State logic

[rsdoran]

Ok I didnt study your last post well enough...sorry.

 

[Allen Nelson]

Don't be sorry - I updated my post to include the paragraph about the one-scan alarm. We were probably posting simulateously.

 

[Gerry]

A note of caution

In the foregoing ladder examples, if AUX is an un-buffered input and you're using A-B remote I/O or ControlLogix, then state Y may or may not occur because it is possible for AUX to be updated between the evaluation of the Y rung and the WAS rung.

Just one more trap to look out for.

 

[Peter Nachtwey]

There are many applications where the next state of the machine is not just determined by the current state, but of previous states. Static K-Maps cannot handle this.

Yes they can. Whether it is practical is another matter, but if the number of states is then it is easy to use the last 3 or four states.

The problem with K-MAPs is that they get big quickly.

The problem with SFCs is that they are easiest to understand when they are sequential. Using a SFC to jump around from state to state gets messy. This is why many have expressed their preference for using ladder as a state machine.

 

[Allen Nelson]

Gerry:

Yeah, yeah. Let's not make this more than it is, OK? I'm just trying to understand Karnaugh maps and how to use them to generate SFCs.

But, as log as you started the tangent - is there any advantage that anyone can come up with to having I/O be asynchonous to scan? Clearly, Gerry has pointed a disadvantage.

Is there another PLC besides the ControLogix that does this?

Peter:

I agree completely. And your reply to VillaBoy is correct - that's what that 'WAS' stuff has been all about. 'WAS' captured States 1-5, so that the trip alarm ('Y') can be expressed - without it, you get the alarm as soon as you start the motor, before the 'AUX' has had a chance to be made. (See, Terry, I've figured out that much of the lesson.)

 

[Eric Nelson]

shutit Well I'll be darned.... Yes, Allen, you're right... The code is indeed correct

I should have gone with my first take on it. It made sense at first, then RS went and got me re-reading it again and again.
I guess I'm too easily influenced?

Since this is just an exercise, I shouldn't jump to my real-world train of thought that says "What the hell good is an "ALARM" if it's only on for one scan?". I'm pretty sure this is what RS was thinking as well. I think it was just the word that tripped us up. These "ALARMS" are really only intended to be seen by the motor enable rung, which DOES get to see these alarms.

As far as the asynchonous I/O topic... Seemingly random changes in the I/O table during a scan? This would drive me nuts! mddr
I would love to see an example where this is actually NEEDED. I can see where you might want to update an input or two if you're dealing with a complex program (read: long scan time), but that's why the "immediate" instructions exist.

-Eric

 

[Allen Nelson]

I called states 'X' and 'Y' "alarms", since they were where the program went if the motor didn't start. Due to how they're (by me, but implied by the K-map), both are active only for one scan.

Clearly they cannot be used (directly) to alert the operator, but as I said, alarm handling is in a different module ("It's not covered in the spec - I'll have to issue a change order").

It's actually a very similar module, with X (or Y) acting as PB-1, the operator alert acting as MOTOR, and some sort of acknowledgement acting as PB-2. You could even have "alarms" within that module, if the operator takes too long to acknowledge them! (probably should be called "alerts" or "faults", though)

Giving something the proper name is always tricky. I should have used the word "Fault", not "Alarm". The words are often used interchangably, but like SFC/State Logic/Grafcet, it ain't necessarily so.

------

On the tangent of asynchonous I/O scanning in the CLX: (Man, I miss the old forum's ability to branch off threads when tangents occur)

I think every CLX programmer MOVEs all their I/O into internal tags - otherwise they'd go nuts. I still haven't come up with a single good reason to do it, at least not with inputs. I could make a case for outputs, but asynchonous does not mean immediate update, so even there it doesn't buy you anything.

 

[Rick Densing]

Perhaps a better term for X and Y would be "conditions". Like he said, alarms would be handled in different code.