Error Control Logic through Indirect Addressing

[JonSaundersTechEE]

I'm have been tasked with re-engineering the Error logic footprint of our machine Ladder program. I have the following issues to consider:
1.) Converting from processor type to another
2.) Interfacing with HMI's for Msg. Display
3.) Bit Mapping for proper error to Msg. alignment
4.) Memory conservation (this is where the indirect addressing comes in)

I have divided the errors into 5 groups to include priority order.

N12:1 - Major errors
N12:2-3 Machine device input errors
N12:4 - Mechanical Feedback Errors
N12:5 - Interface and low priority Errors

I wanted to use N12:0 as the Control Word in the Msg. display and PLC. I want to use N12:0 to determine the Error priority. For example. If an error occurs within B3/0-15, N12:1 will contain the mapping from the PLC to the HMI. and display the message via N12:0. If an error occurs within B3/16 - 46, N12:2-3 will contain the mapping from the PLC to the HMI. And display the message via N12:0 (Indirectly)

This should allow me to use N12:0/x to call the corresponding screen and still use the same Tag (N12:0)

I have heard of this type of programming method being used on Motor Control adjustment Screens but I have never designed one myself. If anyone can help, please contact me. I'm not looking for someone to do the work for me just point me in the right direction.

I am well versed in PID control and have written many modified PI routines. If I can be of help just ask.

We all have our strong points I hope someone will be willing to share theirs.

 

[Allen Nelson]

Welcome

Welcome to the forum. I'm sure we will be able to help eachother out.

But first we are going to need to more information about your project.

There are many things to consider when setting up an alarm system. On of the first is scalability.

In reading between the lines of your post, I'm guessing that you are only expecting to ever, in any project, only define 16 major errors (whatever those are), 32 "Machine device input errors", 16 Mechanical Feedback Errors, and 16 Interface and low priority Errors (again, whatever those are). In that way, you will have one bit per error (alarm point), and there will be a natural priority built into the alarms (depending on the HMI you use, of course)

Before we start on your engine, are you sure that this is the right balance? 32 sensors which detect trouble (e-stops, door switches, out-of-bounds PEs/prox's) to support only 16 output seems a bit off (of course, the only outputs that count are those that have feedback).

When you say one of the considerations is:

1.) Converting from processor type to another

do you mean converting from SLC 5/05 to 5/04 to Micrologix to PLC-5, or does you mean AB to Siemens to AD to GE? You use N12: in you example (implying AB), but just how generic do you mean to make it?

I first suggest that you look at THIS OLD POST of mine. It's a good as an introduction to alarms as any, and might give you some ideas on how to set up alarming.

Now to what you say you are trying to do.... I'm afraid that I don't see what you mean by the phase "[N12:xx] will contain the mapping from the PLC to the HMI." It looks like your alarm coils will be in your B3 file, and you are just planning on doing a MOV or COP to get the alarm info into an HMI-common area (N12:1-5).

Again, I'm guessing, but it looks like you are asking to devise some logic that will find the bit number of your highest priority alarm, and stick that in N12:0. In other words, if N12:1/5 is set, then N12:0 would have a value of 5. If N12:2/1 is set (and all the N12:1 are reset), then N12:0 would be 17.

Is this a correct guess? If so, you might want to check out THIS POST on how to extract the first non-0 bit in a word.

To get much more, you are going to have to post again and expain what you are attempting to do in more detail.

 

[93lt1]

Sounds like fun.

For starters,
Is this a PLC5 or a SLC?
What is the HMI?

I am guessing SLC5/03,04, or 05 with a Panelview.

You want to display an error message based on which bit (B3/XX)is on, some have priority.

You want to change the current screen of the Panelview to a different screen based on the severity or category (priority) of the current alarm.


Please reply and let us know if we're heading in the right direction here.

 

[JonSaundersTechEE]

Error Control Logic through...detailed

1.) Converting......We often have requests for different processor types; TI, Modicon, Siemens, and so on. The core needs to be easy to carry over if you know what I mean. But for this immediate project(that will set the future standard) I will be using a SLC 5/05 PLC that will interface to an Panelview 1000 Plus.

N12:0 will control each alarm screen. If an alarm is triggered in the first word(example:B3/0-15 N12:0/1 will be set. B3/0-15 will be mapped into N12:1 and will be the tag located in the PV1000 and will manage the alarm descriptions. N12:1 Alarms are E-stop, Door switches, Light Arrays and any Safety related issues. N12:0/2 or 0/3 is triggered by B3/16-46 and N12:2 or 3 will manage the alarm descriptions for these errors. These errors are "low temp" "high temp" "low pressure" "high pressure" and so on. I allowed 32 bits for expansion as the machine is modular and can increase or decrease based on customer demands. The remaining errors should follow this some what redundant order.

I want some complexity but only to help sustain the core of the format. The errors could be reflected by other internal bits later programmed by the customer however an MVM instruction (providing the PLC is SLC 5/03 or higher) will re-map there errors into the Engine N12. If I'm over complicating things its simply in my nature [I hope this gives better direction Allen]

{93lt1}

I initially wanted to overlap message boxes with scrolling messages but decided an Alarm Screen for each bank of errors with Acknowledgement from the operator would be better. This will require attention when Major errors are triggered and minor errors can be acknowledged with "snooze"(time delay)for continued operation.

I hope this sheds more light guys and Thank you for your interest and help.

 

[93lt1]

It sounds like you have it figured out.

I'm not sure if the PV+ will allow a bit level screen control. I haven't tried it yet.

What do you want to do with indirect addressing?

Define "mapped"

It might be easier if you start with the desired end-result... What do you want the operator to do/see in alarm conditions.

Everyone here probably does their alarm handling a little bit differently. I think if you start with the desired end result you will get more discussion.

 

[Allen Nelson]

....Reply Hazy, Try Again Later.....

I'm still very confused as to exactly what you are trying to accomplish.
You said:

N12:0 will control each alarm screen.

That's a sentence loaded with possibilities.

• What do you mean by "each"? Will you be having more than one alarm screen? More than one PV?
• What do you mean by "control"? How? Will setting the bit cause [*}What do you mean be "alarm screen"? Will you be using the canned panelview alarming function, or building your own? Either way, what you do for a Panelview may not work on a TCP or a Panelmate screen (probably won't). Each HMI is different, often radically enough to make a "universal engine" an unreachable goal.

You said:

...alarm is triggered in the first word(example:B3/0-15 N12:0/1 will be set. B3/0-15 will be mapped into N12:1

If that's all, then the logic is easy:

                 +--- MOV --+

-----------------| B3:0     |

                 | N12:1    |

                 +----------+

 

         +--- NEQ --+      N12:0/1          

---------| N12:1    |-------( )

         |     0    |

         +----------+

But somehow, I don't think this is anything close to what you are looking for.

In reading this sentence:

I initially wanted to overlap message boxes with scrolling messages but decided an Alarm Screen for each bank of errors with Acknowledgement from the operator would be better.

I begin to get the idea of what you are envisioning, but ou should know that in every HMI that I have worked with, there is only one "alarm screen object" that you drop on a screen. They will all read from the same global list. Some might allow you filter alarms based on "area" - others not. The panelview is one of the "not".

Again, give more details. Lots more. Start from the begining. Do not use register numbers. Explain things as though the PLC and the HMI are black boxes. Explanations should follow the "When this occurs, the operator will see that." or "When something happens, the PLC will respond thusly". Use as many words as possible. We can't help you if we don't understand, and right now, I, for one, don't understand.

 

[JonSaundersTechEE]

Perhaps I should try a different approach

Perhaps I should try a different approach……….

Allen you are “right on” with the PLC logic example! Thank you.



I want the screen to use a simple text message display for simplicity sake.

The only catch is error logging. When the error is acknowledged by the operator, the HMI reverts back to the main screen or last screen before the error occurred. (I know how this is executed. Save the last active screen and then load it upon a successful “reset”) I need to list the last 3 or 4 most recent errors.

Let’s say you were tasked with building an error table consisting of 5 priority groups with 1 being the highest and 5 the lowest. You wanted to ensure that the error (based on its level of priority) was attended to by the operator but only on error alarms, that if overlooked, would adversely affect the end result of the process. Obviously an E-Stop would catch the attention of the operator as will as the opening of a guard, Drive faults, clutch trips or line crashes (same effect as an E-stop) but a low temp alarm might be ignored due to preoccupation of unrelated factors. A drop in air pressure due to a seal showing signs of ware may also go unattended. Few items would require operator intervention that would not normally interrupt the machine operation however there are a few and the flexibility is always an added bonus.

I hope this is a little more information. The end result should embody a core easy enough to understand that converting from PLC to PLC would be a mater of Data entry more so than reengineering.

 

[JonSaundersTechEE]

I have been out of town for a few days and away from my PC. Can we try to look at this once more? Please review my reply above. I hope I did a better job outlining what I am trying to achieve.

 

[Allen Nelson]

A different approach

From your descriptions, you are looking to make generic PLC code to use on a generic HMI.

First let's start with the HMI.

From your description, it doesn't look like you can use any HMI's canned alarming package, because not all HMI's (in fact, very few) allow you to sort an alarm list on anything other than time-of-occurance (let alone even have 5 levels of "priority" (typical is 3 - "Warning", "Danger", and "Run-for-your-life" (or something like that)).

So instead, you are going to have to roll your own alarming package, with screen-change control, and perhaps the canned message system in the HMI (which not all have).

In doing so, there is going to be different PLC code to support these different HMI's "special" method of operating. Since each HMI will be different, each PLC code that supports it will be different. A generic program isn't possible.

---

But there's a subtle assuption built into what you are trying to do.

You don't trust your opeatators.

Now why is that? Have they ignored alarms, to the detriment of the machine? Why would they do that? Don't they trust your alarms? Don't they know what to do? Haven't they been TRAINED?

You have this as an example:

A drop in air pressure due to a seal showing signs of ware may also go unattended

. Is the PLC capable of detecting whether the low pressure alarm is due to a worn seal, or just that someone goofed and openned the wrong valve? If not, then they will get trained, just like a dog, to ignore the "drop in air pressure" every time it shows up. You will give them a nussance alarm, and they'll automatically acknowledge it without even thinking for a second.

I've been in the field too many times, and I struggle with it. While I want to train the operators on my systems during the startup, I'm also aware that because it's a startup, things aren't perfect yet, and so I'm creating some bad habits along with the good training. Especially in the area of alarms.

But taking the operators to a special screen, and shoving what you think will be the most important alarm to the top of the list isn't going to do much to help the guys. It's like Microsoft Word "helps you", except that it guesses wrong more often than right. It's "unhelpful help", and only breeds dislike of your system, which is not your goal.

Your best bet is to limit the number of alarms, so that when they do get one, they respond with the appropriate concern.

So, don't alarm e-stops, door-switches, and the like. Alarm things like E-stop+Start_PB, so that the operator will know - oops, I just tried to start the machine with an e-stop still in.

You need to start respecting your operators. Understand that they are fallable (and so are you, and so is you machine), but also intelligent enough to read a screen.

It's YOUR job to give them the information they need to do THEIR job. It's an art, not a science (and therefore, not codable). If you give them too much, they it will be as if they CAN'T read the screen. If you give them too little information, they won't see what they need (it should all fit on one screen, after all).

But then again, this is why they pay you the big bucks, right?

 

[alphageek]

I like where you (Allen) are going with your description of what to alarm.

Could you guys flesh out your philosophy as to what to alarm? e.g. what to indicate on the HMI (and how), what to indicate visibly (with indicator lamp or andon or light stick), and what to indicate audibly.

 

[RichBlunt]

I think if your trying to develop an alarm "philosophy" that u can pass from plc to plc regardless of manufacturer, you need to get down to what all PLCs have in common and are capable of, which would be bits and words

As I understand it, you want the following:

1.Priority to factor in
2.Switch screen on HMI approcriate to alarm

I would hold let the word being used hold the priority, ie
word 1 would be E-stops
word 10 would be valves/switches
word 20 would be low level production type stuff, ie overcycles

so when I sorted my alarms if word 1 is filled then I would disregard word 10 and word 20 alarms

As for screen switching, I would first make sure all E-stop information was on the same screen, then I would have screens for individual stations, therefore my screens would be related tied to the logic.

If your looking for something much more complicated, this is an area were people who program all the time may need to be consulted. I have often seen standards adopted, and later they do not fit when applied to future projects. (dont get me started )