Latched relay?

Terry,

Since touch panels have a built in debouncer, I do not have to worry about programming one.

As far as turning on when pushed rather than released, I would jump to 2 stages then.


Terry said,

Granted, my rung has 12 Elements. However, all of the elements are required for the sake of a correct conclusion. If scan time is that critical... hmmm... I'll have to look at a SKIP or JUMP and see how the relevent elements are affected.

Sometimes we all can get hung up in the symantics. What I was calling step you refer to as element. For me, this is a throw back to the Omron S3d8 controller. Each element was called a step.

The fewer elements used, the faster the scan time. I realize that when we are dealing with only 7 or 12 elements the scan time difference is minimal, but it will have an impact on much larger programs.

Automation direct also has a Drum Sequencer. I think that Block/Stage programming is a lot more flexible. The example I used is rather simplistic, but does show how Block/Stage programming works. Another benefit of Block Stage programming is the Stage view that is available from within DirectSoft. You can monitor which stages are active from a flowchart type view. It makes it easier to troubleshoot which section of the program you are having trouble with.

Bob

what happened to good 'ol rung logic! Toggle2 is the output coil for this flip flop.

[attachment

Moin all,

meanwhile we have seen several solutions. I used the problem to show how to program the toggle in all 5 IEC 61131 languages.

Different from my first post I have used a rising edge sensitive input for the Toggle function block. Much easier.

Yes, all have been tested.
http://www.61131.com/

As being full fledged function blocks all can be used in a larger project as often as required.

What about the sample w/o a PLC?

Regards
Friedrich Haase



Ingenieurbüro Dr. Friedrich Haase
Consulting - Automatisierungstechnik
email [email protected]
web http://www.61131.com/

Bob,

I will agree that Stage-Programming provides more flexibility than a Drum Switch... but only because Drum Switches are typically limited in the number of steps or stages that they can contain.

I should expect that Stage-Programming is unlimited (up to 64k**) with respect to the number of stages.

** Actually, unless the Stage-Programming method has a built-in limitation, there should be virtually no limit to the number of stages that can be used... you can always add another dimension to the stage-id-number by using multiple stage-id-bits.

As in...

 Book-0   Page-0    SG-1

---| |------| |------| |---...

  *

  *

  *

 Book-6   Page-8    SG-9

---| |------| |------| |---...

However, if there is a limit to the number of stage-steps then a staging program is nothing more than a canned-routine, only bigger than a drum switch.

As far as conditional flexibilities, stepping through a drum is controlled by a conditional-bit and possibly by a timer value. No different than it is in Stage-Programming. This conditional-bit, in conjunction with any associated time delays, can be managed by any number of rungs outside of the drum. Likewise, the stage or step can be selected by explicit declaration.

In my experiences, drum status also indicates where a drum might be hung.

The point that I'm trying to make is that ALL of the fancy functions and methods provided by the programming interface can be replicated through normal ladder coding practices (there might be a few issues where the method used is very complicated, but none the less...).

You simply need to pause and consider... "I wonder how it does that?"

Then you need to wonder... "How can I exploit that to fit my needs?"

But then again... Soylent Green! (some peoples just likes what they likes!)

Terry,

On the D2-250-1, I think that the number of stages available is 1777 (octal). Which is no different than the fact that the number of inputs and outputs are limited for each CPU.

Having not used a Drum Sequencer yet, I have nothing to compare it to. I am aware though that Drums are limited to the number of steps available. Is the entire drum monitored during each scan, or only the current step that is active?


Terry said,

As far as conditional flexibilities, stepping through a drum is controlled by a conditional-bit and possibly by a timer value. No different than it is in Stage-Programming. This conditional-bit, in conjunction with any associated time delays, can be managed by any number of rungs outside of the drum. Likewise, the stage or step can be selected by explicit declaration.

Are not all ladders controlled in some way by conditional bits (timers, counters, inputs, outputs,etc?) All of these cause the program to change states. Are drums only limited to discrete bits and timers, or can they be advanced by other things like V1<V2 and V3>=V4? (V would be a variable word) I use a lot of comparing setpoint values to cause the stages to JUMP.

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. This makes it very easy to set up one program for multiple machines (1 head, 2 head, 3 head) and not have it impact scan time.

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). It is up to the programmer to pick what is best for each machine.

The stage example I used may be better done using ladder. I was just showing an optional way of doing it if the PLC is from AD.

Thanks for your input Terry. I am always glad to hear what you have to say.

By the way, I prefer the original story by Harry Harrison, Make Room, Make Room. The movie wasn't bad though.

Bob

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!

Terry said,

As I said before, with respect to the Drum, all events are external. That means, anywhere but inside the Drum.


This may be where drums and stages differ. The events that can cause the stage to jump to the next stage can be located inside the stage. I sometimes locate a timer within a stage and when it times out, this causes the program to jump to the next stage.

Setting up blocks is easy. All you need is a BLK at the beginning and a BEND at the end. Everything in between is then part of the block.

There is one thing about AD that I do not like. You have to use MCRs if you want multiple branches;


This is not possible without using MCRs.

Thanks for the info on drums.

Bob

I don't see how you can make this so difficult.

Drums, stages, SFC are all overkill. It makes me shake my head.

I like Friedrich Haase's FBD example. What can be simpler?

lightninguk's example is excellent too. Panic mode also has the right idea but ABs don't have a bit XOR

S7Guy, you too have the right idea but why not.....?


This the same as lightninguk's example in S7 STL. Aren't ALT or Xor instructions great?

Peter...

If you were to follow through, you would notice that Bob and I went off on a tangent 4 or 5 posts ago... we went "stage-left" as it were.

Bob said...

"This may be where drums and stages differ. The events that can cause the stage to jump to the next stage can be located inside the stage."

That is one of the points I was trying to make. The movement from one stage to another is generally generated inside the previous stage. In a drum the movement from step to step is generated externally.

HOWEVER, if a particular stage relies on code activity outside of the staging-code then, at that point, there is no difference between the drum method and the stage method.

I think I have beaten this drum to death...

Thanks Peter, that's a good idea to use the oft-neglected X instruction. It streamlines the code that much more. The only change I had to make was adding one line to reset the input when the input comes from a GUI (in the system I use, the toggle bit is sent to the PLC, and the PLC must reset it):

Terry said,

I think I have beaten this drum to death...

I agree but I do not consider it wasted time. I understand drums better and now can add them to my arsenal of weapons to be used if I see the need.

Thanks Terry,

Bob

Re: I don't see how you can make this so difficult.

Peter Nachtwey said:

Panic mode also has the right idea but ABs don't have a bit XOR
Aren't ALT or Xor instructions great?

Click to expand...

Peter,

Sorry for replying so late, I didn't notice where this topic dissapeared. I don't quite understand what do you mean by
"right idea" because this idea is running for a ages now
on number of projects. It's true that ABs don't have special
instruction for bit_xor but who cares (time of bit_only
and replace_relays PLC programming is long gone).
All you need to do is use mask to select bit(s) to toggle.
Personally I'd rather not have a gazilion of instructions.
It takes forever to learn them all and it makes harder to
standardize - unless one guy does all by himself (which
might work short term but won't take him far...).
Using word level instructions can simplify code, save
development time, plc memory and scan time.

...and I always tought you are the one really getting excited
about performance