there are valid uses for some instructions (was Re: ENGR: PLC code standards - WHY?)

J

Thread Starter

Jeffrey D. Brandt

Not counting off-delay timers in AB products, there are valid uses for most of the other instructions in PLCs. I do agree that an
overuse of latches is a clear indicator of extensive patching.

One shot instructions are handy for anti-repeat logic for buttons coming from intelligent devices.

Scan races are the most difficult thing to find. I agree that good programming avoids them by being structured and concise. Another good indicator of spaghetti programming is when there's
a programming terminal attached to the PLC around the clock, and the associated 'expert' has his pager number written nearby. "Old Joe, he really knows that PLC program. Whenever the machine is messed up, he knows exactly how to get it going
again." Sound familiar?

- - -

In a previous thread ( RE: ENGR: PLC code standards - "http://www.control.com/addPostingForm?pid=1026153091":http://www.control.com/addPostingForm?pid=1026153091 ):
"I have seen hundreds of PLC programs written by other people that used a lot of latches. I am pretty sure there was no attempt at creating any kind of state machine in any of these programs. It was just really awful code, written by people who just were not very good. If you will remember what I said was "You can always tell when someone is using too many latches because they end up with a bunch of singleshots in the code to get rid of the scan races." If it was good code, and a well thought out state machine, it would not have the one shots or the scan races."
 
T
There are legitimate uses for the TOF instruction as well. Sure there are other ways to do it, but the instructions presence makes for simple ladder. Just because it doesn't have universal application doesn't mean it does not have a legitimate use, I have found a few, not many, but a few times over the years when I was glad it was there. There are other AB instuctions such as RTA that I have used less often.

I agree wholeheartedly with the rest of your statements. I recently inherited some machines from a sister plant that had the "perpetual laptop" connection, and yes the code was populated with latches, and there was an associated "expert." A real clue that the whole PLC concept wasn't being grasped by the programmer: extensive use of the S:1/13 (major error halt) bit as a permissive in the logic. I eventually tossed the whole program and wrote a new one. A machine should run properly without constant babysitting, that is no way to run a factory.
 
R

Richard Norris

To highlight another indication of a programmers abitlity with the AB PLC is when they write all the code in one file. A well structured program written over several files makes life easier for those that follow behind. Excessive uses of the latch and also any use of the jump instruction are sure signs of an inexperienced programmer.
 
J

John Waalkes

As for the Allen-Bradley varity of latches, I would agree that they have been abused, but the GE Series Six style where they always come in a Latch-Unlatch pair are okay in my book.

What drives me crazy is when you find a latch driving a latch driving yet another latch. And usually several hundred rungs apart to boot.

We don't need to do the cycle power thing as a rule, so a bit being retentive/non-retentive usually isn't an issue.

But this is just an opinion :)

John
 
Interesting and amateurish comment:

"Not counting off-delay timers in AB products, there are valid uses for most of the other instructions in PLCs. ..."

In singling out one particular instruction from one particular manufacturer's instruction set and labeling it as "useless" or "invalid", it seems that the author really doesn't have that much industrial programming experience (especially using Allen-Bradley processors) and is in no position to give advice on the matter. Hence my comment "amateurish". I could talk at length about very valid uses of AB's off-delay timer and have many times in my career as a college instructor (EE). In functioning as a consultant, I have found this instruction to be quite valuable over the years in terms of program simplicity and efficiency. I find it interesting that one would target ANY instruction and deem it worthless.
 
C

Chiron Consulting

> I find it interesting that one would target ANY instruction and deem it worthless. <

Interesting, but not unheard-of. A significant portion of the 'C' programming community has bought into the idea that using the "goto"
statement is a bad thing, and an indication of poor programming skill. And with as little justification. In fact, I believe the opposite; using goto's well is a sign of skill, not ignorance. An inability to tell the difference says more about the critic than it does about the programmer.

Greg Goodman
Chiron Consulting
 
C

Curt Wuollet

Hi Greg

There are a few situations where a goto is a lot better than the alternative and it often produces better object code. I think folks did get a little carried away. On the other hand, I once agreed to fix an old BASIC program...........

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
Top