Capturing I/O values at alarm condition

[kaiser_will 65]

I am working on developing a data collection/machine reporting system for our customer base. An idea that came up was to capture I/O values at the time of an abort alarm condition. With most of our I/O being discrete, this should not be too difficult to do, but will involve a lot of fields (for all of the I/O tags). Possibly, a graphical status screen with all of the I/O (like the rack addresses and such) and their value (ON = green, OFF = red). I developed some screens like this many projects ago to display real-time I/O values (with the ability to force I/O), so having that same screen display the I/O values at the time should not be the end of the world. This would be very helpful in identifying the conditions at the time of an event.

[Stupidav 1]

If it was me, on the Abort Alarm condition I would COPY the Bits you are after, to an unused data table in the plc then you can read them at any time with out the worry of them changing. To possibly cut down the number of fields being transfered, I would Read the whole word, or words at one time, rather than the individual bits, then break them down with your app rather than trying to read each individual bit. This will allow you to do 16 bits, or 32 bits (depending on your processor) at one time. The OPC / DDE Load on the processor will be much lower, but you app will have to work a little harder. Are you doing this with VB, and what Processor are you talking to?

[Mike Dyble 0]

Might also be worth saving accumulated time and count values of any relavent timers and counters, also any positional or analog value info.

[rdrast 3]

What platform and HMI ? I've been pretty impressed so for with FTSE 5.x, and the Factory Talk Alarms & Events system.

[Guest]

Greetings kaiser_will ... I’m not sure whether your plans include something like a “first out” recorder ... this usually has the idea of “trapping” the first one of a series of digital inputs to turn off ... if this is NOT what you’re trying to do, please stop reading now and just ignore the rest of this post ... continuing on ... many (most?) people don’t know it, but when two or more digital inputs electrically change state at the same time, the PLC does NOT always “update” the correct ONE/ZERO status of those inputs on exactly the same processor scan ... specifically, suppose that two digital inputs are wired to the SAME switch - and that the switch is presently ON ... both bits on the PLC’s input data table are each presently showing a status of ONE ... now suppose that the switch is turned OFF ... since both inputs are electrically tied together, it’s natural to assume that both of the bits will change to a ZERO status simultaneous ... issue: that SIMULTANEOUS thing doesn’t always happen ... specifically, one of the bits may still reflect a ONE status for one or two processor scans - while the other bit now reflects a ZERO status ... I hate to dredge this old thread up, but I covered these types of issues in this post ... http://www.plctalk.net/qanda/showthread.ph...mp;postcount=25 anyway ... if the “data recorder” that you’re working on can deal with a one-scan or two-scan discrepancy between the “actual” and the “recorded” status of the bits, then party on ... don’t worry about this type of stuff ... on the other hand, if you’re really trying to nail down EXACTLY what the status of several bits are at “alarm time” then you might want to consider the issues that I’m talking about ... hope this helps ...

[TConnolly 13]

Like my distinguished colleague Ron, I'm going to dredge up an old thread, but this one is about how to pack multiple bits into a single word and unpack them again in your HMI. http://www.plctalk.net/qanda/showpost.php?...amp;postcount=8