We wrote up a Knowledge Base article a little while back that I wanted to post here. It goes over a variety of questions that are common with regard to Python in Ignition. If you’re looking for information on the topic, take a glance at the linked article.
12 Likes
A great addition to that would be an example of a Windows server with Python 3 installed, and then calling externally from Ignition to the CPython install and returning data.
I know it only applies to Windows installs, but this is something that would greatly benefit a lot of customers that want to use panda, numpy, etc for heavy data crunching from within Ignition.
just my 2.5 cents 
2 Likes
Is there anything that would differentiate that from generic documentation or a KB article on how to use system.util.execute or the Java/Python stdlib equivalent?
Well yeah since the above article scratches the surface on bottle and flask.
It doesn’t really explain HOW you would integrate them with Ignition, etc.
#The easiest way to do this is to wrap your Python 3 code with Flask or Bottle, which makes it available by a simple REST call from Ignition.
#A simple Bottle example:
from bottle import route, run
@route('/hello')
def hello ():
return "Hello World!"
run(host='localhost', port=8080, debug= True )
Where would you use this code? What needs to be installed where?
Think like a newbie for the answer 
Huh, guess I should have peeked at the article.
Personally I would not recommend that approach to anybody because now you need to worry about how to keep another piece of software running as a service and make sure it's well documented that your Ignition project relies on this other software.
But that's an acceptable level of complexity for some people.
Agree, the article should probably touch on this.
1 Like
For anyone wondering and needing this immeidately -
You would run the Ignition gateway as a service as you normally do, and then in myFlask.py file which has the sample bottle code, you’d run that either from terminal or figure out how to deploy it/run as a service/whatever terminology you want, from their documentation. Then from ignition, you should be able to hit that end point by doing
client = system.net.httpClient()
client.get("http://localhost/hello")
You may not need the http:, and you might be better off using an IP, but that’s the gist of how you would get that "Hello World!" value returned from your /hello route and into your Ignition script now.
As @Kevin.Herron notes though, now you have an additional server you need to make sure is up and running for your Ignition scripts to run correctly. However if you MUST use CPython scripts this does seem to me like the easiest way to handle that.
I think simply shelling out and executing a script is the easiest approach unless you have an application that is stateful and needs to be running all the time to track that state.
2 Likes
True. I have a web background so my first thought is API’s everywhere! But good point.
2 Likes
Yes that’s a cleaner approach, just more complex as we’ve all acknowledged
The article is certainly intended to be a primer, not an in-depth guide or how-to. That said, I agree that it could use a few more notes about how a Flask / Bottle wrapped script would be executed. I’ll get with the team to update that section.
To Kevin Herron’s point, there are advantages to both routes. system.util.execute() doesn’t require you to package up the Python script or install it as a service / daemon. It does require you to figure out how to do data exchange from your script to the Python 3 script. (Data exchange from Flask/Bottle is normally JSON, but does need some definition by you as well.) Using .execute() can also be trickier to troubleshoot script execution, as any exceptions might not make it back to Ignition (whereas they do with Flask/Bottle). .execute() is a little more efficient than running a local web service, if every ounce of performance is critical. It’s probably worth adding an example of .execute() in the guide as well.
I’d say the majority of folks I’ve talked to who are using pandas, numpy, scikit-learn, tensorflow, and a variety of other data intensive processing have gone the Flask / Bottle route.
Installing a Python 3 program as a service is something that you can certainly search for guidance on. On Windows, one popular options is pywin32, which lets you define your service right in python. On Linux, it’s common to add your python invocation command directly to a .service file you create for it in systemd.
3 Likes
While I probably understand the reasons why jython was initially chosen as a scripting language, is there any discussion about what this means very long term if python itself keeps diverging from jython? It would seem that jython is almost a dead end given the lack of jython 3 progress (I just saw a post from 2010 on stack overflow talking about jython 3), even though it isn’t quite pining for the fjords just yet.
There’s no solid plans but we’ve discussed a future where there are multiple scripting engines to choose from. I don’t know if or how they would interact/interop, it would maybe have to be something done per-gateway or per-project if we could figure that out. It’s really just crazy future talk right now
We don’t see the evolution and divergence of Python as a huge issue. The scripting language doesn’t need to evolve at the same pace or even at all, it just needs to be stable and maintainable and something we can keep working. We do understand that library compatibility will keep getting worse, though, which is part of why we’re considering other options.
I agree that it’s not a huge issue at the moment, but the more that python 3 increases in popularity, the more resources there will be for it, and the more frustration there will be for people using Ignition when they try and google a python solution 
But OTOH the main scripting language for Cimplicity HMI is still a version of basic that is a throwback to last century. And while it does support C# for scripting, you need to jump through hoops if you want to use any non-trivial library functions.
And I just saw that Oracle has been trying out its own version of Python - GraalPython which is trying to be Python 3.8 equivalent, and has more motion in its GitHub repository than jython 3
Yeah, in some ways we would have been better off developing our own scripting language or dropping something less popular but already developed like Lua in instead of opening everybody’s eyes to the world of Python.
Seems crazy, but it’s got to be close to 15 years ago that this Jython decision was made…
I'm actually really glad that I have such a powerful scripting language to use. But I don't use third party modules much so the whole python 3 issue doesn't bother me.
Almost as bad as FactoryTalk's VBA 6.0 
Started using Ignition regularly and started getting more and more requests for our SCADA, which is still FTV, to do things like query a data base. Makes me feel like I'm back in the stone ages. I suppose it's better than BASIC but not much.
I'm certainly a better programmer today because of that choice so, I at least am grateful for it.
4 Likes
There's a massive difference in core Python from 2.7 to 3.x. Python 2.7 is still powerful but it doesn't take long working in 3.x to start missing features from it imo
https://powerfulpython.com/blog/whats-really-new-in-python-3/
*and tbf it takes even less time working in other HMIs to start missing Python 2.7
I have to make a confession here. I'm one of those people who looked down my nose at python's use of whitespace. But up until using Ignition I had never actually used python in a serious project. 
After having been exposed to the use of whitespace I find that I can deal with it. But I still have a strong opinion about it 
1 Like
I’m not a fan of whitespace-sensitivity either. I get it, now you’ve got a language that looks pretty even when newbs code, which is arguably a reason Python took off, but it’s annoying
That said, the deeper I got into Python the more I learned to appreciate it for what it is. I remember learning a few idioms from Raymond Hettinger’s Transforming Code into Beautiful, Idiomatic Python and going “alright, that’s pretty cool”
5 Likes
Very cool link, thanks for sharing