Bob said...
"... I think that the number of stages available is 1777 (octal)."
Yeah, that makes for a lot of stage/steps being available. Much more so than a typical drum.
Bob asked...
"Is the entire drum monitored during each scan, or only the current step that is active?"
The program monitors only the current drum step... plus a couple of conditionals that are used to RUN the Drum, ENABLE/RESET the Drum, and SKIP to the next step. All Drums are not the same... these conditionals are available on my drums.
Bob asked...
"Are drums only limited to discrete bits and timers, or can they be advanced by other things like V1<V2 and V3>=V4?"
In general, Drums are advanced by an "Event" or an "Event & a Timer".
The question is... What is the "Event" and how is it "generated"?
Relative to the Drum, all "Events" are "external". That is, a particular "event" might be something as simple as an Input... or an Output... or a Control Relay.
"Input Events" simply are as they occur in the field.
"Output Events" simply are as they are "generated" in the code.
"Control Relay Events" are as they are "generated" in the code.
How much code does it take to "generate" an "Event"?
It usually takes only as much as is necessary. How much is that? Well, I have to fall back onto the standard PLCnet answer... "It Depends."
Larger Systems, especially those that involve motion or pressure control, have a way of becoming very complicated, very quickly.
One might use a Drum as a Primary Stepper through a particular process, however, there is usually a lot, and I mean a lot, of things going on in any particular step.
In general, the "Discrete Bit" that causes the Drum to move from one step to another is a signal indicating that all of the activity associated with the current step has been successfully completed and it is, therefore, OK to go to the next step.
What might that "activity" be?
It could be something as simple as a limit switch turned ON or OFF... to any combination of inputs, outputs and control relays. In fact, your drum switch could be driving a drum switch which is driving a drum switch which is... (puke)... ad nauseum.
Bob said...
"There is one more concept involved with stage programming. You can assign a group of stages to a block (for example; BLK1 would include S0, S1, S2, and S3) If a block is off, then all stages associated with that block are also off and are not scanned."
Creating your "block" probably requires a bit more effort than I need to insert a SKIP and a LABEL. "Skip-Areas" do not get automatically "zero'd out" like in a Master Control Relay section.
Bob said...
"I will definitely agree with you that all the fancy bells and whistles could be accomplished using straight ladder code (how much extra code is for another topic).
Extra code... hmmm... my contention is that there is essentially no difference in the amount of code.
Within any of your stages, you have a certain amount of code. That code causes things to happen. When those things happen, the last part of any given stage says... OK, go to Stage such-n-such. The same process is repeated in the next stage.
In a program with a Drum, the same activity occurs. Logically, there is no difference between stage-code and drum-code. In terms of the amount of code, again, no difference... the same activities have to be generated, detected, and evaluated, before moving on to the next step or stage.
As for "Organization"... that too is a "wash".
Certainly, in staging, all of the appropriate code has to be contained within the particular stages... or does it???
Any element in a stage can actually be "generated" by code outside of the stage-program. So, a stage-program might not necessarily be as self-contained as one might think. Of course, whether or not a particular bit is controlled in the stage-program or outside the stage program is entirely arbitrary and up to the programmer.
As I said before, with respect to the Drum, all events are external. That means, anywhere but inside the Drum.
Hmmm... that might not be entirely accurate to say.
The current step in a Drum could turn ON a bit. The assertion of that bit might be necessary in order to proceed to the next step... that is possible... it would be lousy programming, but it is possible.
...where was I?...
Oh, yeah...
For a Drum, it is the case that the "step-signal" is generated externally. Now, just it is upto the "stage-programmer" to determine how he organizes his code, so too it is for the "drum-programmer" to organize his code.
How code is organized, in any process, depends primarily on the nature of the process.
With respect to code-organization, a programmer should ALWAYS organize the code so that it is easy (at least, as easy as possible) to troubleshoot. All the time bearing in mind that the process is for the operators FIRST, then the maintenance folks SECOND, then the programmer LAST!!!
I guess the final word is that, regardless of the point of view, all methods essentially provide the same effect... no method is any better at saving effort than another.
OF COURSE, any method can be used in such a way that it demonstrates how easy it is to use.
HOWEVER, in the final analysis, the process is the Judge!
The process WILL, sooner or later, find the holes in the code developed with the so-called "easy-method". It finds the holes in ANY method!