Simple Sequencer

[Guest i_canoe]

I"ll post the simple version to make it all to easy. This is the base for nearly all my programs and I have used it for ten years and hundreds of systems. Just try and remember and service that convaluted program you wrote eight years ago, you will have a much better chance if you start from a concise base. It looks so simple, how can it work so good? Several years of trial and error (started with SLC 100) and three programmers at a small system house, hammered this system into shape. I've had maintenance men insist that this system be used on all new equipment so they could understand the program. I challenge anyone for a cleaner routine, if you come up with one I'll use it. All the Best Best_Sequence.zip

[Guest i_canoe]

anybody figure it out yet?

[Guest PhilipW]

Francis....thanks for the simplified file (1ST_3RUNGS it makes fine sense. But as you surely hoped, I must offer a defense for my own style of programming. 1. First up it isn't really mine..it is a derivation of a much more comprehensive standard used by a major user of ControlLogix systems for whom I have done work in the past. 2. The primary goal was to create a framework that multiple programmers working on many sites, on different projects, could work with. Many of these projects are VERY large and demand a highly disciplined approach to the programming. All I can say is that I had a steep curve to learn up when I first encountered it. 3. The key idea within the ControlLogix platform is the use of "User Defined Datatypes" (UDT) and standard reusable device subroutines for every "object type" within the system. For example all inputs, outputs, valves, motors, alarms, sequencers, scanners, etc all use the SAME common subroutine throughout the whole organisation. (Subject to some variation due to revision history.) 4. Personally I then adapted this idea for use in the SLC 500 system which lacks UDT's and an easy way to pass parameters in and out of subroutines. What I posted is a typical example. It was written and commissioned in about 20 hours because all the subroutines are basically copies of routines I have used before. (It is not quite standard because the 501 processor totally lacks any indirect addressing and I had to make changes to get around this.) 5. Yes it looks complex to begin with, but it is VERY structured and every flag in the system has a clear place in a datatable. First up I create the subroutine and as I go I symbol and comment everything in an Excel file. When I have got the working table finalised its then very easy to copy and paste the comments into as many device datatables as desired...and then modify them to their final symbols with some search and replace. Try exporting the database of this .RSS file as a .CSV into Excel and you'll see how simple it is. As a result every address has a meaningful symbol and comment and I rarely look at the raw SLC (n10:0 style) addresses. 6. The type of application I get involved with is usually some kind of utility or service, and as such as HVAC, water pumps, power systems, boilers etc. and as such I usually don't need sub 100msec response times...BUT what is often the case there are usually lots of the same kind of device in the system. It helps enormously if there is only ONE subroutine to manage for all of them. ie if I decide to alter the logic relating to how a motor faults for example, then I ony have one location to do it in. 7. I use a three level model for my applications: a. I encapsulate each lower level device within its own routine and datatable. In the file I posted the subroutines _SBRPMP, _SBRALM and _SBRLMP, are the low level devices. b. A mid level "glue layer" that provides a place to hook together the relationships between the high and low level routines. INPUT & OUTPUT MAP and PUMP_RUN are examples of this. c. The file PUMP_DUTY is the higher level process routine. 8. Typically you get on site and find that you need to alter these process realtionships, and frankly I used to get into all sorts of "unintended consequences" cutting code on the fly like that. The approach I have taken here seems to help me a lot...I find I can make these commissioning changes with far less stress. I have no quibble at all with your approach Francis...we have simply evolved different styles according to the environments we work in and the experiences we have had. Yes I too used to code assembly language (6809's!!!) and when I first encountered ladder my first thought was "what clunky rubbish!!", but nowadays I have immense respect for what can be accomplished in it. It was after all the very FIRST GUI of any kind, and still thrives 35 years later despite enormous changes in technology. It's key strength is the graphical presentation of the state of each logic statement. It's key weakness is the lack of any inherent higher level structure. With experience all good PLC programmers create some kind of structure to get better results, and help them stay sane. PS Francis..can you spot the simple one rung change to your program to allow more than 15 steps? Give me a day or two and I'll post a simpler file of how I manage sequences.

[Guest setchmo]

Why would any one have to add a rung to increase past 15 steps? I have used this sequencer style as long as Francis. It can be increased in number of steps. I programmed several machines that have more than 15 steps in them. This sequencer will also work, with changes, in other processors.

[Guest PhilipW]

OK.Gents I’ll post my answer to the challenge. This is my simple sequencer. Its a rather cut down version… what is I haven’t included for the sake of simplicity are step timers, step status messages, fault messages, fault handling and logging. In real life I find that getting the program to do what you expect is easy…it’s getting it to intelligently handle ALL the exceptions and faults that's the interesting part. However what I have posted is closely analogous to the method Francis is using but achieved differently….I guess it suit me. I find the DCD instruction annoying because it doesn’t raise a flag at Step 0, whereas the method I am using does. Neither is it limited to 15 steps…this method can realistically go to as many as you can fit into a single datatable ie 256*16= 4096., without cascading sequencers. Similarly for the limits on the outputs. As for Francis’s earlier comment about OTL’s and OTU’s…this REALLY is a matter of personal preference…on the other hand I have a total allergy to OSR’s because you can get into so much trouble if you make the mistake of re-using the History Bit elsewhere. Easy to do in the days of APS. I like to visualise an OTL/OUT pair as “one event set the flag, another clears it”, and as such I find them the flag equivalent of the MOV instruction in the State Logic sequence. Maybe this is all just down to the way I think. SIMPLESTATE.RSS

[Guest PhilipW]

Well? I've given you a few days to paddle your barb wire canoe up.....mm. :*-( You made the challenge at the start of thread and the ball got popped back into your court (yuk how I hate mixing metaphors). I reckon my "sequencer" is cleaner than yours...so have you tried it yet?? (All in the spirit of good clean fun) :-p

[Guest i_canoe]

Philip W Sorry about the delay, I'm busy at the real job. I will be putting in a lab rac this week to see how it runs. Looks like too many mov statements and the scan time is going to be high for a couple hundred I/O system. Patience grasshooper