RS Logix5000 ST to ladder program

[drbitboy]

For me it's the Buba Effect. I don't want that 2am call when Buba cant find an output to see why it's not coming on.

This is where the money is made, or at least not lost.

If the machine is losing money every minute it is down, and it is down longer because on-site staff cannot grok ST, then ST has cost the company money and the company should find the person responsible for that choice and either make sure they do not make, or have not made, that incorrect choice, or fire them.

There are places where ST works, and works better than LAD, but it is never universally better.

 

[chelton]

For me it's the Buba Effect. I don't want that 2am call when Buba cant find an output to see why it's not coming on.


That's also why I try to never even use indirect addressing. If the PLC has the memory and the scan time, I'd rather use it up and keep it easy for Buba.

I would prefer the 2am call, find out why there was no alarm to point the operator/maintenance to the problem and fix it. Having the program structured using whatever language is fit for purpose. Too often the language gets the blame. Well written programs don't need maintenance going online to find out why outputs aren't coming on.

 

[drbitboy]

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

 

[IO_Rack]

Well written programs don't need maintenance going online to find out why outputs aren't coming on.

I've been following this touchy thread and there is (respectfully) a difference of opinion.

I'm going to +1 this statement.

We recently ran into an issue with a machine that met all the user requirements but in the end had quality issues due to non fail safe programming. The program was also very complicated and difficult to digest which made troubleshooting a daunting task, especially for floor techs.

The problem here was not due to ST or FBD or any language outside of Ladder. The question is, how do specify simple, fail safe and easy to troubleshoot programming?

Short of telling our machine builders how to program (which doesn't go over well), this is a difficult challenge.

 

[cardosocea]

Then quit being fundamentalist and understand that different folks have different situations that need different solutions.

The difference in opinion here is the suitability of your solution. You can write everything in ladder, but certain logic constructs will be horrible to follow for techs that can't understand plain English in front of them. Also, specifying ladder doesn't mean that the programmer actually understands ladder or writes clean code. I now have an all ladder program where the writer was seemingly one of your maintenance techs and no one seems to understand it.

All I'm asking is for the common courtesy of not being called stupid

All I'm asking is the courtesy of thinking a little bit outside of your premade assumptions. Some code is undeciferable in ladder, but easily understandable or even monitored in other languages. Being a fundamentalist for ladder makes you misso out on these things and possibly still get the 2AM call because a tech didn't understand a loop or missed an MCR instruction.

btw, some vendor's ladder syntax does allow for this (.[index] in A-B). It is not some magical concept originated in ST.

Oddly, I tried it in Logix before I made that comment and it didn't allow it in ladder.

I would prefer the 2am call, find out why there was no alarm to point the operator/maintenance to the problem and fix it. Having the program structured using whatever language is fit for purpose. Too often the language gets the blame. Well written programs don't need maintenance going online to find out why outputs aren't coming on.

This is it for me. If a tech needs to look inside a program to understand the problem then the language isn't the issue, the system ihas a problem.

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.

This can be applied to literally everything... when was the last time you had to go into the code for your car's ECU? Your phone? Your neighbour's pacemaker? And yet these things are built with the purpose of making money too.

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.

I don't believe in this... and either way, a system should come with documentation too. Problem is that too many people forgot to actually read it, which made companies think they don't ned to make it. One of the most successful technicians I've met barely understood how electricity worked, didn't know how to measure current and sorted most issues with the automated equipment. His secret? Read the documentation...