Programming Style

[Jeff23spl]

Ideally you'll want to assume ideal conditions when programming your sequence, validate that it works. Then build the fault logic. Determine what fault conditions could exist and and create proper actions to those fault conditions.

i'm not agree with you, if i understand well, you forget about fault handling at first, you will have to change or do again your ideal condition to add fault sequence, it's doing the job 2 times....
You may forget some details at first but to me the fault handling sequence should not be considered a detail.

I did and seen to much programmer stressed or in a hurry to enter the ladder code and patch it on the way to end up with a big mess of last minute changes adapted to the original logic...
You should think and write the sequence on a paper (not ladder but logic step ) see the machine passing thru this logic in your head and validate where it should go bad and adapt it before coding it.
It may seem a lost of time at first but it will save you manny hours at the end

Only when it works on the paper with the complete design, you may code it on the plc because it will work there also. If not, it is because you made a coding mistake or a copy error.
You should not let the plc decide if your logic will work or not,you should stay in control!

If you work with a new brand and want to make sure something works, it may be a good idea to test just that particul thing alone before copying manny times in your program and have to modify it everywhere...EX: when you understand a timer logic doesn't work this way with that particular brand....try it at first than use it.

 

[Paullys50]

i'm not agree with you, if i understand well, you forget about fault handling at first, you will have to change or do again your ideal condition to add fault sequence, it's doing the job 2 times....
You may forget some details at first but to me the fault handling sequence should not be considered a detail.

I did and seen to much programmer stressed or in a hurry to enter the ladder code and patch it on the way to end up with a big mess of last minute changes adapted to the original logic...
You should think and write the sequence on a paper (not ladder but logic step ) see the machine passing thru this logic in your head and validate where it should go bad and adapt it before coding it.
It may seem a lost of time at first but it will save you manny hours at the end

Only when it works on the paper with the complete design, you may code it on the plc because it will work there also. If not, it is because you made a coding mistake or a copy error.
You should not let the plc decide if your logic will work or not,you should stay in control!

If you work with a new brand and want to make sure something works, it may be a good idea to test just that particul thing alone before copying manny times in your program and have to modify it everywhere...EX: when you understand a timer logic doesn't work this way with that particular brand....try it at first than use it.

I completely agree with you that he "Design" of the program must happen on paper first. And fault handling needs to be included in that design process as well. However, if you have a standard method of design, a standard method of controlling process steps, a standard method of controlling devices, and a standard method of monitoring faults and executing fault actions it becomes relatively easy to additional fault conditions at any time without much work. Meaning I can bench test my "ideal" sequence and validate it works as I expect, add in the additional fault logic, bench test the "fault" conditions. When commissioning starts any additional faults that might be required can be added with minor logic changes.

If every program you write is completely custom right down to flashing a light then some of my methodology won't apply.

 

[albertabound]

I like to create basic machine status indicators seperate from process activities. I also like to create a progress status indicator that can be queried for troubleshooting. Calls to library routines that perform specific functions can be replaced/modified with relative ease.

My general goal is to build continuos refernce points along the process, where should an unforseen condition bring the process to a halt, manual intervention by the opertaor is confined to advancing/reversing the process to the closest reference point for resumption.

 

[OkiePC]

First, all my development falls into two piles:
Process Control
Data Gathering
and I go in with an idea of the visualization to be used, and a visual (hopefully accurate dwg files) of the machines, and electrical drawings.

Then I go top down, take on the perspective of the product (literally personify in my twisted mind) and write the program based on the transformations encountered by the product. I then have a flow chart, steps list, and parameters for the machinery, and I want up front to know about any upstream and downstream equipment and existing or desired interfaces.

That main flow becomes the spine, the overview, the top of the project, and each of its logical sections are quartered off and chopped into ladder logic with no regard for address, only interface bits of the correct binary sizes and shapes. We'll deal with the electrical and I/O addressing later. If I have a section that I don't know how to solve, feels too big, I skip it and move on to the next one, or break it into smaller pieces. Then I go after low hanging fruit and solve all the pieces I know how to solve, leaving me time to stew on the hard ones, and come up with ideas, and sometimes test them in advance until I am sure I have working code even if it might need adjustment at start up. If it does, it gets linked over to the data gathering pile and is made available on an HMI somewhere. It is really cool when you perform checkout and startup without opening the laptop lid or enclosure door. (Honestly has only happened three times so far for me).

Now you have a generic driver, and can get out the prints, map the I/O, generate cross references and build the HMI app, and work out the data exchange during that process which may include copying your input map, or I may choose to use the input map user memory area as my HMI tags keeping the mapping to a minimum, while having it perfectly organized for efficient comms.

That driver code which is subdivided into sequencers, state engines or batching or process variable control logic. I have done so much coding I have templates or rough outlines of each of these to apply. With strictly ladder I also use input and output mapping for all I/O, sometimes separate HMI logic files, sometimes the mapping and I/O and HMI interfaces are part of each subsection.

If there are not too many steps and lots of branches, I tend to use state engines.

If there are a lot of steps in a relatively long discrete manufacturing machine with lots of I/O, I will consider using a sequencer with masked and sequenced input for automatic step control. This is a "style" that can turn out extremely tight code that is very flexible and can be easily tied to HMI recipes or product lists. I have only written one true sequencer for my current employer but we used them extensively on tire assembly machines where there might be more than 100 steps, and a sequencer bit width of 128 bits, with interlocking sub sequencers, and depending on the type of tire, that sequencer would need to skip groups of steps for components not needed, or apply a different number of revolutions of ply or innerliner, for example. Each step advance might be dependent of three or more of over 250 input devices, so the natural built in diagnostics of sequenced inputs make this a great way to code this style of machine.

Like Alaric, if my unconditional subroutines get too long, I tend to break them differently, but I will go several hundred rungs and make use of Advanced Diagnostics if it is best for overall structure or efficiency.

I never control real outputs in conditional subroutines. Conditional subs are fine for processing mapped data for machine control sequencers, but I reserve conditioned branching in ladder for pure functions like sorting data or complex application specific things that may be applied to an array of machines in need of the same logic and data processing.

I always assign diagnostic files for all data channels in PLC-5 and SLC50x programs.

With Red Lion, I have some button bars and master slides and a few tags that are a pretty basic template.

I have not gotten into auto code generation or made much use of library files, simply not enough time for that level of development.

 

[splatman]

By far the best way to design a program for a sequential control that may need to "change its mind" is to design and then code a Finite State Machine. A very useful tool for designing state machines is called Tabula. It represents the state logic in a kind of spreadsheet that can be tested interactively. Tabula state machine design tool. While Tabula will not generate ladder code for you, it breaks down the required coding into very small steps. Also: Brief note on writing FSMs in ladder.

David Stonier-Gibson splatco.com