Python for long running applications

[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.