Sequencers

(8{)} ( .) said...

"Sequencers are limited. They only go one direction."

It's too bad you had such limited sequencers to work with.

The TI sequencer allows for damn near any kind of step manipulation you could ask for (via direct access to the Sequencer Control Block). You can even use one of the controlled bits to activate a "Go To Step-X". It can "loop" within a particular segment of the sequencer as necessary. All it takes is careful planning... like in any PLC coding. The only thing that aggrevates me is the size limit on the sequencer. However, this can be over-come by chaining mutiple sequencers together.

The TI sequencer is a mighty powerful beastly thing-oid!

(8{)} .)
My Bad.
Sorry for underestimating your skills.
I didn't know that you were sophisticated enough to roll your own.

I certainly am not.
But I think I can follow someone elses sequencer. (even the Horrid AB thingoids)

I took your post as though you wanted to stay away from Sequencers because they are just too complicated. (Bad Read on my part)

If you can do whatever you want with indirect addressing and Masks, go for it.
Good Luck!

Terry Woods said:

It's too bad you had such limited sequencers to work with.

Click to expand...

1st of all the thread discussed SLC-500 sequencers.

2nd, I have used TI sequencers but since I've only had to decipher someone elses code (not write my own) my thoughts against them are even more justified.

Basically I'm against using sequencers. Their uses are very limited and they violate my 1st rule of PLC programming: "keep it understandable."

Unlike application programming (eg. developing a word processor) PLC source code is viewed every day by non-programmers. Ladder logic is a troubleshooting tool.

Picture the electrician trying to decipher a sequencer that was stuffed into the code simply because the programmer thought sequencers are sexy. After hours of frustration the electrician throws up his hands in exasperation and makes a bee-line to the local voodoo parlor and asks the local medicine-man to turn the programmer into a shrub.

Back to my TI program...

I was called in to troubleshoot a poorly documented sequencer that ran a centrifuge. The thing was undecipherable. The centrifuge had about 10 inputs and 6 outputs. Why was it necessary to program the thing with a sequencer? The hours it took to finally figure the damn thing out (and I've got well over 20 years PLC experience) proves my point.

I can go on and on regarding sequencers and other useless instructions that PLC companies put in their controllers. The point is, once again, that it is our job to program well (and document well) so that PLC code we deliver serves both of it's main purposes: Work properly and be a good troubleshooting tool.


(8{)} ( .)

(Yosi)

So... Yosi,

Your real complaint is against poor programming; including poor program organization and poor documentation... no?

At the very least, a sequencer clearly indicates what it is waiting for, and then, just as clearly, indicates what it does as a result.

A sequencer simply says... first I wait for this, then I do something, then I wait for that, and then I do something else, etc.

The sequencer itself is incredibly dumb and quite incapable of producing confusion. It's pretty damned straight-forward.

If you had a hard time deciphering a sequencer, I dare say that your hard time was either in trying to determine the derivation of the control bits, or in trying to decipher the resulting actions produced by the controlled bits.

In either case, I'm pretty sure that the aggrevation you describe lays outside of the sequencer. Also, I'll bet that the bits had really lousy names; names that didn't make sense in terms of the centrifuge process controlled by the sequencer.

Before you left, did you do anything to fix those names for the next poor ba$tard?

Well Terry poor programming should rattle anyone's chain.

Regardless, look at what the sequencer does. It spits out a bit pattern through a mask to a series of outputs.

Why use it? The MVM does everything the SQO does and more. Furthermore the MEQ does everything the SQI does. I can't tell you how many times I've rewritten code to use File-to-Word (and old PLC-2 instruction, now I'm showing my age) instead of sequencers. The rewritten code is invariably smaller and easier to understand. In many cases I'd have eliminated the File to Word method of programming but I didn't want to rewrite entire projects.

You may ask (and then again you may not...): Why did the original programer use sequencers in the first place? I have no idea other than the belief that you can program an entire factory on one rung or something equally inane.

Finally, we have to write for our audience. While we can't always write down to a certain level we can certainly do our best to make the code understandable. Instructions like the sequencer, especially when they are inappropriatly used (which is usually the case) defeat one of the main purposes of coding in ladder ie. ladder logic is a troubleshooting tool.

(BTW, see how long this thread is... It's all the sequencer's fault.)

Oh yea, I did improve the existing documntation on the centrifuge project.

Cheers,

(8{)} ( .)

(Yosi)

Yosi,

I certainly agree that all sequencer type actions can be accomplished without a single sequencer. However, if the particular sequencer function is nothing more than a simple, basic, generic type sequencer that acts exactly like an old mechanical Stepping Drum Switch then it is a very handy way to link causes & effects in a very simple and easily understood manner.

I was so bewildered by your comments and your complete disrespect of the sequencer that I had to go see exactly what you so disliked. So I opened up the SLC-500 Instruction Set and read up on their sequencer...

Well, now I understand your pain. In terms of the SLC-500 Sequencer, I agree with you.

The SLC-500 Sequencer reminds me of the OSHA approved horse & rider. Is there really a horse underneath all of the clutter?

There is an interesting ironic twist embedded in the OSHA approved horse & rider. If a person grew up knowing of no horse other than the OSHA approved horse, and then happened upon a horse in the wild... that person probably wouldn't see a horse at all... at least, not what he recognized as a "functioning" horse.

I think most of us can agree that a horse, recently "broken" from the wild, is more of a horse than is the OSHA approved horse.

I said "most" because there is bound to be a few that insist on seeing the world only from the "approved perspective".

Some would bring the newly "broken" horse to the "Approval Bureau" and asked... Is this a horse? The "Approval Bureau" might say... Well, if you did this, and that and then the other, well, then I will recognize it as a horse.

And so, a horse is not a horse, unless it complies with the requirements of the "Approval Bureau".

A horse ain't a horse,
of course, of course,
that is, of course,
unless the horse
is finally "approved".

But... Since most of us can agree that a horse, recently "broken" from the wild, is more of a horse than the "approved" horse...

A horse is a horse,
of course, of course,
that is, of course,
until the horse
is finally "approved".

hmmm... there seems to be a logical contradiction here... somewhere...

It appears that...
A Horse is a Horse... until the "Approval Bureau" gets a hold on it.
A Sequencer is a Sequencer... until the "Approval Bureau" gets a hold on it.
A Mask is a Mask... until the "Approval Bureau" gets a hold on it.

Since the "Approval Bureau" is the "authority" in so many cases, and because so many insist on looking at the world from the "AB-approved" point of view, it might be safe to say that many "AB-approved" programmers wouldn't know a real horse if it bit them on the a$$.

Sad.

Hey! Don't take it personally!

I'm not slamming the AB Programmers except to the extent that some refuse to understand that the Philosophy of Logic existed long before AB existed. Life really did exist before AB.

I'm slamming the programming environment you guys have to survive in. The "Approval Bureau" made things much more difficult than it should have.

However, I will admit that I'm hearing good things about the latest programming software. I'll have to go take a peek and see if they improved the sequencer (I'll bet they didn't). Sometimes it just takes a while to grow up and get serious.

(2036)

Running the risk of sounding like a fool bragging about crayons while everyone else is using sharp pencils.

The sequencer on the SLC 150 platform was a blessing, considering how hard (how limiting) the ladder logic "PCIS" is to use.

Hi Terry,

However, I will admit that I'm hearing good things about the latest programming software. I'll have to go take a peek and see if they improved the sequencer (I'll bet they didn't). Sometimes it just takes a while to grow up and get serious.

Click to expand...

The RSLogix envrionment is excellent. If you haven't seen it then you should take a good long in-depth look.

Regarding the sequencer and the horse etc...

A horse is a great thing...
Until you get a car.

Why on earth improve an obsolete instruction which has very limited use?

How many applications have you had where:

...the particular sequencer function is nothing more than a simple, basic, generic type sequencer that acts exactly like an old mechanical Stepping Drum Switch...

Click to expand...

I've been in the business since 1981. I haven't seen more than a handful of applications that are best served using a drum instruction: Anyone's drum instruction.

I'll say it again, we code for an audience. Our code is looked at by non-programmers every day. I've done hundreds of projects and have encountered very few pure drum sequences. With so few of them being used (or used correctly) what reason is there for slowing down the trouble-shooting process with instructions that are overly complicated and have to be crow-barred into the logic to make them do exactly what you want them to do?

Awaiting your next installment.

(8{)} ( .)

(Yosi)

BTW, have you noted the lenth of this thread?

You pass off, I doubted if wise person the meaning of sequencer, but the true one was clarified.
Confirmations

Correct, tecnics books and dictionaries confirm:

Terry Woods said:

There are two aspects to MASKING... the MASK itself and the Masking Operation. To speak of MASKING is to speak of the MASK and the specified MASK Operation. MASKING consists of a MASK (user defined) and a MASK OPERATION (user defined). They are "user defined" unless a canned routine is used which might force either the MASK, the MASK OPERATION, or both, to some pre-defined condition.

Click to expand...

At this point, it is worth noting that most processors do NOT have the capability to perform an "XOR" operation directly. Nor can they do an "OR" operation directly. That is, they simply don't have the hardware to do so. This is also the case for Subtraction. The hardware just ain't there to make it happen! So, the operations are "manipulated" via software.

Click to expand...

True and false. It depends on the CPU generation
The internal cicuit they are squematic to answer in only cycle a composed operation. More PLCs, currently more one steps

To mask and filter - They can have the similar result:
Filter - It limits to band of values
It masks - It can limit the limit (AND), this means a filter pass-low.

It masks Frequent, it possesss an fix value. But it can be taken as variable.

Yosi

If it possesss difficulty, not it operation,but the application.Lack to abstract, some pratice logical to fortify
Sequencers: They are we good, since when the resources expense they are covered by theimplementation easiness.
- Less time for codification and implementation - If true, implementation - Get speed and best results.
- To make a device, to forward or to back. Directly, selected the steps. (for simple systems)
- To make a machine to forward or to back. Using sequencers for IN and OUT, interlaced.

It masks it of sequencer, argued. I consider useless (has contrary validate?) Because to filter a value, where it was defined as constant?
If it masks it, it was used to collate with the sequence of data. And to each validation, to walk a step. It would have an inverse instruction when sequencer, me it would be useful. It would get a sequence comparator, accurately the discrete processing of the programs.

Good choice of words Dandrede,
GO pea OFF! Masking is nothing more than a physical "ANDING" of the input and the mask, on individual bits. The output word is the actual anding of individual bits contained in the input word, integer, or whatever and the mask word! The "ONLY" time it may be of concern, is with sign extend, of two different data lengths!
1 and 1 is 1
1 and 0 is 0
if the two datum are of different size the only output that is different is the overflow bit! Bite me!

from Bitmore's post:

Masking is nothing more than a physical "ANDING" of the input and the mask, on individual bits.

Click to expand...

not exactly

as an example, check out columns E and F here

previous post about decoding a mask

"Decoding a Mask" (whatever the hell that means) is not "Masking".

"Moving WITH Mask" is more than Masking. A Masking operation can occur without actually "moving" anything.

"Building with Nails" is more than Nailing. A "nailing operation" can occur without actually "building" something.

Bitmore said...

Masking is nothing more than a physical "ANDING" of the input and the mask, on individual bits.

Click to expand...

Don't limit your view of possible Masking Operations: AND, OR, XOR, NAND, NOR...

I am going to reply to the tangent as a maintenance man that has to troubleshoot on a daily basis.

For over 20 years I have worked with machines that used electromechnical Drum Sequencers, it was and is a common practice.

I have dealt with the GE Drum Sequencer and the AB SQO instruction many times. The only difficulty I have ever had was with documentation pertaining to the corresponding bits.

Sequencers are limited. They only go one direction.

Click to expand...

I have always associated Sequencers with electromechanical drum sequencers. They can only go one way.
Definition

One of the three basic logic structures in computer programming. The other two logic structures are selection and loop.

In a sequence structure, an action, or event, leads to the next ordered action in a predetermined order. The sequence can contain any number of actions, but no actions can be skipped in the sequence. The program, when run, must perform each action in order with no possibility of skipping an action or branching off to another action.

Click to expand...

As a maintenance electrician if I look at plc code with a "ROLL YER OWN" with MVM then I am not sure if it would be easily understood. If I see a sequence instruction then I understand what the next step is. I understand that most modern plc software offers more capabilities with the instruction(s) then the equivalent electromechanical devices they were created to replace.

I too would like to thank everyone for these old posts that are helpful to those of us who are learning still today. So far everything I've learned here from PID loops, (Dependent Gains/ ISA), AOI's and UDT's has translated well to StudioLogix Designer ver 21 and RSL5000 ver. 20, which I train with on a 1769 L-23E QBFC1B CPX.

Merry Christmas,

Jeff

Ron Beaufort thanks so much for a comprehensive explanation of the AB SQO, I need to program a simple one today on a MicroLogix 1500 and within a few minutes of reading your post I had a working sequencer.


Thanks Again
JT