I would prefer the 2am call ... Well written programs don't need maintenance going online to find out why outputs aren't coming on.
I find those statements, if considered universal, to have a faulty concept of ultimate goal of the PLC program, and for that matter the goal of everything and everyone associated with the process: i.e. to make money. If that is not our primary driver* for everything we do for the company, then we should be not be working for that company.
* within reasonable constraints e.g. safety, laws, etc.
Yes, in an ideal world, a well-designed HMI would alert maintenance to where the problem is. But in the real world there are too many possibilities to cover them all in the HMI. So between that 2am call and when you arrive, the plant
loses money hand over fist because of a choice of programming language that removed a diagnostic tool from maintenance's kit that could have solved the program sooner.
If a section of code would be so ugly in ladder logic that no one else would understand it anyway, then of course it makes sense to put it in ST. But in the kind of plant where downtime loses money, ST
for its own sake is a Bad Idea.
I say this as a language agnostic (I hate them all
) and from a point of view of having decades of experience coding in ST-like languages, and I have nothing against the language itself.
"The only things I don't like about any programming language are its proponents."