Sequential state machines

[eastkodakguy]

State machine engine

In some programs i have seen a state machine engine is used at the beginning of the ladder file which tells you what the last and present state that the machine is in, below this is rungs that have latches and unlatches these are for the individual states, below that is where the real code is (the code that acutally controls the machine). It is pretty quick to be able to go to a particular part (file) of a machine and see what is keeping it from going to the next state. I have only seen this used on ab plc's but i am sure that it can be applied to alot more.

 

[Tmm2112]

SFCs are fine if everything goes according to plan. But if you add a PAUSE button, or an E-STOP, and they can get real ugly, real fast. That's the beauty of Ladder Logic - it is more adept at exception handling than SFCs and some of the other highter level hanguages.

Actually, sequential logic has defined structural components intended to handle things like a pause, stop or abort. As long as you can identify the conditions, you can program for it and the sequence will handle them in whatever way you need them to. There is no reason for an SFC to get ugly just because someone pressed an E-stop; you just have to include it in the conditions/actions. That's actually the beauty of SFC far more than ladder; the very structure of the programming method tells you that you need such things. You can do this in ladder as well, but you have to have the experience to tell you such things are needed. If I add a new input that stops a process, I wouldn't expect my program to handle it smoothly no matter what language I used unless I configured it to do so.

 

[janner_10]

I think 17 years may actually be a record!

 

[PLCnovice61]

Its nearly "Engineer v Joe Maintenance" thread currently on the main page, from 17 years ago.
Still very interesting to see how it's approached and even better to see some names who are still helping all of us today, thanks to Tom, Peter, Keith, Gerry.
Thanks for your guidance over more than 17 years.

 

[janner_10]

Depressing thing is, I won't be retired in the next 17 years!

 

[AustralIan]

Depressing thing is, I won't be retired in the next 17 years!

Are you leaving the UK before Brexit, then?

 

[Highland Controls]

Well, since someone else brought it up...


I think SFC's are great, once you fully understand them. Easy to troubleshoot, and if properly programmed can handle an E-Stop or process interruption at any step then pick up again where it needs to.

 

[James Mcquade]

just my 2 cents.

long winded, but I think it gets the point across.
it doesn't matter to me of you are an Engineer, OEM, systems integrator, independent contractor, or part time programmer.
what does matter is that you take care of the person paying the bill, your
customer.
I am an electrical engineer and have worked in industrial maintenance for 3 years. I worked for two different oem's over 12 years and can take the customer spec and give him a working machine that I did the electrical design, prints, manuals, programming, wiring, installation, and debug on. Sometimes the mechanical design as well.

what many companies don't realize is that any machine is a team effort. mechanical does their design and electrical does their thing. BUT, if the two do not meet and discuss their plans, it will be a big mess. been there done that with a mechanical designer. I finally had to discuss things on a first grade level relating to what the plc could actually do before he got the message. after that, things went very smoothly.

when programming, the programmer needs to find out what the customer's support staff (typically maintenance) can do. you can't write a program and document it in Chinese if the end users are American and only know english. you have to write it in a way that everyone can understand. work with maintenance and get their level of understanding, write the code, document it, write a good user manual, detailed mechanical/electrical/pneumatic/hydraulic prints, bill of materials. keep them in the loop and work with them as the machine is being installed and proved out. it has been my experience that those guys will bend over backwards to troubleshoot the problem before calling. when they do call, they have a real problem. installing a machine and saying here ya go is bad business, i'm going through that now, I have to write a manual for maintenance.

know your customer and the support staff, work with them, give good documentation, and life will be less stressful.

james

 

[Peter Nachtwey]

This old thread is about state machines, not engineers vs maintenance.
Our motion controllers use ST in a state machines. It seems that anybody with just a little programming skill can figure it out. LD is not very good for motion control. Yes, it is possible to make state machines in LD but is isn't always obvious as to how to do it when there are many ways. That is why we basically force people to use state machines and ST. From time to time we do get a request to have some ladder capability. I think LD would be OK for a back ground task but state machines are MUCH more efficient than LD. You can't have variable scan times in a motion controller. We don't get complaint about our ST and state machines. It seems people can adapt if the ST and state machines are implemented well. Those that can't adapt shouldn't be doing motion control anyway.


Ancient history

I joined this forum in 1999. I know it says 2002 but there were two other versions of this forum before the current 2002 version. The first ones were colored by blue and red ( actually kind of pink ).


I could have retired years ago but.....

 

[busarider29]

One more thing. There is a possibility of race conditions. To avoid that I often use two registers. One is the current state and the other is the requested state. When a state change is made the requested state only is changed. At the top of the ladder the requested state is then copied into the currecnt state. This makes sure that many states don't get executed in one scan.

WHY BOTHER?

I do a lot of motion control. One very common problem is that users often give the command to move and then check for the 'in position' bit to see if the axis as reached its command position. The problem is that too often the in position is checked before the PLC even has a chance to send the command to the motion controller. The in position bit hasn't even gone off because the axis hasn't started to move yet. This causes the statemachine to jump a head to the next state too soon.

The requested state/current state method make sure only one state is executed per scan.

Glad I stopped in to read this. Peter, thanks for the tidbit there. I think I "might" be experiencing a race condition on occasion with a motion program I'm currently working on, although I can't say for sure. Its written in ST though, not LD or SFC. I'm only using one integer for the state and incrementing/setting that for the next state after each MotionCommand.DN. Platform is TwinCAT (Codesys).

 

[Peter Nachtwey]

Glad I stopped in to read this. Peter, thanks for the tidbit there. I think I "might" be experiencing a race condition on occasion with a motion program I'm currently working on, although I can't say for sure. Its written in ST though, not LD or SFC. I'm only using one integer for the state and incrementing/setting that for the next state after each MotionCommand.DN. Platform is TwinCAT (Codesys).

Usually you don't want to execute two states in the same scan.

If I were writing a state machine in ST I would use a CASE statement. You may be able to get by with just one variable for the state. The CASE OF statement will ensure only one state or CASE is executed in a scan if you put a break at the end of each CASE OF.

You should wait for the .DN bit to go off then back on. This requires two states. Sometime the motion controller can turn the .DN of and on quickly so the PLC cannot detect the off on sequence. In this case on should at least wait one scan before checking the .DN bit.

We have had many PLC programmers call with the same problem.