Using ladder logic, there are many ways that a program can be structured and still work on a PLC. Some ways however, are very difficult to maintain, or to follow if you did not write the original code, others become very big and clumsy.

I believe that it is important to creat a structure that is easy to follow by someone who has plc knowledge but was not necessarily involved in writing the original code.

I like to create state machine logic to make it easy to find faults and to edit/grow the code. This is not necessarily the best way, but it is my personal preference.
Each "state" can then be separated off for easy manipulation.

I am interested to see what "standards" and preferences others use, what you find to be difficult to work with (after someone else has created the code) and what you find to be good to work with.

There are so many ways of achieving the same result, and with a little effort and planning we can either make it easy or impossible.

Best regards,

Hello Mark,

I’ve seen a few company “standards” for plc programming the finite state is one of them
The ones I’ve seen and written usually revolve around a main routine (main calling program) and some type of stepping sequence The software moves from one state to the other by means of a state number or a latch and unlatch system, that is latch in current state then next state unlatches previous state and latches current state. My personal preference is to track the sequences by keeping all states latched and do a clear down on the final state. An interesting standard is the Fords standard or Eddie standard I think they also refer to it as steps. Try adding an extra step/state in, what a nightmare! I would say the mark of a well written plc program is its ease of maintainability and its flexibility to change. I’ve seen more badly written programs than good ones and the experience of the plc programmers does not seem to correlate to the quality of code produced.
Some of the title tale signs of poorly structured code are the over use of timers, latching/ unlatching a bit in several places, no comments, incorrect comments, rungs spanning several pages, no logical flow to the software, no logical segregation of memory use. No logical modularizing of the software.

The down side of poor software is it cost money and if the code is complex, trying to find a problem is a career move or in some cases a career breaker. In the automotive industry clients demand high standards and if they are following the six sigma standards and you have poor code…need I say more.

Regards
Carl

Hello Carl

Coming from a micro programming background, the approach that I tend to take to implimenting state machines is to have a state register with each "state" allocated a number. I use a series of compares to determine the state and either jump to the state routine, or call the state routine depending on the rest of the structure. I find this very easy to work with and you can determine the stat by the number in the register at any time. To change states, you just change the number in the register. It is easy to maintain and add extra states, plus you end up with a very modularised program that is easy to work with.
The problem is, that there are many ways of achieveing the same result and it is difficult to keep everyone happy. I would prefer to write in a manner that is familiar to most who may have to update the software at a later date, the old "Keep it simple" approach.

Have a good day,

Hello Marke

Most of the PLC programmers structure the program in a way which is called “Step method”. In this method, a controller integer or a counter is used to control the operation of machine in many steps. At the end of rung of each step, a “MOV” instruction is used to move next step number into the controller integer/counter, for example 1,2, 3….. Now at the beginning of rungs in each step, a comparator uses which compares the integer value with step number, if equals, then plc scans and operation in that particular rungs starts. The operation in the other steps is now locked because the controller integer value and step number doesn’t match.

This is a very reliable method as we can control operation of machine only in one routine. Otherwise, we have to make many subroutines in the project tree which are caused an additional load on plc memory. This is also as easy as every one who has some knowledge of ladder logic, can understand the operation written in the rungs. This method also saves the scan time of plc.

Rung title and comments are also play an important roll for making a program easy.

Using this method, I have made short the programs in our five Allen Bradley SLCs in different machines and save the memory which have used to program the more parts of machines which were not in our plan when budget was approved for up gradation of machines.

A little late coming into this thread but, better late they say.

I agree with marke and ab2005 that comparing the integer in the register is the best and most flexible method. We didn't use this method back in the day when integer functions cost considerably in scan speed but, nowadays the cost is minimal. When writing initial code, I usually add 10 to each step - similar to the old BASIC line number theory. The idea is to help the next poor smuck (often myself) who has to add steps in between.

This type of 'state machine' can just as easily be run backwards - I mean, if ever you have a need to run the machine in reverse sequence. This brings back a memory of me being 'chewed out' by the head of maintenance at one of the Lear Corp. (Magna) plants. It turns out that my code was considered too complex for their crew to troubleshoot. With misplaced pride, I pointed out just how flexible the program was, to the point of their being to run the sequence backwards with little modification to the code. Everybody in the meeting looked at me as if I'd lost my grip on reality; which is exactly what had happened, I suppose. From then on, they wanted me to write simple bit latch/unlatch type routines.

C'est la vie