Event Messages in STEP7

I need help understanding how event messages are handled between my siemens PLC and my siemens Touch panel. If someone could give an example that would be great.

I suppose that you are talking about S7-300/S7-400 and not S7-200.
Also, I suppose that you mean "regular" event messages and not the ALARM-S system that is a special way of handling alarms and events with S7 PLCs.

Regular event messages are extremely simple:
In Protool you have to add an "Area Pointer" of type "Event Messages". You have to specify a number of merker words or data words that are used for the event messaged. Each bit in the assigned words correspond to a particular message.
In protool open the "Messages" .. "Event Messages" and enter the text for each message. Each line correspond to a bit. Notice that when a particular message line is selected, the corresponding bit address in the S7 PLC is displayed in the lower right corner of the screen.
In Protool open "System" .. "Screen/Keys" and there specify how messages should be displayed. You can choose to display it as a line or as a window.
In the S7 program you then trigger the bit for a particular message when you want that message displayed.

Hi Jesper,

I haven't got round to doing all my alarm messages yet, but it's getting pretty close. Your answer implies that under some circumstances it's not necessary to use ALARM-S.

Two questions, when must you use ALARM-S, and what are the advantages / disadvantages of using each method.

According to the ProTool help-file, one advantage of ALARM-S is that since they must be generated in S7, they are automatically available to many different (types of) HMIs. Is this the only advantage?

A related question, disregarding data transfer aspects (which I'm aware may not be wise on a very large system) how do you generally group your error Bits. I'm having difficulty deciding whether to group the errors by function ("switch X out of each Module", or "all motor driven switches"), or by Module.

I'd appreciate your thoughts on the matter.

Cheers

Roy

Hi again Roy.

I dont think there are any circumstances where you must use ALARM-S.

Advantages (as I see it):
1. Offloading the network. This because the HMI doesnt constantly poll all the alarm bits, in stead the PLC sends an alarm message once per alarm instance. Also, all HMI stations recieve the alarm message at the same time.
2. The alarms gets timestamped down to the millisecond (obviously this can only have an accuracy as good as the scantime of the PLC).
3. Some central integration. The alarms and their messages can be "managed" centrally (with P-DIAG I think).

Disadvantages (as I see it):
1. It only works with Siemens PLC's + Siemens HMI's.
2. It takes more than just an afternoon to learn how to use this system (as usual with Siemens).

About grouping the alarms:
I think that an alarm message should be so precise (hardware speaking that is) as possible.
"Limits switch E123 wasnt reached 5 seconds after activating valve Y456." is alot more helpful than "There was a timeout when opening a valve." When I can, I try to describe exactly what inputs and outputs should be checked and maybe what page in the documentation is relevant as well (with the additional help-text that you can define for each individual alarm).
In the PLC programs I have standard FBs for the various kinds of "objects" (like conveyors, valves, silos etc.). The alarms for one kind of object are boolean "outputs" on the FB. That frees me to pack the alarms in the memory area associated with the HMI alarms.
One could speculate if it would be smart to pack a group af alarms in a word at a time. My "objects" are so diverse that it would not be a good strategy for me, but maybe for others it could pay off.

2. It takes more than just an afternoon to learn how to use this system (as usual with Siemens).

Click to expand...

I know, I've had a look at it a couple of times already and I'm still floundering. I'd forgotten that doing it in ProTool would mean constant polling would be necessary. While there's plenty of time available, the sheer number of potential alarms to be scanned would make for a massive communications load.

Apart from that, the chances of me ever seeing another project with time scales like this one must be about 10,000 to 1 (probably more), so I think I might as well bite the bullet and learn about ALARM-S while I've got the chance to do it at my own pace!

Roy.

How many alarms do you have ?
Remember that you can have max 2000 alarms in Protool (+ 2000 event messages).
At 1.5 Mbps and a tag updating of 1 second (for example) I dont think that the communication will be so penalised - even with 2000 alarms.
2000 alarms + 2000 events is equal to 250 power tags.

How many alarms do you have ?

Click to expand...

Not too sure yet, just going through it quickly, I come up with about:

H/W (DOs, Motor-Driven switch travel etc.) ~250
Process (Mainly Transition supervision in GRAPH7) ~700
H/W (DIs, Interlocks, E-Stop, etc.) ~50 - 100
+ whatever I haven't thought of in that bunch!

What's a little more worrying are the Power Tags - how are they calculated? We're running at 1781 at present and while I wouldn't expect a lot more to come, with this customer there's no way I can be sure of that!

Every time that you access a tag it is called a powertag. It doesnt matter if it is a bool or an int, they count the same.
One way of saving powertags when displaying animations is to avoid animating with bits, but rather use the "bit in tag" or "value of tag" to animate many different states.
Also, one way of saving powertags when setting options from the HMI is to avoid the "set bit" but rather use the "set bit in tag".
Alarms and events doesnt count in the powertags, they are "free".

In WIN CC Flexible the count of tags should be even more frugal. You can create an array of tags. And all the tags in the array will only count as one powertag, no matter how big the array is.

2000 alarms + 2000 events is equal to 250 power tags.

Click to expand...

Alarms and events doesnt count in the powertags, they are "free".

Click to expand...

Now you've got me slightly confused! Or did you mean from a communications point of view, as far as load is concerned, that 2000 Alarms + 2000 Events is equivalent to 250 Power Tags?

Using the Bit Set in Tag doesn't help me really, because I'm not doing any animation as such in the pictures. Apart from that the Siemens warning that if you do this, the PLC shouldn't write to the Bits because ProTool writes the whole Tag and would therefore overwrite any changes, is unusually loud! I also seem to remember reading a recommendation (which I can't find, at the moment), that if your PLC supports Bit commands, then you should use this in preference to Bit in Tag commands. Did some of the S5s not have Bit commands, or are they just trying to sell more licences?

Now you've got me slightly confused! Or did you mean from a communications point of view, as far as load is concerned, that 2000 Alarms + 2000 Events is equivalent to 250 Power Tags?

Click to expand...

Sorry about that. I meant to say that the communication load from the max amount of alarms and events should equal the communication load of 250 power tags (2000 bits + 2000 bits = 250 words).

Apart from that the Siemens warning that if you do this, the PLC shouldn't write to the Bits because ProTool writes the whole Tag and would therefore overwrite any changes, is unusually loud

Click to expand...

The HMI transmits the entire tag when you use the "set bit in tag" function.
I use the "set bit" or "set bit in tag" for START and STOP user commands and the like.
I then evaluate the bits in the program, and then clear the entire word.
It gives me the safe equivalent of a regular pushbutton, but with one-shot functionality.

The HMI transmits the entire tag when you use the "set bit in tag" function.
I use the "set bit" or "set bit in tag" for START and STOP user commands and the like.
I then evaluate the bits in the program, and then clear the entire word.
It gives me the safe equivalent of a regular pushbutton, but with one-shot functionality.

Click to expand...

That's a neat trick, since you don't appear to have copyrighted it, I think I may steal it!