Can automation equipment / PLC program use States

B

Bruce Durdle

According to IEC61131 Table 46, there are three variants on the divergence of sequence. All three use methods to ensure that only one of the divergent paths can be taken.

In the first, there is an inherent left-to-right priority of the transition evaluations. In the second, the priority order is explicitly assigned by numbering each transition. In these two methods, only one subsequent step is possible. In the third, the "user must assure that transition conditions are mutually exclusive". So the Isagraph implementation is only one of the three, and probably the least rigorous.
 
S
Vladimir,

In general, SFC has two types of path divergence: a conditional type in which each path is preceded by its own test (the type we've been discussing), and a multiple path type in which following completion of one single test, the first steps in ALL the divergent paths become enabled.

It no doubt varies slightly by implementation, but I’m familiar with ones in which the conditional type are indeed exclusive. In CoDeSys, for example, the test are performed in left-to-right order, so you must code them in order of decreasing precedence from left to right, because only the first path with a valid test is going to become enabled.

In fact, it’s almost hard to picture it being otherwise. Once one test is successful and the corresponding path enabled, for the other tests in the same branch to continue to be active would imply that the preceding step is still enabled to some extent, which it is obviously not because one of the following paths has been enabled. The only plausible scenario that I can imagine that would result in enabling multiple divergent paths would be on the first scan in which one of the tests is found to be true, to not stop testing immediately but do all the remaining tests (just one that one scan), enabling any paths following successful tests.
 
V

Vladimir E. Zyubin

> So the Isagraph implementation is only one of the three,
> and probably the least rigorous.

Bruce, I see. I am not use IEC 61131-3, and never read about these brand-dependent nuances in implementations of IEC 61131-3.

--
Vladimir
 
S
Vladimir,

Bruce's point was that in general there is a mechanism, whether built in or put there by the programmer, to ensure only one branch of a alternative divergence group is enabled.

And you can't really take issue with some theoretical definition of SFC, because if you use SFC on any real application, you'll have to do so using some commercial product, and then the brand-specific nuances will become just as much grist for that decision mill as any theoretical definition. (in some cases no doubt moreso).
 
V

Vladimir E. Zyubin

> Bruce's point was that in general there is a mechanism,

Steve,

I do understand the point Bruce write. The thing I can catch is why does the "inclusive" divergence feature present in IEC 61131-3... as for IEC 61131-3.

As for the strategy Bruce sounds, I really would like to read how does the implementation look like for the case of hierarchically structurized and/or simultaneous algorithms. If it is possible in practice, of course...

> And you can't really take issue with some theoretical definition of SFC, because if you use SFC on any real
> application, you'll have to do so using some commercial product, and then the brand-specific nuances will become just
> as much grist for that decision mill as any theoretical definition. (in some cases no doubt more so).

Just a remark: I personally prefer to name the "theoretical definition" as IEC 61131-3 standard.

--
Vladimir
 
S
> As for the strategy Bruce sounds, I really would like to read how does the implementation look like for the case of
> hierarchically structurized and/or simultaneous algorithms. If it is possible in practice, of course...

I believe I have some of the 3S/CoDeSys docs I'd be happy to send you (or possibly links), if you post your email address.

> Just a remark: I personally prefer to name the "theoretical definition" as IEC 61131-3 standard.

I have no objection to that, except to note that SFC is not a creation of IEC 61131, and that therefore the IEC has not the right to assume they can write a binding definition of it. They simply define it for people interested in saying they have followed that standard.
 
V

Vladimir E. Zyubin

> I believe I have some of the 3S/CoDeSys docs I'd be happy to send you (or possibly links), if you post your email address.

As I understand the strategy under question is just Bruce's local programming/coding standard. So, reading CoDeSys's implementation of IEC 61131-3 can not enlighten me on the topic. But if you think it can help, my e-mail is v dot e dot zyubin at mail dot ru.

--
Vladimir
 
I've read the replies and wanted to add ...

My background is digital logic design (hardware) with complex state machines typically implemented in PLDs and or FPGAs (telecom applications). The two main programming languages used are verilog and VHDL. These languages are similar to C in syntax but all of the logic (Flip flops) execute simultaneously rather than sequential step by step nature of traditional computer programming language. The vendor tool packages (Xilinx, Altera, etc.) handle the timing and fitting into the PLD device.

I am familiar with Ladder logic and Function Block Diagrams PLC programming. I have shown students how to program state machines using ladder logic with LogixPro simulator. State machines make an abstract difficult programming problem very deterministic and solvable on the first attempt, however troubleshooting by elec/maintenance personel is much more complex if they don't understand the state machine logic flow.

My questions for those with industry experience - Would your company prefer complex state machines designed in a systematic method that was very reliable but more difficult to debug on the shop floor?

Just curious.
Thanks,
Jonathan
 
I'm using ladder logic for low level control and state machines for upper and top. It is much better than only LAD. I just started line and it runs - only 2 lost pieces for setup and production could begin. Customer can't believe his eyes, newer seen something like this..
I'm using little obsolete but good tool HiGraph.
 
K

Ken Emmons Jr.

You might want to start a new thread (this one is a year old).

What you have to understand about ladder is that everyone has a preferred method of doing things and it sometimes depends on what controller they started with, or what training they had to start out with. Having said that I feel that a traditional state machine like I learned in digital design would be severely overkill for ladder programming. Here are some methods I've seen used and/or have used myself:

1) Sequence using Boolean "sets" and "resets" of auxillary relays (internal bits) (or latch/unlatch if that is what you are used to).

Note that I've drawn the output statements next to each other. In some PLCs these would be in a vertical row. This is easier to type for me so I'm doing it this way.<pre>
----|M0 |-----------<logic here>-----------------(set M1)-(reset M0)----
----|M1 |-----------<logic here>-----------------(set M2)-(reset M1)----
----|M2 |-----------<logic here>-----------------(set M3)-(reset M2)----
----|M3 |-----------<logic here>----------------------------(reset M3)----</pre>
Disadvantages are that you have to edit three statements to insert a rung into the sequence which ripples down to all subsequent steps.

2) Sequence using counter compares (my preferred method)<pre>
---|Step == 1|------------<logic here>----------------(increment Step)
---|Step == 2|------------<logic here>----------------(increment Step)
---|Step == 3|------------<logic here>----------------(increment Step)
---|Step == 4|------------<logic here>----------------(set Step:=0)</pre>
This method has the advantage of only having to re-sequence the left hand step equality constants if you insert steps into the sequence. What I also like about this method is that you can name your step counter by the action is is doing if you want to jump around. This gets rid of having to do bad programming equivalent to "goto line 8" which, if you are familiar with any modern software is a big no-no. Here is an example (This one is a bit tougher to draw in ASCII ladder!):<pre>
---|Step == 1|------------<logic here>-------------------------------(increment Step)

---|Step == 2|-------|Not SomeFault Bit|--------------------------(increment Step)
| Some Fault Bit|-----------(set Step:=0)---(set FaultStp:=1)

---|Step == 3|------------<logic here>-------------------------------(increment Step)
---|Step == 4|------------<logic here>-------------------------------(increment Step)
---|Step == 5|------------<logic here>-------------------------------(set Step:=0)</pre>
As you can see if a fault bit/relay is set then the current sequence is stopped and the fault sequence is started. To me this is a much more useful and safer version of "GOTO". If a hardcore C programmer saw this they would be scratching their head at this, but in ladder it is a reasonable way of bringing order and sequence to the scanning nature of the controller.

I have also heard of using timers to sequence through (a variation of my #1 approach). As many of my machines use switch feedback as opposed to timers I tend not to use that method.

KEJR
 
B
Schneider Electric PLCs that support UNITY software provide SFC logic programming. Sequential Function Chart is true state programming with many options.

Visual presentation, with animation and forcing and multiple state and transition options.
 
V

Vladimir E. Zyubin

Hi, Jonathan

We are just teaching student to program with the Reflex language and explain common approach of implementation in process-oriented programming, so they become familiar with the domain specifics and can choose the means depending on the task.

BTW, state machine model is not complex, just it implementation is complex (easy lead to error), especially during modifications. And the terminology is obsolete. But any DSL-support (with adequate conceptual framework) solve the problem.

As to LD and others FBDs... Hgm.. thanks to the IEC 61131-3 authors. :)

--
best,
Vladimir

TA> My questions for those with industry experience - Would your
TA> company prefer complex state machines designed in a systematic
TA> method that was very reliable but more difficult to debug on the shop floor?
 
Top