Event archive vs. alarm events in Rapid SCADA 6

Forum Home Forums Understanding the Software Event archive vs. alarm events in Rapid SCADA 6

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #18187
    Andi
    Participant

    Hello,

    first of all, thank you again for your previous support. We have successfully set up Rapid SCADA 6 with PostgreSQL and Grafana, and everything is working very well.

    We are now trying to use the Event archive as the data source for a Grafana State Timeline panel. This archive is ideal because it stores only state changes (instead of continuously storing unchanged digital values).

    However, we have encountered a conceptual problem.

    For a digital channel (for example, a door contact), we enabled:

    Event enabled
    Channel data has changed

    As expected, every state change is then stored in the PostgreSQL table eventscopy_event.

    Unfortunately, these operating state changes also appear in the standard Events window of Rapid SCADA.

    Our goal is to keep the Events window reserved for real warnings and alarms only, while still recording normal operating state changes (door contacts, operating modes, pump states, etc.) for historical visualization in Grafana.

    Our question is:

    Is there a built-in way in Rapid SCADA 6 to separate operational state changes from alarm events?

    For example:

    – event categories,
    – severity levels,
    – event classes,
    – event filters,
    – or any other recommended mechanism?

    Or is the intended solution to organize channels into different Views and use “Events by View” so that only the alarm view is displayed to the operator?

    We would like to understand the recommended architecture before implementing a workaround.

    Thank you very much for your advice.

    Best regards,

    Andre

    #18188
    manjey73
    Participant

    Use an Event Mask
    I can’t think of anything else.

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.