> I still know the e-stop function of that code by heart 30 years later
I'd be very interested in hearing more about this! I've recently re-designed the safety system for my company's product, and I chose to keep it purely hardware based (using safety relays) rather than involving any software, purely because it's so much harder to guarantee that software will be failsafe.
That's the perfect solution, and actually quite close to what I ended up doing. But you are still going to have to (1) detect the fact that there is an e-stop in progress, (2) restore the machinery to stable state afterwards and (3) lift the e-stop condition at some point.
And all of those will have a software component.
I've written a bit more about how it worked in another comment.
The big thing to keep in mind here is that an ST is a very limited machine when it comes to IO and that just about every port was already occupied so I somehow had to make this work safely without having additional ports for e-stop i/o in the budget.
If I had to do it again in the present I would never have consented to using such an I/O hamstrung platform to begin with and I would use an FPGA to do all the control logic.
I'd be very interested in hearing more about this! I've recently re-designed the safety system for my company's product, and I chose to keep it purely hardware based (using safety relays) rather than involving any software, purely because it's so much harder to guarantee that software will be failsafe.