Actually my background if for a big part PLC-based, mostly Batch-processes (not necessarily with batch application on top). I know it works there, and that there's a lot of value.
A DCS is probably easier, especially for continuous processes. That's not taking into consideration that DCS systems are more closed.
I have the least experience in machine automation. Certainly interested in the methods and approach you use there.
For machine control (which is what I prefer), it is more of a series of steps than keeping a process functioning correctly. You have a series of mechanical components that need to do the right thing at the right time. Most of the more complex machinery I have dealt with has been packaging machinery. At this step, there is a part or isn't a part, if there is do this, if not do this, move to the next step. With each step you then decide what can go wrong. Is this a quality issue or a safety issue, safety issues always taking priority. I prefer to build safety alarms as I go in each step and the step itself is is in my head and I'm thinking through it and build the alarms as a single routine.
That being said, there is also state-based machine programming which I have not had to deal much with as I always dealt with linear processes. That being the case, it is useful to have libraries for how, for instance, a cylinder should function, but machine safety is highly situational and depends on many different mechanical variables based on the machine, the tooling, guarding in place, etc. I see an algorithm that can handle that to be years in the making, and a bug in that algorithm that only appears in a very specific situation could easily cost someone their life.
In my experience, no two machines are ever the same. Even two identical machines made in exactly the same way will have some small mechanical variance that may require some fine-tuning, and for this reason every single machine I have ever worked on has had a way of adjusting various components, either mechanically or electronically.
For the same reason PID controllers have offsets in place. I used to work on water heating PID's and the factory-calibrated controllers were all ~ 5 degress F off. We had to compare measurements with other precise tools and properly set the offset to get the controller to the proper reading, however they were all equally precise in their measurements.
This is just an example where automatically generated code can go awry. How much time is saved generating a code for something so situational vs the time it takes to examine that code and make sure everything is the way it should be? How much is lost in the way of readability via comments as the programmer writes the code?
Will machines be doing the troubleshooting on the system when a component fails? This is why ladder is so frequently used. It doesn't matter what platform that ladder is on, with some basic documentation I can read a ladder from one platform to the next easily and quickly to figure out what is happening and determine why based on the machine's symptoms. So can just about every other industrial electrician I have worked with.
IT requires a large amount of logical knowledge in the form of reading code and being able to see what is happening in your head. Mechanics tend to be very visual creatures as that is what they work with. I'm loving this thread.
