Sequences

[RET]

Forgive me but your example doesn't make much sense to me.

"Starting", as you have said implies a mode or state the machine is in, not a sequence. This screams bits to represent each mode or state. Within each mode/state you have a sequence that occurs. Or you could have 1 sequence, where steps 0 - 10 make up your "starting" mode, steps 11 - 20 your "running" mode, steps 21 - 30 your "stopping" mode...etc.

I can see on a large complex system having a master sequence of "Step 1 - Starting", "Step 2 - Running", "Step 3 - Stopping"...etc which is a sequence but really used to track state. Each of these kick off their required sub-sequences. Thinking about it, this example seems to be a good justification of integer:

// Using code formatting for clarity

Step 1 - Starting
    Step 10 - "Starting Step initialize"
    Step 11 - "Starting Step #1"
    Step 12 - "Starting Step #2"
    .
    .
    .
    Step 19 - "Staring Step #9"

Step 2 - Running
    Step 20 - "Running Step initialize"
    Step 21 - "Running Step #1"
    Step 22 - "Running Step #2"
    .
    .
    .
    Step 29 - "Running Step #9"

Step 3 - Stopping
    Step 30 - "Stopping Step initialize"
    Step 31 - "Stopping Step #1"
    Step 32 - "Stopping Step #2"
    .
    .
    .
    Step 39 - "Stopping Step #9"

Of course you can use bits in my example, but again for fluidity across the PLC/HMI/Documentation, integers are very clear. Even in this case, you have multiple sequences occurring but each is exclusive and identifiable simply by the integer step number.

That's the problem, though, if you do have multiple sequences occurring in parallel. Having one integer tag to indicate the multiple sequences, steps or states that the machine may be in, especially if it's not a truly sequential operation, restricts your insight into the process, kind of like assigning an integer value to a single tag depending upon any myriad of alarms states that can be present, I'd like to know all of them.

I've seen it both ways, but the huge range of systems and processes that control people work in, nothing can be absolute for all, it just all depends on the system and situation.

 

[kamenges]

Originally posted by RET:

...especially if it's not a truly sequential operation, ...

That sounds to me like you are trying to shove a square peg into a round hole. Why would you use a sequencer/state concept for something that is not truly sequential? If it isn't sequential don't use a tool that works best with sequential processes.

Keith

 

[mk42]

That's the problem, though, if you do have multiple sequences occurring in parallel. Having one integer tag to indicate the multiple sequences

Why would you limit yourself to one step tag, if you have multiple parallel sequences? You can easily have an overall sequence, and then a sequence for different sections of the machine, and then tie them together via the transition logic.

 

[joaco1993]

Could you upload some program examples of these different aproachs ??

That would be great,

 

[ganutenator]

Could you upload some program examples of these different aproachs ??

That would be great,

(*

Transition from ...

PARKING

to

PRESOAK1

*)

(*once the park window is complete*)

If (my_sfc = 1.0) and car_in_park_window_for_time then

	Case Pass1 Of

		0: my_sfc:= 1.5; (*Presoak 1*)

		1: my_sfc:= 1.6; (*Presoak 2*)

		2: my_sfc:= 1.7; (*Reposition*)

	End_Case;



	car_in_park_window_for_time:= false;

	MachineMotionNxtStep:= 10;

end_if;





If (my_sfc = 1.5) then

	Pass1Pre1:= true;

else

	Pass1Pre1:= false;

end_if;



If (my_sfc = 1.6) then

	Pass1Pre2:= true;

else

	Pass1Pre2:= false;

end_if;



If (my_sfc = 1.7) then

	Pass1Repo:= true;

else

	Pass1Repo:= false;

end_if;

And I see an error in me comment. Orig, the program only had presoak 1 as the first pass.

But it kinda cool that I was able to add states to the state machine after the fact w/o screwing it up.

 

[joaco1993]

How about ladder ?? I dont really like much ST for sequence.. when debuging is much easier to see in ladder..

I believe..

 

[ganutenator]

How about ladder ?? I dont really like much ST for sequence.. when debuging is much easier to see in ladder..

I believe..

I actually love ladder too.

I spent 1995 to 2006 w/ ladder.

When I sober up, I will totally post the equiv.

first things first, taco night

 

[gclshortt]

http://accautomation.ca/building-a-plc-program-that-you-can-be-proud-of-part-1/
This series takes you through using discrete inputs and outputs to control traffic lights and cylinders. As we progress we introduce additional methods to solve logic. We look at sequencers in a new way and learn how to write programs to allow users to teach the new sequence.

This is how we have developed sequencers in different systems.

Regards,

 

[ganutenator]

http://accautomation.ca/building-a-plc-program-that-you-can-be-proud-of-part-1/
This series takes you through using discrete inputs and outputs to control traffic lights and cylinders. As we progress we introduce additional methods to solve logic. We look at sequencers in a new way and learn how to write programs to allow users to teach the new sequence.

This is how we have developed sequencers in different systems.

Regards,

Do you realize how many college projects you just solved?

 

[James Mcquade]

I can see how easy it is for those who know sequencers to use them.
But I am going to argue against them for those in maintenance.

As I said earlier, I had to clean up the mess created by the guy who wrote the
sequencers. I spent weeks on the program and we finally ended up contracting with the guy to fix his mess. We had the contract written so that he had no choice but to fix his mess.

MOST maintenance mechanics don't know sequencers or how they work.
Being the guy left at the company, I got 4 or 5 calls almost every night wanting to know how to fix the machine and I lived 4 hours away from the plant. Try functioning on 3 hours sleep a night for several weeks! That should be a red alert right there something is wrong.

The machine can't be fixed by maintenance and doesn't make production, Management gets involved because customers are about to pull the po, my company gets a call, and the boss yells at me and I end up telling him what the issue is and give him a copy of the program to look at and he finally agrees with me after a day of trying to explain how sequencers work.

Just a rant - maybe.
I never, ever want to go through that experience again!

james

 

[ndzied1]

How about ladder ?? I dont really like much ST for sequence.. when debuging is much easier to see in ladder..

I believe..

Here's a blast from the past
http://www.plctalk.net/qanda/showpost.php?p=669470&postcount=25

 

[jstolaruk]

I can see how easy it is for those who know sequencers to use them.
But I am going to argue against them for those in maintenance.

As I said earlier, I had to clean up the mess created by the guy who wrote the
sequencers. I spent weeks on the program and we finally ended up contracting with the guy to fix his mess. We had the contract written so that he had no choice but to fix his mess.

MOST maintenance mechanics don't know sequencers or how they work.
Being the guy left at the company, I got 4 or 5 calls almost every night wanting to know how to fix the machine and I lived 4 hours away from the plant. Try functioning on 3 hours sleep a night for several weeks! That should be a red alert right there something is wrong.

The machine can't be fixed by maintenance and doesn't make production, Management gets involved because customers are about to pull the po, my company gets a call, and the boss yells at me and I end up telling him what the issue is and give him a copy of the program to look at and he finally agrees with me after a day of trying to explain how sequencers work.

Just a rant - maybe.
I never, ever want to go through that experience again!

james

+10

Exactly why my big customers (F,GM,FCA) don't allow them and because it has to be something the plant can support. When each motion has a rung of truth then the electrician can look at it and know exactly why its not working. 33 years of programming PLCs for machinery have taught me that I best make it easy for the electricians otherwise I can expect a phone call in the middle of the night. Forget that, I don't want any phone calls unless its for the next job.

 

[kamenges]

Originally posted by James Mcquade:

I can see how easy it is for those who know sequencers to use them.

Are you referring to the built-in instruction called a sequencer or are you referring to the concept of sequencers in general? The way the above sentence is written you seem to be talking about a device as opposed to a concept.

Originally posted by jstolaruk:

When each motion has a rung of truth then the electrician can look at it and know exactly why its not working.

Unless the process or function you are controlling is as simple as "push and hold button / extend cylinder" it is HIGHLY unlikely that you will be able to encapsulate all the logical requirements for all of the output functions into one rung each. So in the end the guy (or gal) is going to have to search for the reason why the one bit in the rung is not active anyway. I guess I don't understand how this point would apply only to the use of state machines.

At the end of the day, if the process or function is sequential in nature it will have to be programmed in some type of sequential manner if it is going to work. So people who don't like "sequencers" have to be using sequential programming whether they like it or not. Therefore the argument isn't about whether or not you will use sequencers. It is about what form you want the sequential programming to take. I personally prefer integer based state machines but to each his own.

Keith

 

[Paullys50]

That's the problem, though, if you do have multiple sequences occurring in parallel. Having one integer tag to indicate the multiple sequences, steps or states that the machine may be in, especially if it's not a truly sequential operation, restricts your insight into the process, kind of like assigning an integer value to a single tag depending upon any myriad of alarms states that can be present, I'd like to know all of them.

My example was pretty basic, and simply an attempt to portray clarity with integers. The example as written does not have any possible parallel sequences.

Even if you did require parallel sequences that is easily solved. My perspective is that every process that requires a sequence gets a unique sequence engine to drive it, thus unique states, unique step indication, unique transitions, unique alarm conditions..etc. These could be completely independent, these could have master/slave relationship, they could be in parallel, it really doesn't matter as the sequence engine works on a singular process.

Note, I definitely do not encourage the use of any SEQ instruction, roll your own to give you all the features you require.

 

[AustralIan]

Maybe someone should post a functional spec and we all get to program it and compare different sequential logic. On reflection, I don't actually use a sequencer at all, I use an abstract design concept called a State Machine. I have a DINT which stores the current state of the machine. I have a section of ladder logic that handles the transition between states. I then have a section of logic that defines what happens in each state, ie. the outputs, motion instructions, etc.

I am curious to see how for example James McQuade programs this. I am also curious to find out more of how the sequence logic James talks about was programmed, so we can all avoid such practices in the future. Are you able to tell us a bit more about how it was programmed? Was it a specific sequence instruction, or did it just use ladder logic to switch between different states?