PLC-2, Sequencers and bad programming

[(8{)} ( .)]

Hi All,

We've been down this road several times before but I want to get this off of my chest. Here goes.

I am not a big fan of sequencer instructions. It's not that the is anything inherently bad about them it's just that I keep running across these agrivating PLC-2 programs. I just wrapped up such a project, hence the post.

Let's be more specific. One of our bread-and-butter job sources is retro-fitting PLC-2 processors. We usually upgrade them to SLCs. The problem is, time and time again I run across programs that are written to service sequencer instructions which, unexplicably, happen to run the process.

For some reason, the programs that I run across manipulate the sequencer masks and sequencer data. These programs are unservicable. Whenever I run across a customer with one of these applications he invariably informs me that the process is unbelievably complex blah, blah, blah, when actually, it's only the code that is satanic.

Typically I re-write the programs, cooking down the sequencers to simple ladder code, thus putting them out of their misery. The results are programs that are usually 1/3 to 1/4 of the size of the original and, Great Googly Moogly!, readable.

Cheers,

(8{)} ( .)
(Yosi)

 

[Lancie1]

Yes, I agree. In order to use a sequencer for almost all real-world applications, you have to manipulate the inputs, doctor the sequencer, squeeze a 300-pound gorilla into a bikini, and then no one else can figure out how it all works. Why go to all that bother merely to show that "Yes, Dorthy, sequencers really do exist"?

 

[just_lionel]

300-pound gorilla into a bikini

Sorry, took me by surprise, but yes I do agree! They are good for Christmas lights though!

 

[davidg68124]

That is an example of poor programming. I have serviced programs that while I did not agree with the application specifics of the sequencer, were actually quite good. And very extensible.

Sadly, that is the exception.

I have seen large installations run with only a few rungs with a properly designed and implemented sequencer. Again, an exception.

Most times you see people manually manipulating the position or control file of the sequencer with all the necessary, but hard to follow logic, that is just an absolute mess. And an incorrect application of the sequencer instruction.

So actually, what I am saying is this, I do not agree they are bad. They have there place. It is like PID implementation. Most times the programmer never was taught how to use it PROPERLY.

David

 

[Donnchadh]

Hi All

Sorry for the question, could you expand on what you mean

by Sequence programming.Is it indirect programming or am I way off

the mark.





Donnchadh K.

 

[Doug-P]

...could you expand on what you mean

by Sequence programming.

It's not sequence programming, it's an instruction called a sequencer (some makers call it a DRUM). A good analogy is the drum on a music box or player piano.

The PLC-2 has three flavors - SQO drives outputs, SQI reads inputs, SQL 'learns' a sequence of inputs.

 

[FrancisL]

Totally disagree - Sequencers can be wonderfully efficient if used correctly. How they are used should be well documented of course, and they are not right for everything.
I used them on and AB2/30 back in the early 80's, in a batch process control application.
Had to teach the site electricians all about them, however the client liked them so much that they subsequently demanded that they be used on all future projects.
Yes, I even changed the sequencer masks and sequencer data on occasions (eg when running last batch) but of course this was documented well.

 

[OkiePC]

I have had excellent experiences with sequencers in my plant. We have dozens of automated assembly machines that must be configurable to build 14 different tire constructions. The main program is only a few hundred rungs thanks to a well designed sequencer. We use the setup information from the HMI to set and reset bits in the mask and source files to select the operations that are carried out when the machine is running in automatic. I added SQI instructions and XOR/MVM instructions to automate diagnostics. If your process only has a few steps, then a sequencer is overkill, but if the sequence must be flexible, or is complex enough, sequencers can definitely help with program structure and simplicity.Just my opinion ...

 

[(8{)} ( .)]

FrancisL and Okie I think you're missing the point. Too many of the programs that I've run across used sequencers because the programmer thought that they were sexy. Using the sequencer instruction was probably a personal thing with them and they had to figure out a way to crowbar the damn thing into the program.

The end result(s) was a program written around the sequencer instruction. No attempt was made to see if another aproach to programming the process was possible. They NEEDED to use the sequencer like a fat kid needs to drink straight Bosco.

In addition, the sequencers were used incorrectly. A FTW instruction would have sufficed and it would have eliminated the need for whole bunch of support logic.

Finally, I don't know what your applications are and perhaps a sequencer is the best approach there. The applications that I'm discussing, however, are fine examples of poopy programming.

Cheers,

(8{)} ( .)

(Yosi)

 

[Sergei Troizky]

Hi All,

For some reason, the programs that I run across manipulate the sequencer masks and sequencer data. These programs are unservicable.
(8{)} ( .)
(Yosi)

Cannot this be their way of the software protection from unauthorized use or distribution?

 

[Sergei Troizky]

Also, some newbies understand too literally the fact that a ladder diagram simulates an electrical diagram.
If a machine with a rotary cam switch was once upgraded to PLC, somebody could literally simulate it in the software.

 

[FrancisL]

It really sounds like some people have had experiences with badly designed software. No surprise, but I think that the fact that this software used Sequencers is probably not all that was wrong the relevant software, and it is unfair to blame a particular instruction.

May I clarify how I use Sequencers. (a simplification)

They are state engines that can set lots of objects in a module to a required state.

For example you can have an Equipment module containing a number of valves. With one command (set the Sequence to index X) you can set a whole collection of valves (call them bits if you like) to appropriate states for the Equipment state. You do not have to have a mess of rungs setting each valve according to the state of the equipment module, just one row in a table for each state of the equipment. Yes, I know that I do not have to use Sequencers for this, and FTW (File to Word I presume, correct me if I am wrong) may suffice but I think the principle applies.

Going back to the early 80’s project I mentioned, I also used Sequencer Ins to determine when to move to the next step – these days I think I would use an SFC, but have the SFC steps set the sequencer index.

 

[Terry Woods]

To the nay-sayers of Sequence Control...

If you think that Sequencers are more grief than they are worth... then you probably don't realize that the "causal factor" that leads to the next step should be developed outside of the sequencer.

That is, although a sequencer generally requires but a single input in order to proceed to the next step (and possibly a timer)... that single input should never (or at least, almost never) be an actual Input Signal (as in I/O).

The power in a sequencer is that that particular portion of the process proceeds only according to the defined sequence.

If there is a problem... then, if necessary, a "bail-out" sequence/routine can be activated. Otherwise, the process stays in the current step. If there is a problem, that is determined outside of the sequencer. If a problem occurs, then the sequencer is aborted and the appropriate bail-out sequence/routine is activated.

Ignoring the capabilities of a well defined sequencer is short-sighted.

Of course, as in any part of PLC Programming... the code must be well defined... and, of course, it's up to the programmer to make it so!

 

[kamenges]

Terry-

Just because a process lends itself to 'sequence control' doesn't inherently mean the use of the SQI/SQO/SQL instruction group is the best way to approach it in an AB processor. That particular instruction group has specific rules to their use that can make them tough to deal with unless your process is rigidly sequencial.

I don't think the original post has any particular issue with sequencers assuming the process lends itself to sequenced operation. You can drive a nail with a pipe wrench and become quite good at it. But that doesn't mean there isn't a better tool out there to drive nails with. Any specific tool or technique has some applications they are suited for and others that are not. The jist of the original post is 'don't use a pipe wrench to drive nails', not 'don't own a pipe wrench'.

Keith

 

[Terry Woods]

Keith,

My initial post was directed, as I stated in that post, to those respondants that spoke poorly of the sequencer in general.

Now, with regard to what you said...
Aren't you really saying that a sequencer shouldn't be used if the particular process-sequence is not necessarily a ridgidly defined sequence?

If so, then I agree... but then... that process-sequence doesn't follow the model of "sequence", does it?

If it's a "sequence", as understood in the common parlance, then it is a ridgidly defined series of steps that repeat, over and over, without variation. If not... then it is not a "sequence" (as commonly understood).

So... why would anyone use a sequencer to control events that don't necessarily occur in a repeating, sequential, fashion?

In some PLCs you can "jump" to whichever step you want to by accessing the Sequencer Control Word. This allows the Sequencer to actually act as a "buffet" of Output conditions (TI comes to mind). Of course, that means that the Sequencer-Step-Number must be determined by code outside of the sequencer. In that case, the "Step-Forward Conditions" in the Sequencer are nothing more than "dummy-bits" which are always OFF and not controlled by any code. Those bits never cause the sequencer to advance.

That can be a pretty damned powerful tool for selecting particular "sets of Output conditions". A "buffet" of output conditions, as it were.

Now, if someone is "masking" the outputs from a particular step to produce a desired result... I can just about accept that as a viable option on a very limited exception basis. However, it makes me think that the someone hasn't clearly defined the scope of the required output conditions in terms of the selection available from the "buffet". To alleviate this exception-masking, it's easy enough to use a second or third sequencer thus providing additional "buffet" selections.

Whether or not this is a good approach depends on the particular application.