the Zen of stage programming ...
Greetings, Dave,
now that Bernie, Ron, and Eric have done all of the hard work and helped you get a handle on this stage programming animal, here are some extra thoughts from the sidelines that might make the next project a little bit easier ...
Eric Nelson said:
First thing you should do is add names to your I/O, stages, etc.
this is excellent advice ... I would go just a little bit further and recommend that as the very FIRST phase of every project that you name each and every one of your stages with a separate step of the machine’s actions ... notice in the left column of the sample program below how each separate machine step has been assigned to a separate LABELLED stage box ... don’t start with the right column until all of the steps have been defined and named and charted ... this is where a lot of beginners go wrong ... they program first ... and then do the documentation later ... there is a much easier way to proceed ...
[attachment]
notice that this sample project is NOT intended to be just like the one you’re working on ... but it is a fairly common sequence of machine steps that most programmers can identify with ... plus I’ve taken a few minor liberties with the way the program will actually be displayed on your computer screen ...
once you’ve defined and charted each step (stage) of the machine’s sequence, then it’s time to start fleshing out each stage ... if you’ve picked the right name for each stage (one which accurately defines exactly what the stage is intended to accomplish) then the actual programming is pretty straightforward ... for example:
what will we do during the “wait for start” stage? ... we’ll use special contact SP4 to flash the green lamp to signal the operator that we’re ready for another cycle ... when will we be finished with the “wait for start” stage? ... when the operator presses the start button ... then we’ll move on to the next stage ...
what will we do during the “head goes down” stage? ... we’ll keep the green lamp on steady to let the operator know that a cycle is currently in progress ... we’ll turn on the travel motor to drive the head downward ... when will we be finished with the “head goes down” stage? ... when the head reaches the lower limit switch ... then we’ll move on to the next stage ...
what will we do in the “grind at bottom” stage? ... we’ll keep the green lamp on steady to let the operator know that a cycle is currently in progress ... we’ll turn on the grinder motor to grind the product ... and notice that since we did NOT program the travel motor in this stage, the head will not be moving during this step of the cycle ... since this will be a TIMED step in the cycle, we’ll need to run a timer ... when will we be finished with the “grind at bottom” stage? ... when the “dwell” timer gets done ... then we’ll move on to the next stage ...
what will we do during the “head goes up” stage? ... we’ll keep the green lamp on steady to let the operator know that a cycle is currently in progress ... we’ll turn on the travel motor to move the head ... we’ll also energize the “up” relay to set the travel motor’s direction to drive the head upward ... when will we be finished with the “head goes up” stage? ... when the head reaches the upper limit switch ...
now the cycle is complete so we can jump back up to the start stage ... and we’re ready to start another cycle ...
the best way to start a project like this is to draw the stage boxes on a piece of paper ... leave some room between the boxes for the programming ... but do NOT start adding the actual programming code until each and every one of the machine’s action steps has been assigned to its own individual stage box ... yes, it IS possible to program several steps in each stage ... but that defeats the overall idea behind stage programming ... the beauty of this “stage” programming approach is that if you do it correctly, then you’ll never again have a BIG programming problem ... all of your problems will be little bite-sized problems ... something that you can work on just one little step (stage) at a time ...
good idea: make a flow chart of your process before you start to program it ...
better idea: use stage programming to set up the flow chart ...
stage programming is really just a flow chart that actually WORKS ... you can program decisions and use the results to jump to alternate paths ... you can set up more than one simultaneous path ... for example: how about a simple little chain of stages ... running off to the side of the main sequence of stages ... constantly monitoring for “cycle took too long” ... then let the “too long” condition drop into a “set alarm” stage ... you can use “resets” in this stage to “turn off” the execution in the main sequence of stages ...
people who have no previous experience with stage programming are usually amazed that things like the “double-coiling” problems associated with ladder logic are no longer an issue ... notice that “output coils” for Y14 (the travel motor) appeared twice in the sample program with absolutely no problems ... and look at how simple the “output” rungs become ... we’re letting the ON or OFF status of the stages condition the output actions ... in fact, if you find yourself adding “too much” conditioning to your “output” rungs, then you’re probably doing something wrong ...
and for those of us whose processors don’t even support stage programming ... it’s often worth the time it takes to program a complicated process in stage first – even though it will eventually have to be REprogrammed in ladder logic ... the fact is, using stage programming as a flow charting process can help us analyze and understand the machine’s actions ... and help us organize our thoughts ... and provide a systematic and structured approach to our final ladder logic programming ...
final thoughts: stage programming ... it’s good when you understand it ... it’s even better when you accept it and believe in it ...
hope this helps ...