Collecting events off many different triggers

Hello:

Currently I am working on a request to collect event data from a mixing system here on site.
I have an overall mixing cycle and ~60 some odd separate possible events in that cycle. The request is to collect each event, the time triggered, and the time that event stopped.
I was thinking of using a combination of OPC items and action items and creating a separate group for each ‘event’. The group would trigger on value change and the action item would use some Boolean logic to either write “blah blah event fired” or “blah blah event ended”

This seems cumbersome really, wondered if anyone had a better idea?

  • Mike

Do the events overlap? What about the following setup with 2 FSQL groups:

  1. Have an event_id register and trigger. Trigger value of 1 indicates start, 2 indicates stop. event_id (int) is set prior to setting the trigger value. It indicates the 60 events.
  2. Start” FSQL group triggers “on value =1” then resets trigger to 0
    2a. Start group logs a record (t_stamp=start time, event_id signals event, end_time is initially NULL)
  3. Stop” FSQL group triggers “on value=2” then resets trigger to 0.
    3a. Stop group uses action items. recent_event is an Action Item that performs an SQL query to tell you the id of the most recent record with the currently selected event_id in the PLC.
    3b. A second action item that runs when Stop triggers performs an UPDATE query that updates the end_time column where id={recent_event} (from above).

The PLC needs to use some sort of stack/queue to ensure that the trigger goes back to 0 (FSQL acknowledging start/stop) before it notifies the next event. The operation should occur quickly.

You can then set up a (possibly user editable) lookup table in the database to go from code->description. You could even add a 3c step that writes this value to another text column in your table. This could even be a full string like “event occurred at date/time and cleared at date/time”, although that could easily be generated with a query later.

Hmm, cool idea.

The events can/do overlap at times though.

Something for me to explore though, thanks for the advice.

Overlap actually shouldn’t be a big deal with that setup. Having the PLC track events if near-simultaneous events are common (compared to the group update rate) is. There is one big assumption though, that a given event will “end” before another event of that same code begins. Things would get trickier if you can’t make that assumption.