Python Based HMI


Thread Starter



I am looking for a comprehensive guide on Python based port communication/HMI development.
Please help me if you can.

Also can somebody help me with some general information and prospects of Movicon SCADA.

James Ingraham

There's not going to be a comprehensive guide on Python HMI development. As for port communication, there should be plenty available from basic Google searches. This forum isn't going to be the best place for that kind of information.

Hopefully, someone on here can speak intelligently about Movicon SCADA. That's a more relevant question for the forum.

-James Ingraham
Sage Automation, Inc.

Curt Wuollet

One must remember that Python is Open Source and the development is not centralized. So the lightly embedded HMI and control things I am doing use libraries from a great many sources. Even one or three that I did.

This means that the information tends to be nebulous and distributed. There are "comprehensive" docs and guides on the core language, but a look at the variety and sheer number of libraries available, many done ad hoc to solve a particular problem, and it seems unlikely that you will find anything all encompassing and handy for reference. It's the nature of the beast. Pick your libraries, read the docs. And, if there are questions still, I have found Python library code far more readable and much less cryptic than optimized C code, although at some points they are one and the same. You'll get out what you put in, but I find it pleasant to work with. And there are plenty of examples for almost anything, because it's Open Source.

If you can't find what you want, write it.

One thing that you have to consider with Python is the fact that it is interpreted and a lot of errors don't manifest until you are testing the system (i.e. runtime errors vs. compile time errors). It is also very loosely typed (as in variable types) so you can get into trouble there. I suppose this is a matter of opinion because some will turn this argument around and say that this is python's strength.

What I'm getting at is that I don't necessarily see the benefit of python in a HMI situation over using a good cross platform GUI toolkit like QT. Working with QT designer is actually pretty convenient and the "complexity" of C++ won't be felt if you are writing a typical event driven application. QT has a lot of higher level libraries for communications too, so you aren't sitting right on top of the raw sockets library, for instance (These types of things also go a long way toward letting your app be cross platform).

I am working with C#.NET for a HMI project at my company and if I were to do it over I would go with QT targeting linux and... when necessary... windows.

I have not done much graphics development in python, but this sounds interesting, and I'd like to see what you come up with. I did use the PyGame package for some graphics, but I was not building on HMI at the time. On another project I worked with the pymodbus package. It is truly amazing how much open source gold there is. The pymodbus package worked great and I barely had to touch it to get exactly what I needed. I have also done some OPC development with python, but I did not get as far with that.

You said you need port communication. Can you elaborate on what you need; Ethernet port or serial port maybe? Are there any specific protocols you will be using?

Curt Wuollet

I think some things would have to be tightened up and I'm not sure how you would do others to non variant object code.

It runs fast enough on the $35 Pi computers I have been using where I haven't recoded anything to C. And there is Cython, but I haven't looked at that yet.

It'll never be real time, what with garbage collection and all so I've been content to use as is, at least until I run into a speed problem. I've even drawn up a couple of boards to give the Pi 24 VDC IO. It's great where PLCs aren't,(networking, format translation, etc.) and will drive an inexpensive HDMI display from 7 to 70 inches. It's definitely got a niche for the automation I'm doing. Since Python is the language of choice, I'm just rolling with the flow. I've found problems much easier (and much cheaper) to solve if you aren't stuck on using only PLCs. And I'm delivering better solutions.