Process sequencing using Allen Bradley

I have a process that has smaller processes, but I am not sure how to best utilize the ladder logic in this situation. I want to make it somewhat modular so that its easier to change things if needed down the road, and with safety in mind.

I assume using SQI/SQO from the Allen Bradley library is the best route to go, but I cannot seem to find a solid way to integrate them, or if I should ignore those functions?


Is there a ladder logic **** type place that I can look at to get inspiration?

zorbio said:

I have a process that has smaller processes, but I am not sure how to best utilize the ladder logic in this situation. I want to make it somewhat modular so that its easier to change things if needed down the road, and with safety in mind.

I assume using SQI/SQO from the Allen Bradley library is the best route to go, but I cannot seem to find a solid way to integrate them, or if I should ignore those functions?


Is there a ladder logic **** type place that I can look at to get inspiration?

Click to expand...

SQI/SQO...lol the ol' college traffic light problem. If you are using ControlLogix/ComplactLogix platform then my go to is using Rockwell's Phase Manager and applying batch (ISA-88) principles. This won't tell you how to write ladder but it does help break down the processes and show how you can create modular pieces of code in a "standard" way.

Give this a read.

I like the idea behind the Phase Manager, what I don't like is that it seems like it is DLC versus part of the ControlLogix package. I guess if the price is right I don't mind using it.

I have a Java background so writing the logic isn't the problem for me, its just organizing it in a way that is easy to work with and not ridiculous. Granted, java is quite ridiculous in its own right...

Thank you for the FOMP book quite a good read thus far!

I may not understand exactly what you're trying to accomplish, but perhaps some AOI's are in order. Easily changed, and can be placed anywhere in the main logic. Hope this helps.

I see what you are asking but don't have a tidy answer for you. When I transitioned from DCS scripting to programming PLC ladder, it was difficult since ladder doesn't handle sequence naturally. That's why for programming sequential operation in ladder, you need to program a "sequence machine" first. You can use sequencer block or I prefer to build my own. There are some example of sequence over at Mr.PLC, I think.

ISA-88 is a good place to start. It gives you a framework on how to break thing up.

Once you have a rough concept of ISA88, group your IO up into control-modules, then write out how your sequence on paper. The sequence will enable/disable control-modules.

One of the best I ever did was a batching process but it had 14 tanks (+ other processes like CIP etc.) This was based on selecting recipes from an SQL Server, downloading it to the tank(s) depending on what recipe for what tank.
I created a task handler for each tank is basically consisted of a small sequence controlled by an integer for example:
0 = IDLE
1 = Starting
2 = Running
3 = Held
4 = Held on Exception
5 = Resuming
6 = Abandoning
7 = Abandoned
This displayed a message on the screen of the status of the task.
Once written as a function block it can be called for each tank or operation so write once use many times, all that was required was to populate the function block with the associated variables.
Next was to write a Unit process block, this again was driven by an integer in a sequence word, this would do the following: ignoring the first 100 states (i.e. 0= Idle, 2 = ??? & so on) when Unit process was started by the task it would go through the motions of 0 - 100 then jump to 5000, this was increment stage. It would load the stage recipe i.e. stage 1, then jump back to say 101, step 101 would check the ingredient type and force the UP seq to a value of the ingredient type for example:
1000 to 1200 Water addition
1300 to 1500 manual addition
1600 to 1900 Starch Addition and so on
I split the sequence numbers into 10 so that If I needed to add another step there were spares.
Example 1010 = Snapshot tank weight,
1020 = Open Water valves
1030 = check water against set point - in-flight
1040 = Close main water valve
1050 = check in-flight
1060 = Close Trickle valve
1070 = Verify Weight
etc. etc.
1080 = shut down UP
1100 weight error
This means that if the process weight was under you could then either manually add more water then jump back to 1070 to check weight or bypass to accept or abort.
This way I could program one tank, debug it then just copy for other tanks and populate the blocks with the relevant addresses.
As far as recipe handling it meant that the recipe could have multiple additions of the same ingredient but at any stage of the recipe. by the way the recipes had up to 16 stages and up to 7 ingredients.
all outputs were driven in one block by either seq number range or internal markers.