S7 Sequence Programming Solution ?

Hi again,

Here is the situation.....


I have now created function blocks for all my equippment in my Robot cell.. Pick and placer, Magazine feeder etc etc.. everything has its own FB.

Now I need som sort of MASTER funktion that can step FWD and call my funktions when they are needed in the sequence.

Im going to have two diffrent mounting sequences.. Mounting A" and Mounting B"..

In my head i can see two FC´s ... one FC for mount A" and one FC for Mont B" IF the operator has choosen A" that sequence will start mounting A" and so on...

Now The BIG Question is... Shall I use an Integer that gets a new "STEP" number after each sequence step it has executed in the process ? OR ? whats should you use ?? hmmmm...


Would need some help in brain storming in this.. I have very little experience in Sequence programming..





Jim M

Hi
The simplest way would be to use an integer for the step number and a load of 'equal' instructions to generate active step coils (these could be in a DB of course)

Then use active step coil plus interlocks to drive outputs, and step coil plus feedbacks to step up.

Cheers

Okey..

I think i undestand what you mean..

I can Create an DB wich contains an integer that i can USE in my FC.
example: IF one function has done its work, i can add 1 to the STEP" integer.. Lets say that the integer was = 10 before the instruction.. And then after the instruction is ready I add +1 . Then the STEP integer will be 11.. And in the next instruction i compare the Integer with 11.. IF Step integer = 11 then carry out next step.. and so on..

Does this sound like something ?

That's indeed basically how it's done. Good advice: Initially use stepnumbers 10,20,30,40,... That way you can easily insert new steps if during real life testing you suddenly realize you forgot something...

There are also some relative simple techniques to turn the active stepnumber into active stepbits. (Create an array of bools and set the bit that corresponds with the active stepnumber). That way you can use simple boolean logic for you activations.

One more Thing that you need to aware of when writing sequences this way is to use an InputStep register and an OutputStep register.

To test if a step is active use the InputStep Register e.g.

If InputStep = 10 The Step10 = True

When looking for a transition, set the next step value in the Output Register e.g.

If Step10 = True && Transition10 = True then OutputStep = 11

At the end of the sequence, transfer the OutputStep register to the InputStep Register e.g.

InputStep = OutputStep

Using the above method has two real advantages: 1) each step is active for at least one program scan so that its state can be evaluated eleswhere in the program. 2) Only one step is ever active in one scan so that the sequence doesn't zip through 10 steps in one scan.

Hope this is helpful to you.

Nick

Hi, yes, you got the general idea, and what Manglemender said is good idea also.

Rather than add '1' I would do a move instead. That way you can jump around steps more easily if you ever need to.
For example you may wish to repeat a step during a sequence to save on coding and testing

kinda like steps 1-2-3-2-4-5-2-6-7-8

Not pretty but sometimes useful

As for the DB something like

DBxx.STEPNUMBER
DBxx.STEP1_ACTIVE
DBxx.STEP2_ACTIVE
....
DBxx.STEP1_DONE
DBxx.STEP2_DONE
.....



Cheers

1. I use 100, 200 as base steps to give myself room for small changes to the structure on the fly

2. I use named states with transition bits. i.e. S100, S200, S300 for states 100, 200 and 300 and T100T200, T200T300.... for the names of the transitions. You can use the same terminology on a state diagram, which makes for a nice connection between documentation and code that is not normally present.

3. Use integer-based state logic (i.e. if transition then move X into state machine state number). This ensures that you can never have the disastrous situation of having the system in two or more states, and ensures that any problems can only be in state actions or transitions. At the end of the state logic you can then set a bit indicating the active state for use in the running logic. Make never having more than one state per scan a priority.

4. Make sure that not more than one state transition can happen per scan.

5. Make a general-purpose state timer that is reset every state change. You can use this for simple time-limited states and to check for states that have not completed correctly.

6. Keep a history of the last 3 state changes to help you track weird jumps in state logic too fast to see. A number-1 troubleshooting problem with state machines is states that jump or execute for only one scan.

7. Implement transition diable bits for testing to allow you to hold the system in a particular state

8. Use an off state that does nothing but reset all actions, and a fault state that causes to system to come to a stable stop when a fault occurs. Alternatively, have a failure state for one or more other states that is stable during foreseeable errors.

If you want to use selective steps (becouse of speed of the program) see help on this instruction in STL:
JL

Example

STL Explanation
L MB0 //Load jump destination number into ACCU 1-L-L.
JL LSTX //Jump destination if ACCU 1-L-L > 3.
JU SEG0 //Jump destination if ACCU 1-L-L = 0.
JU SEG1 //Jump destination if ACCU 1-L-L = 1.
JU COMM //Jump destination if ACCU 1-L-L = 2.
JU SEG3 //Jump destination if ACCU 1-L-L = 3.
LSTX: JU COMM
SEG0: * //Permitted instruction
*
JU COMM
SEG1: * //Permitted instruction
*
JU COMM
SEG3: * //Permitted instruction.
*
JU COMM
COMM: *
*
Regards Mitko

Hi ,

I have always found S7-Graph the easiest and most Dependant for complex sequences. Using the transitions from the processes.

What you can do is call the Graph FC the instance DB that is generated for this FC will already have loads of use info for program control including S_No which is already your step number

So you can use this .Attribute DB.S_No and jump to your relevant program when in a certain step.

R

RheinhardtP said:

Hi ,

I have always found S7-Graph the easiest and most Dependant for complex sequences. Using the transitions from the processes.

R

Click to expand...

I would agree that S7-Graph is fantastic but it's an add on package that your customers must have. The other problem I have with S7-Graph is the incredible hit on processing time incurred every time you call a block; if you have a number of sequences running simulataneously, your PLC grinds to a halt.

Nick

As you can see there are several ways of doing what you want to perform.. But the most important thing as I see it is to design design design and then implement(unfortunally one often feels like there is no time to this even if the machine would be operating earlier if one had laid some more time on the design)..

Write down the sequence of steps translate it to a grafcet or something other you can understand.

Then choose a way to translate the grafcet to ladder logic or any other prefered programming laguage..


if you use integers for handling the stepnumbers you could use a function like this in scl instead of using a bunch of cmp obs only a sample not a perfect piece of code..

var_input
stepnumber : INT;
end_var;
var
laststepnumber : INT;
end_var;
Var_output
step : Array [0..20] of bool;
end_var;

Function_block : Fb100
begin
If stepnumber<>laststepnumber then
step[laststepnumber]:=0;
step[stepnumber]:=1;
laststepnumber:=stepnumber;
end_if;
end_function_block

hmm

I agree that S7-graph does increase the cycle time of the CPU. But, I never had troubles with them, never had a PLC stop... I run 11 sequencers at the same time... with pdiag and supervision alarms and proagent... no problems... ?

But I agree on the cycle time. For our new machine I have chosen for a S7-317-PNDP instead of the usual S7-315-2DP. On the 315 I had a cycle load of 50ms.

Now with the 317: 2ms

Manglemender said:

I would agree that S7-Graph is fantastic but it's an add on package that your customers must have. The other problem I have with S7-Graph is the incredible hit on processing time incurred every time you call a block; if you have a number of sequences running simulataneously, your PLC grinds to a halt.

Nick

Click to expand...

Hold on guys, what is wrong with dimmarkov's suggestion?

There are many good threads on this forum about using the JL instruction to create efficient state machines on this forum.
It is the best part of a S7.

Peter Nachtwey said:

There are many good threads on this forum about using the JL instruction to create efficient state machines on this forum.
It is the best part of a S7.

Click to expand...

I have a few objections to jump lists.

1. They break the "thou shalt not use GOTO" injunction seen in other programming languages. This is a widely and deeply felt injunction, for good reason in my opinion, because it can easily cause a block to fragment into spaghetti code. At least it's easy to see in S7 when a rung of code is being skipped.
2. I like all rungs of blocks to be active at all times for easy troubleshooting. It annoys me to scroll up and down all the time to work out what is going on. For instance, I often look at the rungs for the next state to check all is as expected before the transition occurs.
3. Control of outputs requires set-reset operations in each state where the outputs may be modified. I prefer to use continuous logic, i.e. turn on output in states 4 and 6 only, as opposed to turn out output at start of states 4 and 6.
4. Maintenance electricians, in my experience, hate jump lists.

I have seen jump lists used for really fast machines that require lighting scan times and were already at the top of the processor speed range, but generally the speed difference is not a big selling point compared to the disadvantages. In all the different programs I have seen, the use of jump list is rare.

Incidentally, I did a bit of search on old threads because this is a topic that interested me (because I am sketching some new ideas for state machines in new code I am writing) and I was curious to see whether there are any arguments for a jumping state machine that I was not familiar with. Peter, did you know you have made almost the same comment as your last post in almost every single one I read? You'd almost think you were a fan of that instruction Here are some more references for those interested in more state machine techniques:

http://www.plctalk.net/qanda/showthread.php?t=1931&highlight=JL+state

http://www.plctalk.net/qanda/showthread.php?t=37824&highlight=JL+state

http://www.plctalk.net/qanda/showthread.php?t=37824&highlight=JL+state

http://www.plctalk.net/qanda/showthread.php?t=35595&highlight=JL+state