scan-to-scan vs automatic cycle

Greetings all and Terry:

I was wondering how do you... approach your automatic cycle in your program.

Say we are doing a pick and place…you have all the safeties and everything in place.

Starting with the fun part of the program, (you have already homed your controller) you get a enable (start PB)… next you want to lower your cylinders or move your axes…so you set your output… then what?

Do look for a verification of the part is complete?
Would you pass a bit from that rung to the next?
To enable the next step? Your array? Do you bit shift?

Also where does the scan to scan (time) fall in to play? A couple of months ago I did my first large program that included a fully automatic cycle and motion

I don’t think I considered the scan to scan time factor enough when I was programming

Example…in rung 0000 I would latch a bit B3:10/0, saying that this rung was/is complete, this was not the best example but I think you will understand

But in the next rung I had to put in a timer to delay the next cycle…Is there a better/more stable way? I don’t like using timers in Automatic cycles I think they are unstable to say the least…

The program has ran without interruption, but I don’t like not knowing the “best way” most stable/bullet proof.

Not Safe!!!!

What happens if the all cylinders high bit goes off the next scan and the cylinders are heading down to ruin your day. You should have the all axes high contact in every rung/state that depends on the axes being high. The latch is OK. It is the lack of safety check on the following rungs that isn't.

I don't see why scan time would be an issue unless you are like many of my customers who try to shave milliseconds off their machine cycle times.

Here is a framework for a generic sequence logic. Each step of the sequence requires at least two rungs like these. In addition, you may need to add rungs to define the "Step Trigger Condition" to pas from one step to another. A typical Step Trigger Condition might be some time after a limit switch closure. One of the steps will also need to be defined as the "Home" step and the logic for that step will need to have a "Reset" contact in parallel with the sealing contact.

Previous   This Step      Next Step    General

  Step      Trigger       Trigger    Permissive   This Step

--] [---------] [----+------]/[---------] [----------( )-

                     |

                     |

                     |

This Step            |

--] [----------------+



                        Next Step

           This Step     Trigger     Next Step 

This Step   Trigger     Condition     Trigger

--] [---------]/[----------] [----------( )-

The framework can easily be expanded to include sequences that might need to run in reverse or to accomodate single stepping.

Peter Nachtwey said:

What happens if the all cylinders high bit goes off the next scan and the cylinders are heading down to ruin your day. You should have the all axes high contact in every rung/state that depends on the axes being high. The latch is OK. It is the lack of safety check on the following rungs that isn't..

Click to expand...

Point taken...I will make a change

Peter Nachtwey said:

I don't see why scan time would be an issue unless you are like many of my customers who try to shave millisecond off there machine cycle times.

Click to expand...

Its not the scan time that I am conserned with, I had to add a few timers in the program to (what I think) delay the cycle or the next step of the cycle

The scan was too fast, for my logic (maybe just in my head)to work, I had to install delays in the program to make it work? or latches with timers?

This PDF is the complete part of that reject_auto that I made...look at it let me know what you all think, it works but I never went back to clean it up, they had cycles in the program that worked good, I would set a bit to latch their part of the program.

geniusintraining said:

The scan was too fast, for my logic (maybe just in my head)to work, I had to install delays in the program to make it work? or latches with timers?

Click to expand...

That doesn't make sense. Faster scans should be better. I think what you are describing is a 'race condition' where your state machine skips through a couple states in one scan which is often bad to very bad.

A state machine should only execute one state per scan. Motion control/machine control applications are extremely easy screw up when that rule is violated. It is possible to have several of state machines running in PLC.

I have a couple good stories about state machines.

I will look at the .pdf.

Every state change should have conditions that need to be met to change states. Every state should cause an action, then check for the next action. Why would you need to wait more time then nessecary when the proper conditions have been met?

Here's what my normal automatic sequences look like:




This is sort of generic but in general if you loose the "auto" bit the whole sequence stops. You can drop "auto" with any fault or whatever your application requires for safety. Step 2 is delayed 2 seconds in this example.

The output rungs then look something like this:




With the auto part having an N.O. Contact for the step that turns it on and a N.C. contact for the step that turns it off. If an outputs goes on and off more than once in a sequence you just add another branch with on and off steps.

I took a look at the logic, & it seems like you're using timers rather then sensing the condition has changed. While this will work, it is nowhere near optimal, as timers run if the correct action has happened or not.

When I first started to program & design, I did the same. Once I got a machine from Barry Wahlmier (sp?), I saw a machine that checks for every single state change instead of using timers. The Barry machine functioned much better then the machine it replaced.

I like what Steve did but

In addition to the general permissive I would also have a state permissive contact when necessary and it is in GIT's case.

Norm's Auto is similar to Steve's general permissive. Sometime a state needs to have more or more specific error checking.

Steve's and Ndzied1's logic formats are what I'm familiar with. They are organized and very readable. The nice thing is the rung comments don't have to describe how the rung works, just what its doing in the machine.

geniusintraining said:

The scan was too fast, for my logic (maybe just in my head)to work, I had to install delays in the program to make it work? or latches with timers?

Click to expand...

Genius, I think you have to take a step back for a moment and try to understand how PLCs really work, as writing code isn't your problem right now. What you just said just doesn't make sense. There are conditions where the scan time could be to long, but I have never had a case where it was too short.

I fact, I think a good indication of amateurish programs are the complete overuse of timers. I have nothing against timers, and use them myself, but when I hear someone say "Hey, S7 only has 512 timers, and I just ran out. What do I do now?", then I suspect the programmer doesn't know what he's doing. Anyway, that's another topic for another time.

Tell you what- can you describe a case where you thought you needed to delay the scan for some reason? I think if we could explain the fallacy of that, then your code will fall into place.

Peter Nachtwey said:

I think what you are describing is a 'race condition' where your state machine skips through a couple states in one scan which is often bad to very bad.

Click to expand...

From a quick look at the pdf, I'd say that was what was happening without the timers.

That sort of thing can often be evaded by programming the steps in reverse order.

One think not mentioned here yet is that the machine designer has to allow for the proper sensors to indicate each and every step in the sequence. Sometimes you cheat a little but without them, the only way to program the sequence is with timers and if a valve or motor fails, the PLC has no way to check for it.


In the error checking there will also normally be what I call step timers. These are not for control but to check if a step is taking too long to complete. If the timer times out, you can stop the process or at least throw an alarm light or alarm msg on.

You don't have to write the sequence logic in reverse order to guarantee that the sequence remains in each step for at least one scan. That's what the NC "This Step Trigger" contact in my template is there for.

A step timer is an excellent troubleshooting tool. You can use them to detect when the sequence spends too much time in a single step or too little time. Too much time could be caused by an air or hydraulic leak, a sensor out of adjustment, a mechanical jam, etc. Too little time could be a sensor adjustment problem, a broken part, etc.

Really savvy operators and maintenance people will record the step times when the machine is working properly. Then they have something to compare against when things go wrong.

Steve, one thing I've done on most of my programs is add a diagnostic function that time-stamps any or all control events. When the event occurs (i.e. a limit switch is met), I'll look at the real-time clock, and write it to an array of diagnotic messages that contain the time, description of the actual event, and time since last event. This can be exported to the real world in a number of ways.