Sequential Control (was Updated PLC Book on-line)

M

Thread Starter

Michael Griffin

At 13:49 08/08/01 -0400, Anthony Kerstens wrote:
<clip>
>We have a difference of _opinion_ on programming style.

I am interested in your opinion, which is why I am writing.

>I prefer to
>use plenty of documentation in my logic to segregate sections of code
>and memory (as well as make use of AB's file provisions, when programming
>AB).
>I manage to create complex, yet highly organised programs in this manner,
>and so I neither see a need nor do I prefer to use L's and U's.
<clip>

How exactly do you typically control a sequential operation? I will
briefly describe a hypothetical application which we can use as a reference
problem:

1) A single sequence of 15 steps.
2) The sequence controls roughly half a dozen pneumatic valves, and
reads a dozen cylinder switches. Consider the machine to be some form of
pick and place with some additional devices associated.
3) Several of these steps (say 7 and 8) must be able to be repeated
an arbitrary number of times (a form of looping). The number of times these
steps are repeated will depend upon the product being manufactured (looping
a variable number of times).
4) The sequence must be able to be "aborted" (a form of branching)
at certain steps. (E.g. jump from step 6 to step 10). This may be due to
information discovered during the cycle, or due to operator intervention.
5) Manual control consists of allowing you to single step the
sequence in forward or reverse in the normal sequence of operations.
Auto/manual transfer can happen at any point in the sequence.
6) A special "set-up" mode allows you to control one or two special
elements of the machine in an arbitrary fashion, while still allowing the
normal sequence of operations to be resumed at any time. This form of
discrete manual control is limited, in that it isn't allowing any states not
normally assumed by the standard sequence.


I think the above example would cover most of the typical situations
encountered. It covers, sequential operations with looping, branching,
single step manual, a special "set-up" mode, and modifying the sequence
behaviour according to stored information or conditions sensed during the cycle.

What is the method you find most suitable for controlling the
sequential function of machines such as the one described above? I have seen
a number of different methods - I've used a number of different methods.
What would you consider the best one to be, and why? What would you consider
the worst one to be, and why?

If anyone else besides Mr. Kerstens would like to express their own
opinions I would welcome that as well. But please, let us not have any
suggestions of grafcet or flow charts. That would be cheating!


**********************
Michael Griffin
London, Ont. Canada
**********************
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Mr. Griffin and all:

For a very simple sequence control, refer to Structure.pdf on the PLCArchive (www.plcarchive.com). This example uses (gasp) Latch and Unlatch outputs. &lt;grin>

For more complex scenarios as you describe, I use an integer register that controls what step the cycle is on. As each step in the process is
completed, the "step number" is changed to the next logical step. This acts very much like grafcet, but is done with ladder. I initially write the program using increments of 10, that way it is easy to insert steps when the process changes. (Old habit learned while writing BASIC programs on my Commodore 64.)

The first part of the file is nothing more than:

EQU N7:100 50 XIC B3:1/1 MOV 60 N7:100

Where N7:100 is my Step register,

B3:1/1 represents one or more conditions that would indicate that step #50 is finished.

The MOV at the end increments me to the next step.

Looping would be done by having multiple rungs check for step 50, one rung would move me back to step 30 if the counter was not done, the other would move me to 60 if it was.

Set-up functions are usually performed in steps 10 - 90. that way I can use my first scan bit to set all step registers to 0. Also, fatal faults
reset the step register to 0. When the process is allowed to restart, it sequences itself up naturally to a ready state at step 100. No special flow methods are needed for this initialization, as it flows just like the rest of the program.

The second 'section' of the ladder file is the conditions themselves. This is where the counters for loops would be located, timers, etc. If I need to loop steps 100 - 150 10 times, I would have a counter fire every time my
step register reached 150. If the counter was done, section 1 would go to step 160, if the counter is not done, it would move back to 100.

Section 3 of the ladder file ties the step register to the outputs. Want to know when output O;3/5 comes on? Go to this section, and you can see that steps 150 - 190, step 250, and step 330 turn on the output. If it is on now, a quick look at N7:100 will tell you what step you are on. This not only can be made into a very easy to understand cross reference for
documentation, but the step number can be put onto a display for looking up in a manual, or even better, the step number can be used as an index into an online help file that, when a button is pressed on the HMI, will call up all the info available for that step number, including actions that occur at that step, and conditions for moving on beyond that step.

In very simple projects, error detection is Section 4 of the ladder file. For projects with more than 3 or 4 ladder files, tho, I usually put all the error detection in a seperate file. This is similar to Java's exception handling. In my opinion, having the error detection inline with normal operational code is distracting. Plus, I find it easier to have all the error conditions grouped together in one file, rather than spread through out the program.

Manual operation as you describe is easily done, simply by having your manual mode switch inline with all your automatic increments, and your Step
button simply moves the next value into the step register, either up or down.

I hope that you find this helpful. This is getting pretty long, so I will stop here. If there are any questions, let me know. I have not yet encountered a sequential operating machine that this did not work well for.

--Joe Jansen
 
G

Gilles Allard

Michael wrote:
> What is the method you find most suitable for controlling the sequential
> function of machines such as the one described above? I have seen a
> number of different methods - I've used a number of different methods.

I'm a grafcet aficionado but I sometimes accept to write ladder-logic programs. Here's my way:

First portion of my code is a dispatching logic. It look at the actual internal state (step) and decide of the next step. I often use a numeric variable for the step number so I only have to
change a single variable to move from one step to another (very useful for debugging). For those who know computer programming, you can view this first portion as 2 nested switch (case) statements; the first is based on internal state while the second is looking at events.

The second portion is the actual logic handling (the step code). Each step has it's own code (typically a few ladder rungs) reached thru a goto (jump) in the dispatch section. Logic in this
section act on internal coils (no physical outputs).

Last section handles (physical outputs) according to internal coils. Interlocks are handled in this section. Grouping all outputs together in this section is appreciated by people involved in debugging.

That's my way but I understand there are others. There is one caveat: since I use jumps, internal coils from other steps keep their old value and they therefore act as latches. This is bad (see another popular thread on this list). To solve this problem, I generally clear all of them in the first section.

By the way Michael, I know you are a Siemens user. What do you think about Graph7? It enables you to step thru a graph and (amazing) to resynchronize a graph with the physical world.

I hope this help.

Gilles

 
A
I programmed an application just like it, for a boiler feedwater plant. I use a integer as a counter, and increment it as condition permit. The value of integer points to the present step. If there is a need to jump or repeat the step or steps, just move the step number to it.
 
R

Rick Jafrate

Implement a state machine using ladders, it's clumsy but is very readable, easy to maintain, easy to debug, etc...

1. First split the sequence into operations/functions that make sense to the operator. Each of these functions/operations is assigned to a state. States are selected similar to car radio buttons. Each state is represented by a coil.

2. Each state has a series (sequence) of sub-states, let's call them steps. Each step of each state is represented by a coil. There is a terminal or target step in each of the state sequences.

3. Only one State and one step can be active at a time.

4. State coils are used to activate the state's step (substrate) coils. Step coils are used to activate actuators.

I attached a little example to show what such a thing would look like. I don't really know any other way I would attempt to implement sequential logic. Am I cheating by implementing a simple GRAPHCET using ladder language ?

regards

Rick Jafrate
Mitek

=================================
Top Level State Transitions
=================================
Transition to State-1
PB1 S2 S3 S1
---] [-+-]/[---]/[------------()
S1 !
---] [-+
Transition to State-2
PB2 S1 S3 S2
---] [-+-]/[---]/[------------()
S2 !
---] [-+
Transition to State-3
PB3 S2 S1 S3
---] [-+-]/[---]/[------------()
S3 !
---] [-+

=================================
State-1 Sub-states
=================================
Step-1
S1 S1_1 S1_1
---] [-+-]/[-+----------------()
S1_1 S1_2!
---] [---]/[-+

Step-2
S1 S1_1 S1_1_Complete S1_2
---] [-+-] [-+-] [------------()
S1_2 S1_3!
---] [---]/[-+ :
:
Target Achieved :
S1 S1_N S1_N_Complete S1_Target
---] [-+-] [-+--] [-----------()
S1_Target !
---] [-------+

=================================
State-2 Sub-states
=================================
Step-1
S2 S2_1 S2_1
---] [-+-]/[-+----------------()
S2_1 S2_2!
---] [---]/[-+

Step-2
S2 S2_1 S2_1_Complete S2_2
---] [-+-] [-+-] [------------()
S2_2 S2_3!
---] [---]/[-+ :
:
Target Achieved :
S2 S2_N S2_N_Complete S2_Target
---] [-+-] [-+--] [-----------()
S2_Target !
---] [-------+

=================================
State-3 Sub-states
=================================
Step-1
S3 S3_1 S3_1
---] [-+-]/[-+----------------()
S3_1 S3_2!
---] [---]/[-+

Step-2
S3 S3_1 S3_1_Complete S3_2
---] [-+-] [-+-] [------------()
S3_2 S3_3!
---] [---]/[-+ :
:
Target Achieved :
S3 S3_N S3_N_Complete S3_Target
---] [-+-] [-+--] [-----------()
S3_Target !
---] [-------+

=================================
State Actions
=================================
Target Achieved
S1_Target Target
---] [-------+-----------------()
S2_Target !
---] [-------+
S2_Target !
---] [-------+

Do something ...
S3_1 Actuator_1
---] [---+---------------------()
S2_2 !
---] [---+
S2_3 !
---] [---+
S2_5 !
---] [---+

Do something else ...
S1_1 Actuator_2
---] [---+---------------------()
S1_2 !
---] [---+
S1_3 !
---] [---+
S1_Target!
---] [---+


 
B

Bruce Durdle

This question, I think, is the major one we are going to have to face in the future (apart of course of the perennial question of how to get
Manufacturer A equipment to talk to Manufacturer B controller - or even to Manufacturer A last year's model ...). How can we analyse an application and turn the requirements into a complete, concise and unambiguous Functional Specification of what the control system is to do?

It is easy for anyone to cobble together a program of sorts that will work after a fashion, We have all sat at a PLC programming panel or PC and put networks together. We have probably managed to follow a fairly complex sequence as prescribed in an instruction book. It's not too hard.

The fun starts when you start to ask "What if ..." What if the actuator doesn't extend? Or did the actuator really extend but the sensor failed to pick it up? What if the sensor was forced into an active mode so that it indicated stroke complete before the actuator had moved? These are not usually in the book. Ask the equipment designer about failures and you get
some really funny looks - "My design isn't going to fail!!!!"

I have found the best tool for specifying conotrol system behaviour with complex sequences is some form of State Transition approach. Start with power off - define conditions for all controlled outputs - this is the failure mode. You will move from this when power comes on - so that defines the transition condition. Usually after power is restored move to some form of fault indication state, and from there a manual reset will take you to standby.

A "Start" pushbutton gets you into the sequence proper - which can be broken into steps, with actions in each step defined, "valid" transitions
as defined for the sequence specified, and you can then look at the "What if's" for each state as well.

As a check - the process must follow a path under any conceivable conditions that will eventually return to its beginning - I call it the
Operational Cycle concept. If you send a command to a motor to start, you must send another comand to stop the motor before completing the cycle by
whatever path. And don't forget about sensor failure - I came across a PLC program once where an auxiiliary lube oil motor on a compressor was started as the first step in the sequence. The program designer assumed that the only reason the
oil pressure permissive for the next step would fail to make would be if the motor failed to start - so he didn't bother to stop it. Consequence - when the oil pressure switch failed, the compressor casing filled with oil
and it started coming out along the shaft.

Sounds a lot like developing a Sequential Function Chart, doesn't it? Funny, that! Now, in parallel with that, I need to be able to operate a shutdown system using AND and OR-based combinational logic. When will we get full access to systems implementing the complete IEC61151-3?

Bruce.
 
M

Michael Griffin

There were a number of replies to my question about sequencing methods. Interestingly, most of them (at least as I understand them) seem to be variations on a method I know as "bit latching". The "compare to integer" method described is really just a variation on this. It is just using an integer compare instruction instead of a contact instruction to define the
"state". I would like to thank to Mr. Jansen for having posted a code sample in the PLC Archive. I found it very useful in understanding his explanation.

I will describe what I think is a typical method used. I will then describe what I think is a better way. I would like to invite criticism of
it to see how it can be improved. First however, I will define the criteria which I think are important.

1) The method must provide an inherent method of arranging the program in an order representative of the machine sequence.
2) All the logic for any particular step should be grouped together, rather than intermixed with logic from other steps. For any particular step, everything which happens in that step should be immediately visible in one
location.
3) It must support sequence branching and looping.
4) It must support diverging and converging parallel sequences. That is, it must easily support a means for a single sequence to divide into two (or more) parallel sequences which execute independently, and then join up
again.


Typical Sequence Structure for Method 'A':
i) Sequence transition logic for all steps.
ii) Sequence input logic for all steps.
iii) Sequence output logic for all steps.

As each input condition is met, the next step bit is latched, and the previous one unlatched. Each output is controlled by constructing a rung in which the various step bits are 'ORed' to determine when to turn the
rung. Steps which are not referenced for that output implicitely turn it off.

Variations on 'A':
- Instead of latching and unlatching bits, different constants are moved into a word, and integer compare instructions are used to determine which step is currently active. Writing a constant to the sequence word will cause the sequence to branch to an abitrary step. This handles 'jumps' and looping.
- Alternatively, a single bit is shifted through a word. As the '1' reaches each bit position, the corresponding step becomes active. Writing a constant to the sequence word will also cause the sequence to branch to an aribtrary step.

Problems with 'A':
It satisfies criteria #3 (looping and branching), but not #1 (arranging in order of sequence) or 2 (all logic for each step together).
The variation which latches and unlatches bits can be made to support criteria 4 (diverging and converging parallel sequences). The integer
compare and bit shift methods do not readily support parallel sequences.



Method 'B':
i) Each step consists of a repeated code pattern:
- Set states of all outputs for step x.
- Activate timers, counters, other logic related to step x.
- Compare input states for step x.
- If transition conditions are met, unlatch bit for step x,
latch bit for step y.

ii) The code pattern described above is repeated once for each step or state.
iii) Timers, counters, etc. related to that step can be inserted in between the outputs and inputs.
iv) Each rung in a step is prefixed by a contact which examines the bit for that step, ensuring the logic is only active during that step.
v) Since outputs are addressed in each step, they must use latch and unlatch instructions to prevent the different steps from interacting.
vi) Some types of PLC provide special instructions which support this method more directly.
vii) Outputs can be set conditionally. For example, a step can decide whether to extend a cylinder depending upon some previous condition, or upon some internal parameter.
viii) A variation on this method uses a series of subroutines, with one subroutine for each step. Only the active subroutines (steps) are scanned at any time.


Advantages of Method 'B':
All four criteria listed above are met completely. The code patterns can be arranged in sequential order (#1). Each step can contain all the logic for that step in one location (#2). It supports looping and branching (#3) as logic for each step can define which bit it will latch next. It supports parallel sequences (#4) as you can latch and unlatch several bits at the divergence and convergence points in the sequence.
The basic structure of this method is modelled after Grafcet, but written in ladder logic. Like Grafcet, it uses the "set output" / "examine input" / "transition" code sequence. Like Grafcet, the "step/transition"
pair is the fundamental unit of organisation for grouping logic.


Other Methods:
I noticed that nobody mentioned drum controller emulators (i.e. AB style SQI, SQO). I have had a fair bit of experience with these, and I never want to see another one. I believe that they are completely unsuitable for anything except trivial programs. They are difficult both to write or to reverse engineer. The programs tend to be much more complicated than they
need to be.
Fairly often the application is force fitted into the "drum controller" mould, resulting in limited machine functionality and plenty of bugs.



**********************
Michael Griffin
London, Ont. Canada
**********************
 
A

Anthony Kerstens

Michael,

Regardless of the hypothetical application, I would avoid the use of L's and U's.

L's should not be used for control, and the sequence you mentioned is control. As for the method, I would define general bits such as:

Sequence Start Permissive,
Sequence Start Command,
Sequence Complete Status,

Sequence Step 1 Start Permissive,
Sequence Step 1 Start Command,
Sequence Step 1 Complete Status,

etc.

From there, specific details depend on how the customer has defined the process, and how your system is interfaced to the process.

This does not require bits to be retentive. Simple latching logic is sufficient.

Anthony Kerstens P.Eng.
 
J
I tend to see these as basically the same, but in a different arrangement. I do not see Item #2 as a requirement, per se. Obviously it needs to be
readable, but I prefer to be able to follow the 'outline' of program execution from rung to rung without needing to jump over the conditional
code unless I see a problem in exectuion.

The method I described earlier may have difficulty supporting #4. Not impossible though. It would need to spawn another ladder file executing.

Typically in a large program, I have a main loop that executes, and fires off "action requests" to the other processes. These processes are blocked
at the action request, and when recieved via internal bit, it executes it's process once, and then waits for the machine to reset and loop again. Most machines can be defined as a cycling loop, so this isn't to difficult of a task. Continuous flow machines run somewhat differently, but can be adapted.

In summary, I do not see a lot of difference in the two methods you describe, other than how they are arranged sequentially. I do have 1 question about method B. If I have an output that needs to come on for, say, steps 1, 3, 6, 7, and 10 of a 15 step process (for example, a glue nozzle on a case former), how do you handle the multiple occurances of the output instrucction? Most (all?) PLC's I have worked with either
specifically disallow multiple reference to an address with an output instruction, or, if allowed, simply use the state of the last occurance.
Do you use latching/unlatching instructions? (please say no), or do you map to an internal table, then combine them to the output somewhere else? Doesn't the process of having to combine this output from multiple program "blocks" as you describe below add a layer of confusion? Or have you solved this somehow, and how?

--Joe Jansen
 
V

Vladimir E. Zyubin

Hello Michael,

I am sorry I can not catch the point...

Why do you try to find a solution of the well-known problem in LD terms?

Yes, any algorithm could be described via two commands only: "increment" and "jump if zero". But who will use it in practice?

There is a lot of quite adequate means for the task in question in the world. State languages, for example... They were made for sequential control.

Well, LD is being "positionated" by vendors as a simple mean we can use without any knowledge. But this firstly means that LD has limitations of using.

For example, imagine usability of chisel and hammer (as very simple tools) to perform an operation with eyeball... no use but amputation.

There are different tasks and there are different tools.
IMO.

With best regards. Vladimir
 
M

Michael Griffin

Gilles Allard wrote:
&lt;clip>
>By the way Michael, I know you are a Siemens user. What do you
>think about Graph7? It enables you to step thru a graph and
>(amazing) to resynchronize a graph with the physical world.
&lt;clip>
We have been looking at it for several years, but are concerned about one characteristic of the method Siemens used to implement it.
Essentially, you create your Grafcet chart, and compile it into statement list.
According to Siemens, you cannot reverse this process unless you have the original source code. In other words, it depends very heavily upon
the customer being able to exercise very close control over the source code. This can be difficult, especially when dealing with outside contractors or OEMs. If the source code is lost, or cannot be trusted, then (according to
Siemens) you have to re-write your program. You would only get (incomprehensible) statement list if you try to upload from the PLC.

This is not a problem with Grafcet itself, just the way which Siemens has implemented it as an add-on "engineering tool". If this problem could be solved, then our preferred programming method would be Grafcet. It
is possible that we have been mis-informed by Siemens about this, but they seemed quite sure of themselves whenever we asked.

Have you been using Graph-7, and if so, what do you think of it?


**********************
Michael Griffin
London, Ont. Canada
**********************

 
M

Michael Griffin

At 12:50 13/08/01 -0400, Bruce Durdle wrote:
&lt;clip>
>This question, I think, is the major one we are going to have to face in
>the future &lt;clip>
...
>How can we analyse an application
>and turn the requirements into a complete, concise and unambiguous
>Functional Specification of what the control system is to do?
&lt;clip>

The reverse is also true. How do you analyse a program to see what was implemented?

>And don't forget about sensor failure - I came across a PLC program once
>where an auxiiliary lube oil motor on a compressor was started as the first
>step in the sequence. The program designer assumed that the only reason the
>oil pressure permissive for the next step would fail to make would be if
>the motor failed to start - so he didn't bother to stop it. Consequence -
> when the oil pressure switch failed, the compressor casing filled with oil
>and it started coming out along the shaft.
<clip>

I think that sometimes people don't handle errors and exceptions properly because these complications don't fit into the simple sequence model they are using. A sequence step has to include timers, counters, and various complex handshake logic. If this stuff is just tacked on around the outside of the sequence, it is not obvious what is there and what is missing
or how it integrates into the overall machine operation.

**********************
Michael Griffin
London, Ont. Canada
**********************
 
N

Nijssen.Ronald

Several PLC types allow storage of the complete program, including sources, on a flash-eprom or ram module on the PLC.

Regards
Ronald
 
G

Gilles Allard

Hi Michael and everybody

> Have you been using Graph-7, and if so, what do you think of it?

I've used Graph-7 and I like it. I also looked at SFC (supplied with the PCS7 process control package). The biggest problem is that if you modify the Grafcet structure (add/delete a step or transition), you must regenerate the DB.
When you download your Grafcet will start at the initial step regardless the previous state. This means the amount of modifications is limited if you have to download while the machine is running.

> According to Siemens, you cannot reverse this process unless you
> have the original source code.

This is true. The sole solution is to implement a strict version control policy. But this problem is not strictly related to Grafcet; it applies to all compiled code ( for example, if you modify C code with a debugger in a PC) and even to ladder-logic comments (as posted recently by a OMRON user). The sole solution is to let only one body the right to modify the code at a single moment. All other bodies will have to wait or should communicate their modifications to the appropriate person. For the last twelve years, I've worked with APT (a compiler for TI PLC). Version control is a must. But once in place, it is a benefit for everybody. By the way, with APT, you can download Grafcet modifications
without restarting your graph. But there are some constraints if you modify the code of an active step.

A few epochs ago, I heard that Concept (from Schneider/Modicon) does not allow online changes. Can a Concept user confirm that this is still true.

Gilles

 
M

Michael Griffin

At 14:47 14/08/01 -0400, Joe Jansen wrote:
&lt;clip>
>I tend to see these as basically the same, but in a different arrangement.
>I do not see Item #2 as a requirement, per se. Obviously it needs to be
>readable, but I prefer to be able to follow the 'outline' of program
>execution from rung to rung without needing to jump over the conditional
>code unless I see a problem in exectuion.

The point of method B was that it did let you see the flow of the program. Method A required you to continually search through various pages just to see what happens at any particular point.

>The method I described earlier may have difficulty supporting #4. Not
>impossible though. It would need to spawn another ladder file executing.
<clip>
Criteria #4 (diverging and converging sequences) is the point where many methods fall apart. Interlocking separate sequences can be quite cumbersome and prone to bugs (especially dead locks) if not done properly.
However, both methods A and B can support this quite easily provided they latch individual bits to define states, rather than using the integer compare or shift register method. Both of the latter two methods are based on the assumption that the sequence has a single path of execution.


>In summary, I do not see a lot of difference in the two methods you
>describe, other than how they are arranged sequentially.

How they are arranged sequentially though is important to readability. The key to solving any large problem is to turn it into a number of smaller ones. With software, this is typically done by breaking a problem into a number of subroutines. Imagine each step as a separate
subroutine as independent as possible from the other steps. Indeed method B can even be implemented as actual subroutines if you are careful.

If you know that a problem exists at a particular point in the sequence, you need only look at the code segement (or subroutine) for that
step. You don't need to scan through dozens of pages of unrelated code with a pencil or highlighter to mark out the parts of the program which are related to your problem. You don't need to write pages of notes to integrate the various bits of the program into a picture of that step. Rather, it will be all in one place, right in front of you.

Why are people interested in Grafcet or flow charts, or other such methods? It isn't because they like the pretty pictures. It is because it provides a means of organising the program. Method B is a means of organising a program modeled after Grafcet.
I didn't invent method B. I opened up the manual for a new PLC and there it was - example programs illustrated in Grafcet with the ladder logic implementation shown beside it (this PLC didn't directly support Grafcet). I studied it, and thought about it, and realised that it solved a lot of problems. I tried it, and found it to be much easier than anything else I have done.

>I do have 1
>question about method B. If I have an output that needs to come on for,
>say, steps 1, 3, 6, 7, and 10 of a 15 step process (for example, a glue
>nozzle on a case former), how do you handle the multiple occurances of the
>output instrucction?

Each and every step uses latch and unlatch instructions to turn on or off all sequence controlled outputs. Every controlled output is addressed in every step even if it doesn't change state in some steps. This is
important to allow the outputs to be initialised at any arbitrary step.
If certain outputs are only manipulated in one step (e.g. trigger a weld control), then I will use a conventional coil instruction located in that one step. The coil instruction will cause that output to be disabled at all other steps. This seemed to be a reasonable compromise for these special cases.

>Most (all?) PLC's I have worked with either
>specifically disallow multiple reference to an address with an output
>instruction, or, if allowed, simply use the state of the last occurance.

That is odd, because I have never seen this. I have always been able to address an output as many times as I wished. If the output is addressed with a coil instruction, then yes the state of the last occurance of this will be what is transfered to the real world outputs. That is inherent in the "scan" model used by most PLCs. This is why you can't use coil instructions this way.

>Do you use latching/unlatching instructions? (please say no), or do you
>map to an internal table, then combine them to the output somewhere else?

Yes I use latch/unlatch instructions. I have so far been unconvinced by the arguements against them. The "map to table" method doesn't add any value, but it does make the program difficult to read. I have seen this done a few times for both inputs and outputs, and our electricians absolutely detest it. It only adds extra layers of incomprehensibility to a program.


>Doesn't the process of having to combine this output from multiple program
>"blocks" as you describe below add a layer of confusion? Or have you
>solved this somehow, and how?
&lt;clip>
If you looked at any particular program step, all the inputs are examined directly, and all the controlled outputs are set (or reset)
directly. Each step is a complete stand alone block of logic. It will execute correctly even if the other steps in the sequence are not present.
There are no layers to be traced from elsewhere in the program. If the step needs a dwell timer, you put it right there in the code block. If you are counting something, you put the counter there too. If you need a hand shake to an external device at that step, the hand shake logic goes in the step as well.

The basic organisation of each step is as set of rungs in the following order:
1) Latch or unlatch all the controlled outputs (this is generally done in one rung).
2) Activate any timers etc. that you need (this may or may not be present in any particular step).
3) Examine the inputs (and timers, etc.) to decide whether to transition to the next step.
4) When ready, deactivate the current step, and activate the next one (unlatch and latch the appropriate step bits).

Each step is defined to cause something visible to actually happen in the machine. There should be no extra "phantom" steps added just to help drive internal logic (as some people seem to be fond of).

Machine mode transfers (auto/manual/MCR off/stand by, etc.) are a centralised function whose states are examined by the steps, but this causes no problems with readability.
All machine states are explicitly defined as steps. PLC power-up logic has to decide which state (step) to enter upon power-up, emergency
stop, etc. (any method of course needs to do this). A special power-up step or state can be defined if necessary.

**********************
Michael Griffin
London, Ont. Canada
**********************

 
M

Michael Griffin

At 10:47 14/08/01 -0400, Anthony Kerstens wrote:
<&lt;clip>
>As for the method, I would define general bits such as:
>
>Sequence Start Permissive,
>Sequence Start Command,
>Sequence Complete Status,
>
>Sequence Step 1 Start Permissive,
>Sequence Step 1 Start Command,
>Sequence Step 1 Complete Status,
>
>etc.
&lt;clip>
How is the step state translated to the outputs? If I understand your explanation, the "permissive", "start command", and "complete status" are the transition logic. How do you actually say what to do when you are in any particular state, and where is this logic located? Are timers, counters, etc. located with the transition logic, or with the output logic?

>This does not require bits to be retentive. Simple latching
>logic is sufficient.
<clip>
I assume you mean "seal-in" logic rather than "latching" logic (you have just said you don't like latch instructions). I would by the way, not place any great trust in the re-start characteristics of any particular PLC (e.g. clearing particular memory areas). I have found them to not always work as advertised.
Seal-in logic which needs to reset on re-start (PLC power up, or stop-to-run) needs explicit re-start logic. If this is not done, then if a bit gets turned on during PLC power-up it can cause an unexpected logic state to be assumed. How do you handle this?

**********************
Michael Griffin
London, Ont. Canada
**********************

 
J

Joe Jansen/ENGR/HQ/KEMET/US

A very persuasive argument. I will give it a try on my next project. One last question:

Where do you handle error detection? Do you consider it part of the function block, or, like I do, a seperate process in a seperate ladder
area? I have found that including the error detection and timers, etc. in with the functional code is to distracting. Agree? or not, and (again) why?

--Joe Jansen
 
A

Anthony Kerstens

> At 10:47 14/08/01 -0400, Anthony Kerstens wrote:
> <clip>
> >As for the method, I would define general bits such as:
> >
> >Sequence Start Permissive,
> >Sequence Start Command,
> >Sequence Complete Status,
> >
> >Sequence Step 1 Start Permissive,
> >Sequence Step 1 Start Command,
> >Sequence Step 1 Complete Status,
> >
> >etc.
> <clip>

The complete status of one step may be used to initiate a start command of another step.
Other conditions may also be used to modify/initiate a start command.
The permissive usually is e-stop and modes.

Generally speaking, simple sequences run in a straight line to completion.
If a step must be run multiple times, then a master step may be set-up with counters/timers as required....

For example,
Step 1 (master step).
Step 1a (repeated step).


As for the start commands, they would be used by separate device control logic.
For example, a motor auto run command....

Motor run permissive.
Motor manual run command.
Motor auto run command.
Motor running status.
Motor o/l fault.
etc.
If multiple steps need to initiate a single device, then multiple
step start commands may go to the motor auto run command in parallel.

I do this because I don't like to drive outputs directly within the sequence logic. I need to have the separation between sequence control and device control because I find it allows my logic to be better organized.


> I assume you mean "seal-in" logic rather than "latching" logic

Yes, "seal-in". I often refer to seal logic as latching logic. The AB L is both latching and retentive. Modicon, for example, has a retentive coil, but to latch it you must still use a "seal".

> (you have just said you don't like latch instructions).

What I specifically dislike about the AB L is that the latch is retentive, and that L's and U's may be used anywhere with no limit to the quantity. In the rare instance that I must use
an L (like when something must be retentive), I place the U logic as a branch on the same rung with explicit comments about what is intended.

If I can find a way to do something without the L, I don't use the L.
And I always can find a way to do something without the L.

> Seal-in logic which needs to reset on re-start (PLC power up, or
> stop-to-run) needs explicit re-start logic. If this is not done, then if a


"needs explicit re-start logic" This is exactly the way I like it.

> bit gets turned on during PLC power-up it can cause an unexpected logic
> state to be assumed. How do you handle this?

1. Machine operation must be initiated by the operator.
2. I don't rely on logic states to monitor the state of the system.
I have the state of field devices to monitor the system.
3. Why would a bit that's not retentive be turned on during PLC power-up?

Anthony Kerstens P.Eng.
 
M

Michael Griffin

At 11:09 15/08/01 -0400, Gilles Allard wrote:
&lt;clip>
>I've used Graph-7 and I like it.
&lt;clip>
>> According to Siemens, you cannot reverse this process unless you
>> have the original source code.
>
>This is true. The sole solution is to implement a strict version
>control policy. But this problem is not strictly related to
>Grafcet; it applies to all compiled code ( for example, if you
>modify C code with a debugger in a PC) and even to ladder-logic
>comments (as posted recently by a OMRON user). The sole solution
>is to let only one body the right to modify the code at a single
>moment. All other bodies will have to wait or should communicate
>their modifications to the appropriate person.
&lt;clip>

Even if we manage to have a very good internal source code control system, it won't help us when dealing with the machine OEM or anyone else from outside our company. Most of them (and especially their subcontractors) are very poor at handing over the *correct* version of the program for their machines. Even if they do, they usually take months to deliver a finished
documentation package. Third parties brought in later are even worse (and we ourselves are not all very thorough either).

What I need is a guarantee that if someone (including me) didn't do his job properly, we can at least upload a *readable* copy of the program to salvage the situation. There have been cases in the past with used machines where we have had to trace out wiring, create our own schematics, upload the program, and recreate our own symbols. One of the big advantages of PLCs is that you can normally do this if you have to.

The more I look at the S7-300, the more convinced I am that it was designed by a comittee of computer engineers, and not by people who actually use PLCs. I won't bore you with examples, but I have been seeing far too many cases of there being no simple or obvious means of performing normal PLC functions (and I am not just referring to the programming software).

I like the *idea* of Graph-7, I just don't like the way they implemented it. I think it should have been one of the basic, fundamental
features of the PLC design. If the basic system software had been designed with Grafcet (or other graphical programming systems) in mind, I don't see any reason why a program couldn't always be reverse compiled. The basic step/transition structure of Grafcet is so simple and limited, that a few formatting instructions would give a reverse-compiler enough hints to reconstruct any graph.

**********************
Michael Griffin
London, Ont. Canada
**********************

 
R
> If multiple steps need to initiate a single device, then multiple
> step start commands may go to the motor auto run command in parallel.
>
> I do this because I don't like to drive outputs directly within the
> sequence logic. I need to have the separation between sequence control
> and device control because I find it allows my logic to be better > organized.

As far as I'm concerned there is no other way. Thanks, It's good to know that I'm not as strange as I thought.

> If I can find a way to do something without the L, I don't use the L.
> And I always can find a way to do something without the L.
>
> > Seal-in logic which needs to reset on re-start (PLC power up, or
> > stop-to-run) needs explicit re-start logic. If this is not done, then if a
>
> "needs explicit re-start logic" This is exactly the way I like it.

It seems to me that retentive bits are only useful in the case of power down. Why would anyone assume retentive bits to be in the correct state on power-up.

> > bit gets turned on during PLC power-up it can cause an unexpected logic
> > state to be assumed. How do you handle this?
>
> 1. Machine operation must be initiated by the operator.
> 2. I don't rely on logic states to monitor the state of the system.
> I have the state of field devices to monitor the system.
> 3. Why would a bit that's not retentive be turned on during PLC power-up?

To repeat what Anthony just said "The control system must analyze the initial condition of the equipment being controlled as can be measured by current inputs to establish appropriate logic states. No assumptions can be made about previous logic states. Attempts to avoid this analysis by using previous logic states will, sooner or later, result in disaster.
 
Top