Alarm tags - bits

I’m playing with the latest Ignition to see, what’s possible to do with it.
I’m in automation business for over 25 years and I have been dealing with numerous SCADA systems and PLC programming over these years. Last few (like 10) years I’m mainly on SIEMENS SIMATIC STEP7 PLC and WinCC.

What I’m struggling with in Ignition is, how to define alarms.
In all other SCADA systems, that I have worked with, you must first define some tags and then alarms (for discrete/digital alarms). I have always defined tags in form of words - 16 bit (or double words - 32 bit). That’s because when you have for example 500 alarms (and warnings) you don’t need to define 500 tags; only 32 tags (16 - bit tags) or 16 tags (32 - bit tags).
Then, in the alarm manager, you define your alarm texts and you can assign to each alarm (text) the bit of the tag, for which you want the alarm. For example:

  • In tags I defined MW100 (merker-flag word 100, which has 16 bits: from M100.0 to M101.7, in Siemens PLC).
  • In alarm manager I assign to first alarm tag MW100 and bit 0 (that’s M100.0), to second alarm MW100 and bit 1 (M100.1), to third alarm tag MW100 and bit 2 (that’s M100.2),… and to the 16’th alarm tag MW100 and bit 15 (that’s M101.7).

Now, in Ignition, I can’t find the way to do that… :frowning:

I know, that I can make all 500 tags as Boolean and define for each tag Alerting properties, but that’s to much… Why would you have 500 tags, if you can have 32 (16 bit) tags ( or 16 (32 bit) tags)… :question:

I refuse to believe, that such great product, like Ignition, doesn’t have that option…

Can somebody point me to the right direction?

Regards from sLOVEnia

EDIT: I (soft of) find a way… with the help of others in this thread. :prayer:
See my last post…

Anyone… :frowning:

What you want may require some scripting, depending on how you expect it to work. I can think of the following items that you would want to consider:

  1. Lookup table in the database to enumerate your alerts. I would have 1 row for each alarm, with identifying columns for word, bit, and whatever else you need to id it. This will probably be used for the rest of the steps.

  2. Email/text message on change. You could use the built in tag alerting on a change, but I suspect that you may need script to be able to respond to multiple alerts and provide adequate information based on your lookup table (since you have 500+ alarms).

  3. Way of logging on change for “Alarm History”. You need to support multiple records when you have simultaneous alarm bits on.

  4. Way of displaying “Alarm Status”. What is currently in alarm? This can be multiple alarms. Do you need to know how long it has been in alarm here (besides looking at the history)?

  5. Way of acknowledging. Is this a matter of returning that bit to 0. How do you record who acknowledged it and when?

It’s worth noting that Alerting is scheduled for an upgrade in 7.6. This includes: re-notifying, contact groups, escalation, remote acknowledgement, etc. I added an annotation for native support for combining

Someone help if there’s an easier way…

It occurs to me - you can probably quickly and easily accomplish most of what you want with the built in alerting system.

First separate “important” versus “non-important” alarms to notify operators without enumerating 1000s of alarms. This can be done easily by comparing the word as an analog value (if your high bits are important) or using a separate tag with a little logic in your PLC. You can send them the analog values, but I wouldn’t recommend it. Alarms tell the operators that they need to log on to the system to see what is going on.

You then just need to provide the operators with a means of translating the alarm in the “alarm history”, which is really just bit masking. You can do this with expressions or scripting. So the operator clicks on the alarm and a popup window or graphical element on the screen explains what it means (which may be multiple simultaneous alarms). You could also provide a search/filter that allows them to select a specific condition, then displays all alarms that contain that. Keep in mind that storing alarms this way uses 1 record at a time, so simultaneous alarms are stored together.

Thank you for your detailed answer… :confused:
But that’s a little to much for me… :blush:

Call me old fashion or spoiled, but I’m used to simplicity…
I all SCADA’s I’ve worked with (ok, lately mostly with SIEMENS) it’s more or less simple:

  • you define tags (all, for alarms, for screens, for archiving, …)
  • when you create alarms, you choose tag, you choose bit in that tag (if it is byte or word or double word) and write some text to show up

Don’t take me wrong… I like Ignition, I like the idea, but I simply can’t accept, that you must define all boolean tags for all digital alarms and warnings.

In one of our latest project (a thermal power plant flue gas cleaning station) we had over 2000 alarms and warnings, which must all be shown to operator immediately. I have used WinCC for that project and I can tell you, it was fairly simple to configure all alarms. I think I had around 70 tags (double word - 32 bit) for all digital alarms and warnings (all together we had around 2500 tags). The ‘hardest’ thing was to type all the texts… :slight_smile:
Imagine, that I must define over 2000 boolean tags… what would that do to the network trafic between PLC and SCADA server and not to mention the price for number of tags license…

I know, that with scripting and SQL a man can do miracles (if you know how), but…

I appreciate your work, guys, on Ignition… I think is great product… I just want you to think about implementing ‘something simpler’ to define digital alarms not only through boolean tags, but also with bytes, words and double words (8 bit, 16 bit and 32 bit tags).

Regards
Anton from Slovenia, Europe

1 Like

To the best of my knowledge, Ignition alerting does not support the notion of separate alarms that are mapped to conditions (ie, specific bit of a word). Ignition alerts are tied to tags. You could set up individual tags (DB type) that are based on expressions of the alerting words that you have set up. This changes nothing in the PLC. It wouldn’t affect network traffic either. It also doesn’t cost anything in licensing. It would require the creation of all those (2000-ish) tags within Ignition. You could probably do it quickly with a CSV import/export once you get a few created correctly.

You might be able to do bitwise alerting with a transaction group in the SQL Bridge module. Perhaps Colby or Travis could help out here. I’m not sure.

Nathan,
I beleive the Alarming is something Inductive has not fully considered as an important feature of Scada. For those of us who are migrating up from a legacy Scada ( W/W, RSView ), the alarming is something that cannot be properly implemented.

I posting a feature request a few months ago about the ability to print an alarm to an audit trail line printer. The response was this is something that is not even being considered.

I am on a job site now converting RSView to Ignition and have to inform the customer he will no longer get an audut trail record on a dot matrix printer of system alarms.

I realize we can generate a query page and filter and print alarms to a sheet printer, but the customer wants an audit trail.

Point taken. I posted a survey below to gauge customer feedback on alerting, ask for suggestions on how you would like it to work, and ask for feature requests on the topic.

Tell me more about the printer at the customer’s site. It might be something that can be made to work currently.

viewtopic.php?f=71&t=7061&p=20884

Thanks for the reply.
Printer is Okidata Dot matrix serial/USB printer.
Line printers are used to provide a one line printout to provide a hard copy audit trail of alarms . Similiar to how security systems use audit trail printers to log zones being activated.
One line printed per event, not one page.

Hi Anton,

To get back to the original post, strange as it might seem to you, unfortunately it’s not possible right now. We recognize that the alerting features are a bit limited, and intend to work on them soon. It might be possible to layer in something like you describe over the current system, or we could take it into consideration when designing the upgraded system.

Would it be sufficient if right now the “analog” states also let you specify a bit position instead of an analog value? That would mean that all of the alerts would be under one tag, and would share the custom message, display path, etc, but would have their own state name and severity. I’m not promising we could do this, but it would be the most direct path for preventing the creation of individual tags, for the time being.

In regards to the printer (I feel bad hijacking this thread) - this would ideally be done as an module with the SDK. If you feel up to it at all and can figure out how to programmatically write one line at a time to the printer (and have a device to test with), I can help you with the rest of it over in the module developer forum (you might need to sign up for the dev program to get access).

Regards,

Colby,
that would be a start in the right direction.Majority of legacy systems out there have the PLC generate alarms, and the SCADA used to record and provide a history.
PLC alarms are best generated using a word, 32 bits in Contrologix PLCs, and each bit represents an Alarm.
The SCADA is Alarm system is configured to read that alarm word (s) and another parameter specificies the alarm word is at the bit level .
Then alarm messages are configured for each bit.

then of course, another option to send particular alarms to a line printer.

then i will be :smiley:

[quote=“Colby.Clegg”]Hi Anton,

To get back to the original post, strange as it might seem to you, unfortunately it’s not possible right now. We recognize that the alerting features are a bit limited, and intend to work on them soon. It might be possible to layer in something like you describe over the current system, or we could take it into consideration when designing the upgraded system.

Would it be sufficient if right now the “analog” states also let you specify a bit position instead of an analog value? That would mean that all of the alerts would be under one tag, and would share the custom message, display path, etc, but would have their own state name and severity. I’m not promising we could do this, but it would be the most direct path for preventing the creation of individual tags, for the time being.

In regards to the printer (I feel bad hijacking this thread) - this would ideally be done as an module with the SDK. If you feel up to it at all and can figure out how to programmatically write one line at a time to the printer (and have a device to test with), I can help you with the rest of it over in the module developer forum (you might need to sign up for the dev program to get access).

Regards,[/quote]

Thank’s for your answer.

Look, don’t get me wrong… :slight_smile:
I found about this software on the Internet, and I said, let’s see… I don’t have any intentions to switch to Ignition just jet. I’m just looking, what’s possible. And of course I’m comparing it to other software, which I know.
Until now, I like it very much, but the alarms feature is one of the most (if not THE most) important thing of the SCADA systems (IMHO).
And I completely agree with ‘Curlyandshemp’:

[quote]Majority of legacy systems out there have the PLC generate alarms, and the SCADA used to record and provide a history.
PLC alarms are best generated using a word, 32 bits in Contrologix PLCs, and each bit represents an Alarm.
The SCADA is Alarm system is configured to read that alarm word (s) and another parameter specificies the alarm word is at the bit level .
Then alarm messages are configured for each bit.[/quote]
I will monitor Ignition for improvements regarding alarms, and then we’ll see. I have shown this software to my boss and my colleagues and they also like it, but not the alarms/alerting features.

Regards
Anton from Slovenia, Europe

Here’s a reference to a topic I put up that may help a bit… no pun intended

viewtopic.php?f=25&t=6655

It applies to Controllogix PLC’s & Kepware, but I have a feeling it should work for other PLC’s through Kepware also… not sure if it can be done this way through the built in OPC-UA drivers in Ignition though…

I always work with bits in a register for alarms… I did all the work in xml files and then imported them… worked like a charm…

Anton- We appreciate your feedback, even if you’re not switching yet :slight_smile:

Hopefully we’ll get to alerting soon. The problem is, for some customers it is the “most important feature”… but for other customers, it isn’t. And from those other customers, we’re always getting requests for their “most important features”. So, you can see our problem :laughing:

Anyhow, thanks again for taking the time to post, and please continue to check in from time to time.

Regards,

[quote=“Curlyandshemp”]Colby,
that would be a start in the right direction.Majority of legacy systems out there have the PLC generate alarms, and the SCADA used to record and provide a history.
PLC alarms are best generated using a word, 32 bits in Contrologix PLCs, and each bit represents an Alarm.
The SCADA is Alarm system is configured to read that alarm word (s) and another parameter specificies the alarm word is at the bit level .
Then alarm messages are configured for each bit.[/quote]

So if using a 32 bit DINT in a CLX is the best way to generate an alarm, would a 64 bit LINT be better?

I fail to see the rationale behind this post. Using a DINT with an index would save you no time what so ever compared to just mapping each bit from those words to an individual SQLTag. The bulk of the work is hand entering the alarm message anyways. Any spreadsheet application will make short work of that.

Also, printing to a line printer should be quite simple and trivial on any MAC or Linux based system. You can do it with native OS calls apparently.

mail.python.org/pipermail/tutor/ … 73725.html

Windows may or may not work the same way.

Dont get me wrong, I am in the same business as you, with plants using the same printers, but at the end of the day, a audit log for alarms should reside in the database in my mind, and utilizing a line printer works against one of the strengths of Ignition, which is logging and visualizing data in a database.

As far as a printer goes, would the TCP/UDP driver be of any benefit, now that there is a writable tag available?

[quote=“Kyle Chase”][quote=“Curlyandshemp”]Colby,
that would be a start in the right direction.Majority of legacy systems out there have the PLC generate alarms, and the SCADA used to record and provide a history.
PLC alarms are best generated using a word, 32 bits in Contrologix PLCs, and each bit represents an Alarm.
The SCADA is Alarm system is configured to read that alarm word (s) and another parameter specificies the alarm word is at the bit level .
Then alarm messages are configured for each bit.[/quote]

So if using a 32 bit DINT in a CLX is the best way to generate an alarm, would a 64 bit LINT be better?

I fail to see the rationale behind this post. Using a DINT with an index would save you no time what so ever compared to just mapping each bit from those words to an individual SQLTag. The bulk of the work is hand entering the alarm message anyways. Any spreadsheet application will make short work of that.

Also, printing to a line printer should be quite simple and trivial on any MAC or Linux based system. You can do it with native OS calls apparently.

mail.python.org/pipermail/tutor/ … 73725.html

Windows may or may not work the same way.

Dont get me wrong, I am in the same business as you, with plants using the same printers, but at the end of the day, a audit log for alarms should reside in the database in my mind, and utilizing a line printer works against one of the strengths of Ignition, which is logging and visualizing data in a database.[/quote]

There is more to than just using the DINT to generate alarms. Never considered a LINT, but i use the DDT ( Diagnostic detect ) to generate a queue of most recent alarms in the PLC. This instruction only works with DINTs.
I beleive the alarms, and recording ( audit trail printer ) should still within the control of the PLC. Ignition runs on a 'puter and last time I checked 'puters still lock up, freeze go to la la land.
I’ve been doing this for 25 years now, and always design a control system where I can remove the SCADA and no functionality of the controls is lost , other than scheduling new batches or recording data if the 'puter is every rebooted.

Nothing wrong with that. In fact I keep all alarms at the PLC. Ignition monitors my alarms and logs them and sends email alerts accordingly. As far as a paper trail goes, there are still ways to have one controlled by the PLC.

[quote=“Curlyandshemp”]
Ignition runs on a 'puter and last time I checked 'puters still lock up, freeze go to la la land.[/quote]
And batteries go bad in PLC’s and memory can still get corrupted, and HMI’s can do odd things. On the other hand I have robot installations that are at 7 years operation that are PC-based control. Let’s try not to degenerate into the PLC’s are better than PC’s or vice-versa. Each have their place. The trick is knowing how to get the most out of both! :slight_smile:

[quote=“Curlyandshemp”]
I’ve been doing this for 25 years now[/quote]
Ok! you win! I’m only at 21. :laughing: Sorry, just had to toss that one in. Sometimes, I’m surprised by how well we last!

All I’m saying here is that there is a paradigm shift when using Ignition. It can do so much more than SCADA or HMI that the possibilities are almost staggering. But it may also require us to adapt our programming behaviors.

Myself, I’m trying to get away from It’s how I’ve always done it to How can I get new new guy to change this scheme for me… That one hasn’t worked yet, but I can dream. :mrgreen:

[quote=“Curlyandshemp”][quote=“Kyle Chase”][quote=“Curlyandshemp”]Colby,
that would be a start in the right direction.Majority of legacy systems out there have the PLC generate alarms, and the SCADA used to record and provide a history.
PLC alarms are best generated using a word, 32 bits in Contrologix PLCs, and each bit represents an Alarm.
The SCADA is Alarm system is configured to read that alarm word (s) and another parameter specificies the alarm word is at the bit level .
Then alarm messages are configured for each bit.[/quote]

So if using a 32 bit DINT in a CLX is the best way to generate an alarm, would a 64 bit LINT be better?

I fail to see the rationale behind this post. Using a DINT with an index would save you no time what so ever compared to just mapping each bit from those words to an individual SQLTag. The bulk of the work is hand entering the alarm message anyways. Any spreadsheet application will make short work of that.

Also, printing to a line printer should be quite simple and trivial on any MAC or Linux based system. You can do it with native OS calls apparently.

mail.python.org/pipermail/tutor/ … 73725.html

Windows may or may not work the same way.

Dont get me wrong, I am in the same business as you, with plants using the same printers, but at the end of the day, a audit log for alarms should reside in the database in my mind, and utilizing a line printer works against one of the strengths of Ignition, which is logging and visualizing data in a database.[/quote]

There is more to than just using the DINT to generate alarms. Never considered a LINT, but i use the DDT ( Diagnostic detect ) to generate a queue of most recent alarms in the PLC. This instruction only works with DINTs.
I beleive the alarms, and recording ( audit trail printer ) should still within the control of the PLC. Ignition runs on a 'puter and last time I checked 'puters still lock up, freeze go to la la land.
I’ve been doing this for 25 years now, and always design a control system where I can remove the SCADA and no functionality of the controls is lost , other than scheduling new batches or recording data if the 'puter is every rebooted.[/quote]

You state that the alarms and recording should still be in the control of the PLC, then why do you want Ignition to print to an audit trail printer? Im confused. Also, you can still create alarms in DINT, LINTs, INT or BOOLs, but I dont see how mapping in a DINT as one tag with an index vs 32 individual SQLTags would make any part of your alarm structure any simpler. Generating the alarms should occur in the PLC itself. It generates no extra traffic to the PLC, and is easily manupulated via a spreadsheet program. If you are worried about your SCADA server failing, set up a redundant setup and you are good to go.

As for the audit trail printer, I would do everything I could to get rid of those. The problem I see with our industry is every company has a lot of “data islands”, separate systems logging related data, and no way to use all that data. Ignition lets you start eliminating that effect, and helps create a single software solution clients. Almost all our work and return work is based on the fact that we can present and analyse data in Ignition.