TIA - Alarm Generation

mk42 said:

If it is the same 10 alarms in every case, Program_Alarm might deserve another look. Effectively, you only make 10 alarms, and the system does the rest in the background (assuming you're not in 1200, of course, but 1000 alarms sounds huge for 1200).

The Alarm text for each alarm can be made dynamic to include things like a tag value or the instance DB of the block it's called in. This way you can make one FB, with whatever alarms, and then every time you call the FB again it calls the alarms for you without you doing anything new. In Runtime the HMI sees MOTOR 1 Overcurrent, Motor 2 Overcurrent, etc, but it automatically pulls the MOTOR 1/MOTOR 2/etc dynamically from some something like the instance DB and you don't need to worry about it.

If your 100 FBs is 1 FB called 100x, this you could call program alarm directly. If each FB is truly different, than you could create an Alarms FB to call from inside each one, and map the alarm tags to it. Inside the Alarms FB you call Program Alarm.

Click to expand...

Will having several hundred instances of Program_Alarm in the program use up a lot of memory/resources though?

Jackllx said:

Will having several hundred instances of Program_Alarm in the program use up a lot of memory/resources though?

Click to expand...

Depends on your definition of "a lot", I guess.

I just threw something together in Portal, and compared before and after of calculating the alarms with just bits in a word vs triggering program alarm. The "bits in a word" method would have needed some other code around it for management, probably, but serves as a starting point.

For code work memory, there wasn't much increase. I had a standard FB with 10 alarms that got called 100 times. Adding Program_Alarm added 385 bytes for the instruction itself to be loaded to PLC as well as a little under 1000 bytes for adding the Program_Alarm calls. Note that this is a one time "cost" as the block doing the calling had minimum change.

For Data work memory, there was more increase. It used about 60kB of memory total for the 1000 instances of the alarms. That was about 5% of the 1511 I had configured.

Load Memory increased about 75kB, which left it at still 1% for the 12MB card I selected.

Overall, doesn't seem that bad to me. It isn't half the PLC memory or anything like that, but it's certainly more memory. From my perspective, optimizations don't mean much most of the time, unless you need them, in which case they are critical. If you know you're cutting it close on your CPU, might be a feature to avoid; but if that last 5% makes a difference on your CPU I'd be worried about other things, like expandability down the road.

Remember that if you use Program_alarm, you have to use S7-1500 and only Siemens comfort panels, as S7-1200 and Siemens basic panels don't support it. With bit-triggered alarms you are more flexible when you consider your library also for smaller / cost sensitive applications.

The problem of Program_alarm is not only the memory, but the cycle time it costs, especially on 1500 cpus at the lower end. There are users which program their own handling around it, that only a maximum number of alarms is triggered at one cycle, to avoid extreme high cycle times if you have many errors at the same time (e.g. power loss).

But an advantage of Program_alarm is, that it's timestamped when the message occurs in the plc, and not in the hmi. For some applications it's relevant to know which error came first.

Thomas_v2 said:

Remember that if you use Program_alarm, you have to use S7-1500 and only Siemens comfort panels, as S7-1200 and Siemens basic panels don't support it. With bit-triggered alarms you are more flexible when you consider your library also for smaller / cost sensitive applications.

Click to expand...

1200 and basic panels don't support, very true.

However, you can still get the text of the alarm into a Basic panel or a third party panel with the Get Alarm instruction, which reads the alarms into text that can be sent to the HMI. Downside is now you have to manage a buffer of strings and track them as they come and go.

I think the most recent FW allows for the 1500 to be an OPC UA Alarms and Events server, which could then link up to any OPC UA A&E client, but I dunno how many of those are out there in the wild, if that's more of a theoretical use case than a real one.

Thomas_v2 said:

But an advantage of Program_alarm is, that it's timestamped when the message occurs in the plc, and not in the hmi. For some applications it's relevant to know which error came first.

Click to expand...

It also makes it really easy to manage the alarms if you have multiple HMIs per PLC, you don't have to try to manage the text across them.

You can also read the alarms easily in Portal, on the web page, on the display, etc.


Sidebar: does anyone actually use the front displays on a 1500 for anything? I'm torn on whether its really really useful or a complete marketing gimmick.

Sidebar: does anyone actually use the front displays on a 1500 for anything? I'm torn on whether its really really useful or a complete marketing gimmick.[/QUOTE]

The only nice thing I have found is that I didnt have to run to the HMI to see what alarms are active. Can just read them on the cpu display

mk42 said:

Sidebar: does anyone actually use the front displays on a 1500 for anything? I'm torn on whether its really really useful or a complete marketing gimmick.

Click to expand...

Nope. I also use the ET200SP CPUs, which don't even have the display.

I think the display is useful to read out PLC diagnostics, in case that you have a PLC that wont go to run.
But if you use Siemens HMIs you can get the same functionality with the System Diagnostics View. I think it is actually better than using the small display on the CPU.
And if you don't use Siemens HMIs, there is the onboard web-server.
So, the display is nice to look at but is not so important in real life in my opinion.