Forward or forward?

Join Date
Apr 2002
Location
Just a bit northeast of nowhere
Posts
1,117
I've been thinking about the order in which states occur, and my question can be framed by how they are commented.

Let's say we have a single cylinder machine with three states : Cycle Start, Forward and Return.

Which is the better order? The latches are for clarity.

In the first example, the name "Forward State" refers to the machine's condition at that point. "Forward State" means "the machine is in a Forward State".

In the second example, the name "Forward State" refers to the activity happening in the state. "Forward State" means "the machine is moving into a Forward State".

Each has it's advantages. The first is purely accurate, but it has a disconnect with the outputs affected, i.e., the output is turned on in the previous state. The second activates all related outputs, then monitors the related inputs - each state is totally self-contained.

Which would you rather see in a program?



Example 1

I Cycle Start Output A
I-----I I--------------( )
I
I Cycle Start Forward LS Forward State
I-----I I------------I I-------------( L )
I I Cycle Start
I I-----( U )
I
I
I Forward State Return LS Return State
I-----I I------------I I-------------( L )
I I Forward State
I I-----( U )
I


Example 2

I Cycle Start Forward State
I-----I I--------------( L )
I I Cycle Start
I I-----( U )
I
I Forward State Output A
I-----I I----------------------------( )
I I Forward LS Return State
I I--------I I-----------( L )
I I Forward State
I I-----( U )
I
I Return State Return LS Return State
I-----I I------------I I-------------( U )
I
I
I


 
It is all down to your frame of mind. To me, example two makes perfect sense....it's the way I have always programmed! Everybody I notice has there own style (or way) of doing things. Once you get into the programmers frame of mind your sorted! Every issue becomes a simple problem to solve.
 
>>Maybe its me but Example 1 made no sense, example 2 did.<<

Maybe that's my answer :)

I guess a simpler way to explain it is :

Should the state reflect the condition the machine is in?

OR

Should the state reflect the condition the machine will be in when the outputs finish their jobs?

Put another way :

"I am in Ireland. I'll let you know when I get to England"

vs.

"I'm going to Ireland, I'll let you know when I get there."

This may seem like splitting hairs, but it affects the entire ordering of the logic and the approach to every state along the way.

Personally, I like the second approach as well, but I value you guys' opinions, and wanted to make sure I wasn't making a stupid mistake.

Thanks!

TM
 
I think that it is simply semantics. More descriptive comments like "Moving to forward state" would clarify either method.

To me a "state" is a static thing- how it is now. (state and static are related words). It is sort of a derivative term, because the state could be "moving". The term "forward state" tells me that the device is forward, not moving forward, the "moving forward state" tells me that.
 
Well, Tim, I ain't no semanticist, but I gots opinions on the matter.

First off, I avoids latch and unlatch commands cuase they is harder t' keep track of de-bugging in the wee hours. I prefers t' have holding contacts and done contacts to set status bits or coils. A lot of fellers here disagrees with thet philosophy, though!

Second, I prfers to use different terminology in my nicknames to take some of the confusion out of it. "MoveForward" and "AtForwardLimSw" are easily distinguished from each other, fer example.
 
Just to be contrary...

I would personally go with the theory behind example 1. I build my state machines with the state variable indicating the state the machine is actually in. The main reason for this is I think it provides a bit more flexibility. In the example presented it really doesn't matter much. But in a case where you have six static machine states. You have seven valves that need to actuate at various times during the machine states. These valves could be astuated by various logical combinations of the machine states. If you defined states based on the action currently happening I think you would end up with a whole slew more states than you would the other way. (OK, so that was confusing)
Some of this bias is based on two things I do when I build state machines. The first is that I VERY SELDOM use latched coils for my actual machine outputs. The states are obviously a different story but the actual action coils are standard outputs. So this forces me to use logical combinations of machine states to drive the outputs. That, in turn, forces me to think of individual actions in the context of the whole machine cycle. This can make interactions between individual actions easier to see. I also physically separate my state machine logic from the output driver logic. I don't consider them to be tightly related so I try to keep them separated. This may seem odd at first glance. But I have found it easier to modify the on and off points of the actual outputs if they stand alone and are driven from state values.

It really is a personal preference thing, though. Just make sure you carefully documnet the states either way so someone else can tell what you intend to do.

Happy stating,
Keith
 
Rick:

>>To me a "state" is a static thing- how it is now. (state and static are related words). It is sort of a derivative term, because the state could be "moving". The term "forward state" tells me that the device is forward, not moving forward, the "moving forward state" tells me that.<<

It is, in part, about semantics, but I suppose my real question is whether an active movement could be properly considered a "state". By your definition, the answer is yes, and I agree.

Tom:

>>First off, I avoids latch and unlatch commands cuase they is harder t' keep track of de-bugging in the wee hours. I prefers t' have holding contacts and done contacts to set status bits or coils. A lot of fellers here disagrees with thet philosophy, though!<<

I think they have their purposes, but few and limited. I find using integer states elminates the need for them in most cases. And in my admittedly bad example, I just used them to simplify the illustration. Seems created more confusion, tho'

>>Second, I prfers to use different terminology in my nicknames to take some of the confusion out of it. "MoveForward" and "AtForwardLimSw" are easily distinguished from each other, fer example.<<

Again, a good point. We seem to have a consensus here - actions are states as well.

Keith

>>I would personally go with the theory behind example 1. I build my state machines with the state variable indicating the state the machine is actually in.<<

The thing that caused all of this was myself trying to determine if it is best to start a state from a static condition, or if it can be an action. True, it's partly preference, but I find the latter to be more intuitive, and it's worked out nicely in my current project.

I also keep my output processing separate from the states, and for the same reasons you do.

Thanks for all the feedback!

TM
 
All my sequences are broken down into steps (static AND active), but I add an additional check for switches to be OFF. I don't do my sequential logic like you, but using you method, here's about how it would look:

I Cycle Start Ext. Permit Cyl.A EXTEND
I-----I I------------I I-------------( L )
I
I
I Cyl.A EXTEND Return LS Cyl.A EXTENDING
I-----I I------------I/I-------------( L )
I I
I I Cyl.A EXTEND
I I-----( U )
I
I
I Cyl.A EXTENDING Forward LS Cyl.A EXTENDED
I-----I I------------I I-------------( L )
I I
I I Cyl.A EXTENDING
I I-----( U )
I
I
I Cyl.A EXTENDED Ret. Permit Cyl.A RETRACT
I-----I I------------I I-------------( L )
I I
I I Cyl.A EXTENDED
I I-----( U )
I
I
I Cyl.A RETRACT Forward LS Cyl.A RETRACTING
I-----I I------------I/I-------------( L )
I I
I I Cyl.A EXTENDED
I I-----( U )
I
I
I Cyl.A RETRACTING Return LS Cyl.A RETRACTED
I-----I I------------I I-------------( L )
I I
I I Cyl.A RETRACTING
I I-----( U )


.
Switches can fail in the ON state as well! This just confirms that they they are functioning correctly... 📓

One of these days I'll have to sit down and write a thesis on my sequential programming method. It's difficult (for me) to explain, but it works like a charm! I have yet to find a machine that it can't be adapted to work with. Stay tuned...

beerchug

-Eric
 
Eric, you have done pure sequence, I like that where is only one condition / step !
It is simple show in panelview what is happening and what PLC is waiting for.

I Cyl.A EXTENDING Forward LS Cyl.A EXTENDED *)
I-----I I------------I I-------------( L )
I


I Cyl.A EXTENDED Ret. Permit*) Cyl.A RETRACT
I-----I I------------I I-------------( L )


There is one week point, Cyl.A Extended can't use if Ret. Permit is allready True.
 
Last edited:
Exactly!.. In my opinion, a sequence should be broken down into as many "steps" as there are possible conditions. Debugging is a cinch when you have E-V-E-R-Y condition monitored... :cool:

I only showed it that way because it might make more sense to Tim if I used HIS sequencing logic. As I said, I have a completely different method of sequence logic. With my method (which I HAVE to get around to posting), you WOULD be able to use it in a PanelView, because the Cyl.A Extended bit WOULD be on for at least one full scan...

Quickie preview of my method... The sequence moves backwards (bottom to top) through the ladder. IOW, Tim's version would read, from top to bottom, EXTEND, EXTENDING, EXTENDED. Mine would be EXTENDED, EXTENDING, EXTEND, though the sequence still operates in the proper order. I'm sure it's a method others use as well.

I hope I haven't confused everyone... It sounded confusing just typing it... :p

I promise to post my sequencing logic soon!

beerchug

-Eric
 
Its early but let me see if I can explain why this did not make sense to me and maybe y'all can explain if I am looking at the logic wrong.
Code:
Example1
I  Cycle Start       Output A
I-----I I--------------(  )
WHat does this do?
Code:
I
I  Cycle Start    Forward LS     Forward State
I-----I I------------I I-------------( L ) 
I                              I  Cycle Start 
I                              I-----( U )          
I
Cycle starts but the Forward LS has to the made before the Forward state is latched, this is backwards to me. Maybe its the terms that are throwing me? Is the Forward LS actually the 'home" LS or LS that is at the back of the device that moves forward? If this is so it is backwards to my way of thinking in general.
Code:
I
I  Forward State   Return LS      Return State
I-----I I------------I I-------------( L ) 
I                              I  Forward State 
I                              I-----( U )          
I
Same question here, is the Return LS the switch mounted at the end of forward travel for the device?

When I looked at Example 2 the ladder and the terms matched actions..to me with the exceptions as follows.
1. What is Output A doing?

Overall though I could understand what Example 2 could be doing but not Example 1. The terms matched an action and the switches/terms match an action that would trigger the next action.

Does this make sense?
 

Similar Topics

Hi all, I'm having trouble solving a problem I've been working on for several months, and thought you might like a stab at it. The machine runs...
Replies
22
Views
851
Hi - I have an application where we are planning using an Edge device to connect some equipment, likely an S7-1500 and WinCC Unified Comfort...
Replies
0
Views
919
I am drawing a complete blank this morning looking for a unicorn. I would like to install a device at a remote site that will gather the data...
Replies
15
Views
2,242
I'm working in implementing a bias into logic for a Compactlogix PLC using the PID instruction. I have it close to working but there's one part...
Replies
19
Views
5,802
Hey, We are using the latest and greatest version of WinCC WebServer and Client. WinCC WebNavigator V7.4 + SP1 + Upd13 To the best of my...
Replies
4
Views
4,255
Back
Top Bottom