PLC code standards

B
I have a lot of experience with end user electricians. I have not run across any "excellent" programmers, in fact the code they write is usually pretty awful. What they are often extraordinarily good at is understanding the machine and knowing what it takes to keep it running. I am often amazed at how clever they are in this respect. But there is a huge difference between tweaking an existing piece of code to improve/fix/upgrade it, and sitting down to write a significantly sized PLC program from a blank piece of paper.

Bob Peterson
 
B
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.

As for being "straightforward", I am not all that sure that it is. You can create something much simplere by using a number in a register to define the current machine state. Its a whole lot simpler and easier to code and debug, than any number of latches and unlatches.
 
C
Hi Pierre, James.

I'm not sure anyone has proposed C/C++ as a general use automation language. Just because the hardware is programmed using C or C++ doesn't
mean that's what the end user sees. In fact, I would expect almost all current PLC system code was done in C or C++ with possibly some
assembler thrown in. My applications use C because it would be very difficult to describe machine vision procedures in ladder. Even in these applications the logic portions are done with boolean operators like "if( I2 && I17 )
Q1;" which describes a rung. I don't think many people would mistake what that does. It is also possible to make a graphical ladder editor that
outputs that statement when you draw the rung. I just didn't have the need or the time for that application. What we are discussing are other
ways to describe that rung. My preference would be that you could see and work with the logic graphically like any other ladder product. or
you could use an "english language" method like: If fill_valve is open and tank_full is on, turn on klaxon_horn. Or find another plausible
method to describe logic and processes that everyone can understand. Anyway, my point is that you are almost certainly using code written in
C/C++ every day and _all_ the machines you use probably run C at some level. If you don't want machines using C you need to invest heavily
in mechanical drums and relays. Leave it to the CS guys to find an interface that makes the job easy. No one is forgetting that that's the
whole idea of a PLC. I hate to see people scared off for no reason. It should be possible to accomodate all tastes.

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.
 
B
I was referring to the use of a Latch/Unlatch instruction combination as opposed to building a latching circuit out of coils and contacts. With the circuit, the "programmer" has the option of deliberately determining whether the reset or set contact dominates, whereas with L/U coils it
depends purely on the order in whicxh these are in the ladder. (It is also possible to have the same coil behave differently in a scan if a L is
followed by a U and then by another L acting on the same address.)

Bruce
 
V

Vladimir E. Zyubin

Hello PETERSONRA,

PAC> As for being "straightforward", I am not all that sure that it is.
PAC> You can create something much simplere by using a number in a register
PAC> to define the current machine state. Its a whole lot
PAC> simpler and easier to code and debug, than any number
PAC> of latches and unlatches.

But the right solution is to use the right programming model. Unfortunately for all of us, there is a large class of tasks that can not be implemented in the LD... despite on our wishes
to be both wealthy and healthy... :)

"Can not" because the brain will get the cancer because of working with the current-machine-state-registers. Overcomplexity because of an inadequate tool.

--
Best regards,
Vladimir mailto:[email protected]
 
D

Dobrowolski, Jacek

Bob Peterson wrote:
>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. <

I see your point now and agree with it.

>As for being "straightforward", I am not all that sure that it is. You can create something much simplere by using a number in a register to
define the current machine state. Its a whole lot simpler and easier to code and debug, than any number of latches and unlatches.<

Sometimes there's a need to split the flow into simultaneously executed paths. Then using a register is no longer so easy. On the other hand simple logic (bit) instructions are usually executed faster and occupy less memory than integer instructions. Less and faster code.

Regards,

Jacek Dobrowolski, M. Sc. E. Eng.
Software Eng.
 
M

Michael Griffin

Bob Peterson wrote:
<clip>
> As for being "straightforward", I am not all that sure that it is. You can
> create something much simplere by using a number in a register to define
> the current machine state. Its a whole lot simpler and easier to code and
> debug, than any number of latches and unlatches.
<clip>

You can write a bad program using just about any method there is. The integer number approach has its problems as well. If the sequence has exceptions (loops, jumps, etc.) you end up writing "magic numbers" as constants in the instructions that write to the step register. Because there is nothing obvious about what the number itself means it is easy to make a mistake and type in the wrong number (I've made enough of these mistakes to know what I am talking about with this).

The biggest problem with this method though is when the sequence itself is not a simple linear sequence, but diverges into parallel paths and converges back again. With a "step number" approach, you typically end up with multiple interlocking software sequences which have to handshake with each other in
order to try to describe parallel execution paths. This can get quite messy and error prone as well, especially the interlocks between the multiple sequences.

However, when the machine sequences are always simple linear sequences which aways execute in the same order, then the "step number" approach does have the advantage of being easy to describe. What makes the method easy to use in
some applications but difficult in others is that it contains assumptions about the type of process you are trying to control (the simple linear
progression). I suppose your opinion on the method may depend upon the type of machinery you are exposed to.

************************
Michael Griffin
London, Ont. Canada
************************
 
V

Vladimir E. Zyubin

Hello Michael,

Michael Griffin wrote:

MG> You can write a bad program using just about any method there is. The
MG> integer number approach has its problems as well. If the sequence has
MG> exceptions (loops, jumps, etc.) you end up writing "magic numbers" as
MG> constants in the instructions that write to the step register. Because there
MG> is nothing obvious about what the number itself means it is easy to make a
MG> mistake and type in the wrong number (I've made enough of these mistakes to
MG> know what I am talking about with this).

Yes. Finite state machine in the LD leads to unreliable programs. Identifiers and adequate programming model are the only medicine. Even
SFC makes the problem much simpler.

MG> The biggest problem with this method though is when the sequence itself is
MG> not a simple linear sequence, but diverges into parallel paths and converges
MG> back again. With a "step number" approach, you typically end up with multiple
MG> interlocking software sequences which have to handshake with each other in
MG> order to try to describe parallel execution paths. This can get quite messy
MG> and error prone as well, especially the interlocks between the multiple
MG> sequences.

The divergence is not a problem. The convergence is. It demands a strict technique, dicipline... especially, when there is need to work up errors
in algorithm, when the response of control system on errors is algorithmically complex... The other case - if the errors are system errors, meta-level errors, e.g. errors issued by a I/O module defect... This kind of problems is complex in itself... Any aditional complexity (e.g. because of an inadequate linguistic means) then the problem becomes insoluble.

--
Best regards,
Vladimir mailto:[email protected]
 
S

ScienceOfficer

Bad code can be defined many ways, but I don't understand declaring Latch/Unlatch usage as a symptom of it.

Latch and Unlatch are useful in the cases where the conditions for setting a bit are not the opposite of the conditions for resetting it. Time is the best example; technically, Monday is not the opposite of Friday. I know of many applications (outdoor lighting, pump control, etc.) where an output is latched at a start time and unlatched at an end time, or after a duration,
or after a completion signal.

Latch and Unlatch are also a natural for _two-state_ situations. For example, on a gravity ride (e.g., a roller coaster), when a vehicle or a
failure is detected in a zone, the blocking mechanisms at the beginning of the zone are unlatched. When the zone is known to be clear, the blocking mechanisms are latched. There is actually quite a bit of code involved with something like this, and the logic supporting the Latch and Unlatch decisions is quite complex in each case. (I once did one of these without
using Latch/Unlatch, just to prove I could do it. The code was unmaintainable, and got rewritten using Latch/Unlatch at the next
engineering change!)

I'll agree that attempts to create state machines using chained latches can be a mess, but I've also seen it done well. I recall a very complex and successful machine with dozens of states in at least ten different execution threads, and the technicians could tell everything that was going
on by looking at one data table display on the programming terminal.

Wherever a "1" quit marching from right to left, they knew to look there for the problem. This was before HMIs as we know them today, though, and I doubt I would encourage anyone to go to this much design effort today.

All that said, I find it unforgiveable when the Latch and Unlatch are not next to each other, or when the output bit is addressed by more than a
single instance of each.

Hope this helps!

Larry Lawver
Rexel / Central Florida
 
B

Brian E Boothe

By the over use of Alot of Latches is it Going to effect that Output from Going HI in ms or us Resolution. if thats the case get outta ladder logic and goto C++..
 
B

Brian E Boothe

Well in OUR Company AN ELECTRICIAN Reads PRINTS,,, and Fixes&Repairs Motor Starters, runs Conduit Pulls Wire..Wires Outlets. Panel Building. (The Electrical Division). WE on the other Hand (CONTROL DIVISION) Install Processors Troubleshoot CONTROL Related issues, AB-PLC / NETWORKING. / C++ / VB CODE issues..Active-x Developement..Project Design and Engineering Specification. SURE our Electrician has A little Knowledge of Ladder Logic Paper And Pencil (BASIC-Knowledge) even Ours...NO quibble there at all..... But throw him on a 2Ghz Computer with The Software,, Using A Control-logix Processor with 500Tags+ in RS-VIEW..w. RS-SQL And He is Completly Lost. Even Windows Navigation itself Is a Struggle for Them... AND NO we Dont Want Tinker's / Play arounds in our Software. But we DO Document And Give Hardcopies of the Program...You must Only Implement In one location like a factory Setting or Something. then I Could understand your Meaning ......We on the Other Hand Work All over the US...
 
Curt (about using C in control):
> It is also possible to make a graphical ladder editor that outputs
> that statement when you draw the rung.

FWIW, MatPLC has a module that takes PLC-style mnemonics and translates them into C. Normally, you wouldn't look at the C, of course - MatPLC
then goes on to compile it into a full module which you then run.

It's not particularly readable code, because it's not expected to be read by humans and it has things like Master Control even if you never use it in your program, but it's not too bad. If you run the program in a debugger (like ddd), it'll show you the original mnemonics anyway.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
B
ScienceOfficer writes:

> Latch and Unlatch are useful in the cases where the conditions for
> setting a bit are not the opposite of the conditions for resetting it.
> Time is the best example; technically, Monday is not the opposite of
> Friday. I know of many applications (outdoor lighting, pump control, etc.)
> where an output is latched at a start time and unlatched at
> an end time, or
> after a duration, or after a completion signal.

I would agree there are good reasons to use latches, time is probably not one of them, since it does have more than 2 states, I would be inclined to represent a day of the week as a number from 0 to 6, rather then as would 7 seperate latches. It seems to me this is inherently more obvious. I would probably not use a latch to turn on anything time based, but would probably use a compare statement to compare the current time to the period of time the output is supposed to be on and use that logic to control the output. One reason for doing so is that the idea of latching a bit on, then off works most of the time, but what happens if someone resets the time of day clock, such that the off time does not happen, An example - on at 8 off at 5, at 4:55 the operator realizes the PLC TOD clock is wrong and sets it to 5:05. Now it won't unlatch. BUT, if you used a limit test to turn the output on when the time is between 8 and 5, it would still work correctly, and it seems more obvious to me do to it this way. I realize there are ways to avoid this situation and still use latches, but I prefer something that is more obvious to me.

The main problem I have with latches is not that they are used at all, but that really badly written programs seem to rely on them and the associated single shots that are used to clear the scan races the poorly written code produces. I agree there are other ways to write bad code, but this seems to be a common way of doing so. I have even seen code where the programmer created single shots in RLL to unlatch bits and apparrently either did not realize he was doing so or did not know the PLC had a single shot instruction.

Another indicator of bad code is code that has a lot of short timers in the logic to keep things synched together. I hate this cause its just as easy, and more consistent to write the code so that the timer is not required. For example - I have seen code where a timer was used after a sequence was completed to allow part of a machine to move out of the way, before another seqeunce started that would have crashed into it. The problem with using a timer is that what happens if it does not move. Its a little easier to code this way, but its much better to code a permissive into the sequence rather then just relying on the thing working OK every time for the next 30 years.

bob
 
D

Dobrowolski, Jacek

What can I say ? Stop thinking of coils (as an electrician) start thinking about memory areas (as a programmer). It will make your life easier.
Particularly as this "differently behaving coil" phenomenon is considered.

Regards,

Jacek Dobrowolski, M. Sc. E. Eng.
Software Eng.
 
J

Joe Jansen/ENGR/HQ/KEMET/US

That would be those of us that fall into the catagory of people you deem unworthy: The FINAL: customer. Those of us who actually pay the money to buy the stuff you build to pay your salary. Remember the saying about biting the hand that feeds you, and all of that.

All you are saying, really, is that -your- electricians are incapable of handling software. The electricians in our plants (more than one, and in more than one country) happen to be capable of handling ladder logic, because they have been trained to do so.

Having worked at 2 different robotics integrators prior to taking work as an end user, I can agree that at those companies, the electricians did not
work with the code at all. No need, as there were programmers there to do that.

However, when one of your systems is installed, are you on site for the entire install? Do you go with if there is a warranty issue that requires
a service tech to go out and repair the machine? The point is that if you are the only one that you allow near your code, then you are the one who
gets called at 3 am (or whenever) if something goes wrong.

In a machine builder setting, downtime is meaningless, as it is typically debug time. In production, downtime is measured in dollars/minute, and if you only have one person that knows how to write the program, then your
line sits down waiting for that person to come fix it. Better to have people on site, trained, that can cover the line round the clock.

--Joe Jansen
 
V

Vladimir E. Zyubin

It seems to me Mr. Peterson states that any program will be more simple if it will be expressed by homogenious (simple) means.

Really, it depends on. If the algorithm is homogenious - yes, the homogenious (and adequate) means lead to a more readable program. If the algorithm is non-homogenious - no, the homogenious (and non-adequate) means lead to awgful unreadable code. (As an example we can keep in mind that every program can be expressed with the "decrement" and "jump if zero"
operands only... but these simple means will lead to unreadable code for vast majority of algorithms)

In the discussed case Latch/Unlatch are the means that do not consist in the Relay Model. It is the issue of Mr. Peterson's statement, i.e., the issue is the wishes to keep simple means. IMO.

On Wednesday, July 17, 2002, 9:26:45 PM, List Manager <[email protected]> wrote:

LM> Bob Peterson wrote:
>> 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.
[...]

--
Best regards,
Vladimir mailto:[email protected]
 
M

Michael Griffin

On July 17, 2002 11:26 am, Larry Lawver wrote:
<clip>
> All that said, I find it unforgiveable when the Latch and Unlatch are
> not next to each other, or when the output bit is addressed by more than a
> single instance of each.
<clip>
If I understand what you are saying correctly, then I think that this can have problems of its own. For example, when you have conditions which require several latches to be set or reset together, then if you always want to put your set and reset conditions next to one another you have to duplicate the rung logic to accomplish this. This increases the chance of bugs being introduced.
Another problem is when the states of groups of latches must be consistent, but they are located in different parts of the program. This results in zones where one bit has been modified, but the other has not yet. Suppose
that 'A' is set under some condition, 'B' is set under some other set of conditions, but when 'A' is reset, then 'B' must also be reset. Can I always contrive to ensure that there are no side effects if 'A' and 'B' are reset some distance apart from one another? Would it not be simpler and more fool proof to simply reset them in the same rung?

Really, the choice is one of whether you wish to group together rungs which are related in terms of what the machine is doing, or whether you are grouping together rungs which are related in terms of the memory location used.
Suppose that at a particular point in my sequence, I set a flag to indicate "weld complete", and I want to remember this until I have released the part from the machine. Now where should I reset this flag? With the logic
which is related to releasing the part from the machine or with the logic which is related to weld complete? With the first method (releasing the part), the operations conducted on the flag are related to the sequence of operations, while with the second (welding), they are not.

I think you should use latches sparingly and carefully because you always need to make sure that you clean them up under all possible conditions. However, I think that arbitrarily avoiding them because someone once used them when he wrote a bad program can be a cure which is worse than the disease.

************************
Michael Griffin
London, Ont. Canada
************************
 
J

Joe Jansen/ENGR/HQ/KEMET/US

What are you talking about? The *A*ffect of latches in your logic on the time it takes to send the output high or low is insignificant. If your PLC scan time is measured in microseconds, you already have a lot more to worry about.

--Joe Jansen
 
B
Mr. Peterson's main issue is badly written code. I really do not care much what method is used as long as it is consistent, works well, and has few gotchas. The worst programs I have had to fix generally seem to have an overabundance of latches in them, and inevitably there are a few somewhere in the code that don't get reset along the way, so things don't work quite right. I really could care less if someone wrote a program using all latches and no coils. I myself use very few coils for actual sequencial control, as its much easier for me to visiualize a sequence as being a series of mutually exclusive steps, a logic state that is generally better described as a single value with more then two states, rather than multiple bits with 2 states each. A whole lot easier and eliminates the need to go back in and reset latched up bits with a cleanup routine.

And I do believe in keeping the code as simple as possible. Occassionally, you have to program an algorithm that is not particularly simple. These are fairly rare in general purpose automation projects. Most of it is pretty simple stuff, just a lot of it. Break it down into managable chuncks and program that chunk. The worst part tends to be interlocks between the chuncks.

I do not like jump instructions because they are some what inherently non-obvious. Its really annoying to be trying to debug code inside a jump zone and not relaize you are in a jump zone. OTOH-with some PLCs, its a handy way to implement a do-while or for-next loop inside a single processor scan. But in that case the jump zone is usually only a rung or two long away so you can see it.
 
B

Brian E Boothe

Soo... Im supposed to be worried over a Container valve Opening at 1ms less or more because of the scan times were off... because of the effect of latches... seems a little picky
 
Top