First-out alarm sequence

Try to use File Bit Comparison (FBC) function to get the first-out alarm sequence.

AmazingTrans said:

Try to use File Bit Comparison (FBC) function to get the first-out alarm sequence.

Click to expand...

Is it possible for you to make an example for FBC to achieve first-out alaming sequence logic?

Are you using an HMI with the PLC? (If not, how are you being alerted of a fault)? Some HMIs have an Alarm list that will handle the first-in/out list for you.

FBC may or may not work, that is an AB instruction, doesn't apply to other PLC's.

How about doing the first breakdown on the entire word changing? That way you could look at 16 (or 32) bits at a time for the 'course' breakdown, then refine it to the bit later.

This is how I do it. It's easy for the maintenance guys to understand and easy to tie into the HMI screen. Maybe not the most efficient but I tend to place more value on quick troubleshooting by maintenance guys and also on not needing to come in and help them troubleshoot.

Trank said:

This is a comman way to use, that is, to disable others succeding alarms with first-out alarm, but what if there are many elements, say 50? In the old trick, 51 rungs ladder logic will be needed. Is there any other smarter way to do this to shorten the number of rungs for ladder logic?

Click to expand...

You can use indirect addressing and loop the logic to make it shorter. I do this sometimes if I or someone really familiar with PLC programming are going to be the only ones using it. If electricians and other engineers that are not familiar with the logic are going to be using it for troubleshooting purposes then I prefer not to do too much indirect addressing as it confuses them. I used to be into really neat programming tricks, but have learned through the years that unless they are really easy for novices to follow then it is better to make longer code that is easier to follow so that I can work on new projects and the maintenance guys can take over maintaining the stuff that has already been started up.

jtn said:

You can use indirect addressing and loop the logic to make it shorter. I do this sometimes if I or someone really familiar with PLC programming are going to be the only ones using it. If electricians and other engineers that are not familiar with the logic are going to be using it for troubleshooting purposes then I prefer not to do too much indirect addressing as it confuses them. I used to be into really neat programming tricks, but have learned through the years that unless they are really easy for novices to follow then it is better to make longer code that is easier to follow so that I can work on new projects and the maintenance guys can take over maintaining the stuff that has already been started up.

Click to expand...

Thans for your comment. Can you show the detail of your logic diagram for our reference?

I would stop processing the alarms once a bit is set, by bit or word comparison. Only re-process once the alarm is acknowledged and clear.

Just a bunch of "what-if..."

So... you get an alarm... it is the first one.

Then another alarm occurs... this one is more significant than the previous one. What happens? Does the "first-out" continue to be the primary alarm? Is it the only alarm condition displayed? What if the following alarm is more critical?

Just as in any human situation, shouldn't alarm conditions be handled on a priority basis? Kinda like... triage?

Of course, you need to keep all of the alarm conditions "in mind". However, when it comes to handling a crisis... first things first... no? Then, as one crisis is solved, display the next.

Yes, of course, the PLC should do most, if not all, of the crisis management. But in some cases, for whatever reason, there might be some aspects of the process that are out of the reach of the PLC. For example, there might be some cases where some part of the process is truely Manual if taken out of Auto! That is, while in Auto, the device is controlled only by the PLC, however, while in Manual, the device is controlled only by the operator (without PLC assistance).

At the very least, the PLC should have some kind of feed-back from those aspects of the process that might not be directly controllable by the PLC.

On the other hand...

Let's say that you have a friggin' huge automatic process that has many, separately initiated, sections. That is, an operator input is required to run any of the sections of the process. Then... let's say that the process is "circular"... that is... the "end" of the process is connected to the "beginning" of the process. You can't run the "end" of the process unless various other conditions exist at the "beginning" (or maybe some intermediate point where the "end" connects).

Not only can your alarm handler indicate how to handle a crisis situation in sequence (priority based), but it can also help the operators to figure out what is keeping them from doing what they want to do! Eventually, it ends up being a step-by-step... "How to...".

This becomes most effective in those situations where the employee turn-over is rather large. That is, there are always new-guys coming in from off-the-street... they don't know from nothing! ...except for that lousy training they got on their first day.

So... this might be reaching beyond the intent of the original poster... but... I've always felt that the HMI can be as friendly as the programmer decides to make it! I've always been surprised at how some programmers under-utilize HMIs... especially these days, when they, the HMIs, are capable of so much more!

Too many programmers look at the HMI as nothing more than a display version of a control panel! It can do sooo much more!

Assuming that the HMI knows that "Bob" is on-shift, the HMI could display a message that says... Hey, Bob... I think you need to check such-n-such... and you should do it now... before I have to shout it out, really loud... you know... with that damned horn that you hate so much!

Or maybe the HMI says... Bob, I know what you are trying to do... here is why you can't do that! At which point, the HMI displays the condition(s), in order of priority, that are preventing the action from occurring. As each condition is resolved, the next, lower priority condition, is displayed. And so it goes... until Bob is able to do what he wants to do!

I've got one of those... and no... it ain't easy... at least, not for the programmer (me). It is, however, GREAT for the user! And yes, a bit tougher for any maintainer...

HOWEVER... if my code is solid... there is no reason whatsoever to go into the code! The problems are displayed! In order of priority!

Once you have code that is reliable... any, and all, problems most likely come from the I/O devices... NOT THE CODE!

I really have to shake my head from side to side when I hear that code should be written so that the dumbest of the maintainers can understand it.

If anyone writes code that MUST be understood by... Bubba... (Don't be offended Ron. We all know what I mean)... then I have to wonder... how poor a programmer are you? And how the hell did you get into that position???

Warning... this is gonna be a hard one... but, it's nothing more than a reality-check...

Anyone that programs specifically for Bubba doesn't belong in a programming position!

Don't you get it???

To program for "Bubba" means that you don't have confidence in your own ability to make good code! You EXPECT that your code will fail!!!

Aaahhh... but then there is the situation where a program, written by someone else, is expanded, or modified, because of subsequent functional enhancements...

...and if the code is too hard to understand than it becomes too difficult for joe-blow to make the changes necessary...

Hmmmmm... I don't buy that as an excuse. If Bubba can't read what's there... then Bubba ain't up to speed. And... if Bubba ain't up to speed... then why is Bubba making the changes?

ALL PLC CODE CAN BE DECIFERED!

It's simply a matter of knowing what you need to know, and then taking the time to understand what you see.

I'm done with my rant... yeah, thank God... but... it's only because dinner is ready... and she is my primary "Keeper"!

This has been covered many times before.

I filed the answer to this under tidbits.
Terry, all that and no answer?
I gave a hint at least.

Firstout Logic

This is the logic i made, prolly quite common. Its on an CLX, but can be adapted to any AB PLC is you understand what its doing.

I agree with you Terry, Why should i go about making my logic easier for someone else to understand. I will, dont get me wrong, if it also effiecient. If "Bubba" dont understand, then "Bubba" shouldnt be trying to modify my program.

Terry, I'm getting to feel you have a deep routed sense of insecurity.

If the machine is a single entity, where a single fault would stop the entire machine, then the first alarm generated would be the thing that stopped the machine. Therefore you do not want to see cosequential alarms that could confuse the operators/maintenance.

If the machine is a large sprawling thing (conveying systems come to mind) and a single fault may not necessarily stop the line (parallel feeds etc), then you would not want to stop alarm processing the whole thing but depending on the alarm inhibit others. An example where I work, if the DP/ASi gateway circuit breaker trips, I could get one hell of a lot of alarms, therefore on it tripping (or the DP/ASi gateway indicating it is in fault), then all alarms from the devices fed from that gateway would be suppressed.

As far a 'Bubba's' concerned, a bit of an insult to everyday maintenance folk there, although I agree its better for them not to have to look in the code.

I remember in one factory, we had a pair of NSM palletiser/de-palletisers which our 'Bubba's' always had problems with when anything went wrong. The alarm handing wasn't the best and the program was what I call typical German, written in CSF (AND and OR gate respresentation) and very 'bity'. When fault finding, after 30 minutes they would find they were back on the same network they started at.

I re-wrote the entire code, seeing that each machine had about 13 distinct individual sequences, I spilt it into these sequences and on the HMI showed each sequence step position and what each sequece was looking for to complete each step, if a sequence hung-up, they knew to look at the item that was missed. They had virtually no problems fault finding after that and hardly ever had to look in the code.