PLC State Machine Coding 2

[itsmoked]

Mucking about in this forum, I've been reading the threads pertaining to state machines trapped and forced to live out their existence on Ladder Logic platforms.

Why? Because I'm working on a big(for me) PLC job that I've come to realize should be done as a SM.

Here is a statement I think makes a lot of sense.

I believe that every step in a process should have a state. That way you can have a simple single point for outputs: A solenoid is on in states 3 to 5 and state 7. The solenoid operation is clearly defined in a single rung and there are no surprises when you go back to modify the solenoid operation.

How is this implemented? Is it just a single output rung with a slew of parallel 'state number' contacts?

Where do You put this output statement? In an "outputs area" or perhaps after the last state that would apply?

Keith Cress
kcress -

http://www.flaminsystems.com

 

[AstroEngineer]

Keith,

I do a lot of state coding for a client. The proper way is to group your outputs in a area as you suggest. The rung (if ladder) is as you suggest with multiple or'd Normally Open contacts of the state machine continuous states. Keeping mind the type of equipment the output operates. If its a single sided spring return solenoid then the state will have to hold the output on by a self latch that is broken by a Normally Closed of another state further along in the sequence. A proper state machine will use a comparator for every state driving a OTE for each state as well as a pulse bit. If possible jump state numbers to allow for spare insertion for later modifications. Hope this helps.

 

[itsmoked]

AStrongEngineer;

Hey! Welcome to Eng-Tips. And thanks for signing up to provide an answer to me. Most appreciated.

OK, group the outputs.

Yes this small PLC is strictly a LL machine. This job looks like about 200 machine states. I'm hoping it will all fit.

This project is virtually all pneumatic. There are twenty air lines leaving the enclosure, two VFDs, and a clutch drive. The inputs are a couple of prox detector signals and a slew of rod/piston location switches.

The valves are two types. ON-OFF-ON and ON-ON. (Parker digital manifolded types) I'm told all the ON-ON ones are latching. I'm not sure that actually means they will latch on only a rung or two of ON time.

A proper state machine will use a comparator for every state driving a OTE for each state as well as a pulse bit.

"OTE" ?

If possible jump state numbers to allow for spare insertion for later modifications. Hope this helps.

Ha! I was just thinking about that. Realizing I will likely need to add states I can see myself having to run down thru a 100 states manually incrementing all the state numbers by one. - About a dozen times. (make that 2 dozen!)

Thanks.



Keith Cress
kcress -

http://www.flaminsystems.com

 

[controlsdude]

I know that Rockwell has state machine add on logic that you can program in this format.

Also, there are forums and website that cover state machine logic in more detail.

I did do state machine coding but the oem standard was maybe 15 states not over 100.

 

[controlsdude]

If you google PackML state machine forums, this is probably what your looking for on state machine logic specification or format.

 

[tygerdawg]

Automation Direct PLCs can be coded in state logic, they have a special rung function for grouping. You could probably download their PLC/programming manual at no cost and take a peek at the method behind their madness. Worked well on the couple of times I attempted such a task.

TygerDawg
Blue Technik LLC
Virtuoso Robotics Engineering

http://www.bluetechnik.com

 

[itsmoked]

controlsdude; I'm checking out the PackML standard. Thanks for the heads-up. I already have the entire control panel built so I can't change to a PLC type that has a native state machine system. In this case I'm using a CLICK PLC. It has a "drum" function I haven't figured out yet. Since it's supposed to provide a timer steps like functionality, at first look, I'd say it's likely to be "time" based rather than "state completed move on" based. Understanding this is today's mission.

tygerdawg; Unless you're referring to the "drum" function are you thinking their DL05/06 series? It's about twice the price and BIGGER.

I'm annoyed by ADirect's lack of documentation. I expected to see a coding manual with at least some simple examples. Instead they appear to funnel you into, 'take this over priced course'. Of the ones I've sampled they seem to completely miss providing the desired knowledge being a bunch of noise instead.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[tygerdawg]

I'm not talking about 'drum' function.

I don't have an argument against your 'size of PLC' complaint.

My experience in buying AD's re-branded Koyo products ("DirectLogic" series), both hardware & software: they are fabulously well documented. After a quick glance at the website, it appears that all of the hardware manuals are freely downloadable.

I believe the explanation of the AD method of state programming is in the documentation for the DirectSoft programming software. You must purchase that, it seems they don't allow free downloads of that manual. I thought they did at one time, but could be mistaken. I vaguely recall that the last time I purchased it, it was cheap ($350 or so??). It is simply a few special function rungs that allows one to group a series of rungs, make series of groups, and advance through the groups in desired sequence. When a particular group is enabled, all other groups are disabled. This could be done manually.



TygerDawg
Blue Technik LLC
Virtuoso Robotics Engineering

http://www.bluetechnik.com

 

[itsmoked]

I have the DirectSoft sw. Yes it's about $350. It doesn't cross to the CLICK series. Darn.

As for the manuals, Yes, they're generally pretty good as is the CLICK one. Nothing missing except a chapter explaining the actual commands. Most commands like NO or NC inputs are of course simple but since this PLC is considered their get-your-feet-wet unit you'd think they would bother here. Oh well.

BTW the Drum instruction actually will do Time Steps or State Steps. Still looks a wee bit too constrained to be useful to me. Only one input allowed per state. You can have up to 16 outputs per state.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[controlsdude]

"Only one input allowed per state"

Why dont you combine all the inputs necesssary into one input for it to go on to next step? Its probably not constrained to a physical input but just one bool, which can be any combined state of logic.

 

[AgeXVII]

itsmoked - the Click Koyo has a great set of help files that were very useful to me when I just learned ladder logic on a project. the drum function is explained in there as well and they do offer some coded projects as samples. It turned out to work really well for me but I think an AB PLC might have been a bit simpler to use because I had seen it before and had some sort of an idea.

I did not end up using the drum function but I did play with it for a while and got an idea of how it worked.

 

[itsmoked]

Yeah there are some examples in the help file. I found them.

I've decided not to use the drum function either. I've gone with the latch/unlatch state machine and it's working fine. Now I wish you could cut-and-paste multiple lines of code since there is a huge amount of repetition but, that's probably just being greedy.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[AgeXVII]

If I remember correctly you can? It will only let you take a full rung I guess you call it or lots of them in a group without skipping but then you can delete middle parts after you paste? It has been a few weeks but I remember doing a lot of holding the shift and arrows to get big chunks I wanted then ctrl c, ctrl v and changing all of the tags

 

[AgeXVII]

and also on the automation direct web site they have already coded examples to give you an idea of how some events are handled.

Automation Direct Code Examples List

 

[itsmoked]

Hi AgeXVII. I sure can't see a way to grab more than one line. Tiz a shame. They screwed up a lot of things by using the CTRL and ALT keys to instantly cause the LINE editor to pop into action uselessly. Nor the shift key that would normally select everything between. This leaves no way to select more than one line in the conventional Windoz manner.

To top that off, nothing in the normal LINE editor works when I've woken it from its crypt with the CNTRL key. I can't subsequently 'pick' any lines and have them 'substantiate' like they should. ODD.

And another thing.

I can't believe that when you select "..." before entering a contact address or coil address and it pedantically launches the Address Picker, you can't Nickname the chosen contact/coil even though the space is staring at you. You have to select the contact double-clicking it. Once the Address Picker closes you have to go over and open it again, wait for to eventually re-open with the exact same view and then you have to muck about to find the same contact again T H E N you can nickname it. Is there a better way I'm missing?

Keith Cress
kcress -

http://www.flaminsystems.com

 

[itsmoked]

Oh oh oH!! Thanks for the "code examples" link.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[itsmoked]

In writing this project I find it easiest to follow each state immediately with the outputs driven by that state. Obviously that results in the same outputs occurring in multiple places. That, of course, would be a disaster so after I'm done with an entire state machine I cut and past all the output lines immediately after the state machine. Then it's easy to condense them all down with lots of OR'd states into a single output statement for each output encountered.

My question is this: If I do as described above but then have several different state machines, is it reasonable to leave the output statements after each state machine or should I move all outputs to the end of the entire program?

Keith Cress
kcress -

http://www.flaminsystems.com

 

[PNachtwey]

itsmoked, you can have a section at the bottom of the ladder where you specify which output bits get set and cleared for each state. Then all the I/O is in one place and easy to configure. I have seen two ways of doing this. One is to have a rung for each I/O with the logic that specifies which state turns on each bit.
Another way is to have one rung for each state and turn on or off the I/O for that state. Some people don't like this because the outputs can be turned on or off in multiple states but at least it is easy to see in both cases.
If there is a lot of I/O this second method can save a lot of ladder rungs because there are usually fewer states than I/O.

Some people like state bits and others like state numbers. With state bits one doesn't get hung up on the oreder they are allocated.

One thing that is important is to avoid race conditions where two or more states can be executed in one scan. To avoid this I keep two sets of state bits. One is the next_state bits and the other is the current state bits. At the top of the rung I copy the next state bits into the current state bits by words or dwords. In the state machine I only change the next state bits. This way no changes in the next state will activate a new state in the current scan. One needs to do the same thing if working with state numbers.

Each state may have more than one rung. The first rung is a one shot where code that needs to be executed once on entry to the state are execute. The second rung is ladder that gets executed all the time. The second rung should probably be divided in to more rungs. For instance there can be a transition rung that determines when to change the next state and perhaps start a time out timer in case an I/O doesn't come one. There can also be a clean up rung for on exit.

Don't try to put too much into a state. I once helped a PLC programmer that was programming a lifting device. He had one rung for up and one for down. He struggled with this for a week or so. I asked him to explain what he was doing and we broke the problem down into many states with 11 rungs or so. The PLC programmer did not like having 11 rungs but he got it to go in 4 hours after that. It was a simple program that should have been done in four hours. The two rung solution suffered from race conditions.

Look at Moore and Mealy state diagrams.

The main thing is to avoid the race conditions and be consistent on how you do your state machine.


Peter Nachtwey
Delta Computer Systems

http://www.deltamotion.com

 

[FrancisL]

You may find that this is very relevant
Programming Equipment States Efficiently
State based control is a method of defining the required states of some equipment and then driving the equipment to one of these states, typically where a Phase step sets the Equipment States. ControlDraw has long supported this method as it provides a very efficient method of representing functional ....
See the link for details

Francis

http://www.controldraw.co.uk

www.s88control.blogspot.com

 

[itsmoked]

Thanks for the nice tips PNachtwey.

I'm using the following form:

.....ON_STATE_1        SOME_CONDITION            TRANFER_TO_STATE_2
---------| |-----------------| |------------------------( )--------------

     ON_STATE_1      TRANFER_TO_STATE_2             ON_STATE_2       
---------| |-----------------| |-----------------------(SET)-------------
                                             |
                                             |      ON_STATE_1       
                                              ---------(RST)-------------

      ON_STATE_1                               POSSIBLY_DO_SOMETHING       
---------| |-------------------------------------------(SET)-------------


      ON_STATE_2     SOME_OTHER_CONDITION        TRANFER_TO_STATE_3
---------| |-----------------| |------------------------( )--------------

      ON_STATE_2     TRANFER_TO_STATE_3             ON_STATE_3       
---------| |-----------------| |-----------------------(SET)-------------
                                             |
                                             |      ON_STATE_2       
                                              ---------(RST)-------------

      ON_STATE_2                             POSSIBLY_DO_SOMETHING_ELSE       
---------| |-------------------------------------------(SET)-------------

This is working really well. My biggest fear is having to make a change to state_2 when
I have twenty states..

It's really nice to have the ouput directly after the state. But of course this causes the
"multiple same outputs" hassle because inevitably multiple states control the same outputs.
So, I moved them all to the end of their respective state machines. That was fine until,
being done with all four state machines, I discovered that I had to do an initialization
state machine to setup the physical machine. That state machine uses outputs from all
the other statemachines combined! So now I probably have to move all the outputs down
to the very end of all the state machines.

The only problem with that is that it's hard to easily see what a particular state you're looking at effects without scrolling down two hundred lines.



Keith Cress
kcress -

http://www.flaminsystems.com