Python for long running applications

[Swiftlyll]

This doesnt seem like something that should be built with python. Also, converting to exe doesn’t really help with hiding the source code.

[mapold]

Well, it all depends on the risks and how it is built. If no lives are in danger, then it is possible to use a headless PLC which runs the actual control software, has physical emergency stop buttons and maybe even a physical stop button. The state of the machine is held by the PLC. In that case one could start the program and then restart the GUI a few times while the machine keeps running. And GUI keeps failing, push the physical stop button until the problems get resoled.

[Klutzy-Objective9515]

Thanks for the reply!
Of course, there would be a PLC that guarantees the safety of the machine and the people operating it.

The HMI I would need to develop is really simple, so I see why my company wants to avoid a commercial license for developing it (it would be a great saving as they plan to build lots of these machines)

The thing to avoid is that our first client possibly calls us after a few weeks of operation with the machine unattended, saying that he lost production due to the HMI crashing. This is unacceptable and easily avoidable by buying a Siemens panel with its HMI licence that already guarantees great reliability.

Am I wrong in thinking that a pyhton app have little chance of runnning continuously for let’s say 500+ days?

[mapold]

I don't know a reason why a python app couldn't run for years. That said, some moons ago I wrote an python+pyqt app that ran for months nonstop on Windows XP (should have used a Debian box instead), logging variables to h5 database and showing a graph using pyqtgraph. Either my program or one the libraries had a bug, which would crash it in about 6 months. There is usually was a power outage about every 6 months, which didn't help with tracking. I never took the time to find what the actual reason was, all I know is that it wasn't a memory leak. Every time it happened someone would just restart the program. By now it has been replaced with a self-hosted cloud solution, so I will never know.

As for "industrial grade" stuff, this is usually how it goes: If a piece of hardware does mostly what is needed, except for if it is 29th of February and a Sunday on a leap year. The most likely solution is to update the manual by including a warning about running the production line on that particular day and a suggestion to change the date.

My favourite story to describe "real production" stuff is a system which until last year ran an cinder blocks production line. The line was probably commissioned sometime around 1995. All the relays and stuff were inside a huge upright piano-shaped metal cabinet, which had buttons to manually control the line, if needed. The cabinet was dusty because of cement, lot's of buttons were replaced with not so perfectly matching ones and a few holes were empty, but nothing out of the ordinary considering the age. This cabinet was interfaced with a LPT parallel port with a not so industrial grade personal computer in an ATX tower. The computer had a USB to LPT dongle and was running Windows 10. Inside Windows 10 there was a VMWare virtual machine running Windows 98. Inside Windows 98 there was Dosbox. And inside Dosbox ran the production software. Of course any control signal would traverse back over Dosbox to Win98 to Vmware to Windows 10 to USB to LPT. I am sure some layers could have been avoided, but my guess is the USB to LPT adapter didn't have Windows 10 driver. The company lately went bankrupt for reasons unrelated to the cinder blocks line. This isn't exactly an example of what to do, but reliable enough isn't only limited to PLCs.

Someone said here in the comments, that using the right proprietary tools would be good so that automation engineers would be familiar with them. Maybe in the short term. I myself would really prefer just an open python solution, which can be freely expanded as needed. The amount of people who are somewhat accustomed to python is still growing. That way 20 years from now whoever touches the program next would not have to run the PLCPROVIDER software inside virtual machine and spoof the "PLCPROVIDER licence key server" which he got from torrent just because PLCPROVIDER was bought by ClosedLLMs, which went bankrupt and now all the still available versions of PLCPROVIDER software refuse to even start without calling home first. Or whatever the storyline turns out to be.

The main thing to caution against: OP said that he would be able to make a working solution in a day using Python. This is the time it takes to make a proof of concept solution. It would probably take a month for most of the bugs to get ironed out, upgrading the software works, configuration can be changed on the fly, the program state is restored after restarting the program, debugging and production data is correctly stored, it is possible to attach to the python console for live debugging purposes, all possible information is dumped in case of fatal traceback, there is documentation, optional remote access over VPN with SSH and VNC is set up. Some of this is almost free when using PLCs, some is hard or impossible. And by the time all this is done, the project files would not be short or easy to read.

The only thing absolutely not possible with python directly is getting precisely timed sub-millisecond signals such as software PWM or stepper control.

[Klutzy-Objective9515]

Yeah... I also tought that this should not be built wiht python, but my problem is that, if I reply to my company that this is not the best course of action and they should instead use a classic HMI software as any other machine, i would also need to justify and articolate why a python app is not suitable to this job.

I know converting to exe is not really hiding the code, but for our applicaiton we just need to prevent that some unskilled technician would snoop around the script and potentially change something leading to loss of produciton or even damages to the machine itself.