• Replies 2 replies
  • Subscribers 585 subscribers
  • Views 180 views
  • Users 0 members are here
Options
Related

Alarm Process

Nuno

Hi all,

I have a project with several DNPR I/ODevices.

During tests i notice that Citect retain alarm status on the following scenario:

1 - I switch down a circuit breaker on the electrical board,

2 - The signal appears in Citect, (animation symbol and alarm list the signal = TRUE)

3 - I force a power failure on the electric board, and Citect detects the communication break with this plc (The PLC has no power)

4 - I switch the same circuit breaker back up.

5 - I restore power back on, and wait until communication is establish between Citect and PLC.

6 - In the animation the signal is False and in the alarm the signal is TRUE (Tag=0 and AlarmTag.On=1)

Has anyone had this problem?

Best Regards

Parents

  • Hi Nuno

    It will depend on how this alarm is configured and the hardware (PLC) handles the interrupted power supply. In general, most of alarms in DNPR protocol are configured as "Timestamped Digital/Analog Alarms" that will be "pushed" via DRI (Driver Runtime Interface) directly into the alarm system, and these alarms are not scanned by the Citect alarm engine. In your scenario, it does not explain why Tag=0. Normally a PLC should have a battery to persist its data in case the power supply is lost. Tag=0 indicates that the PLC was in a clean start-up after the power was restored, and its event tables became empty. As a result, there was no Tag=0 event on the PLC (which will be sent to Citect unsolicited to clear the alarm). The alarm data integrity is broken between the PLC and the alarm system.

    If this alarm is configured as “Scanned” alarm, the alarm should be cleared when Tag=0. Please contact Technical Support and raise this issue.

    I am not an expert in the DNPR field but hope my analysis is helpful.

Reply

  • Hi Nuno

    It will depend on how this alarm is configured and the hardware (PLC) handles the interrupted power supply. In general, most of alarms in DNPR protocol are configured as "Timestamped Digital/Analog Alarms" that will be "pushed" via DRI (Driver Runtime Interface) directly into the alarm system, and these alarms are not scanned by the Citect alarm engine. In your scenario, it does not explain why Tag=0. Normally a PLC should have a battery to persist its data in case the power supply is lost. Tag=0 indicates that the PLC was in a clean start-up after the power was restored, and its event tables became empty. As a result, there was no Tag=0 event on the PLC (which will be sent to Citect unsolicited to clear the alarm). The alarm data integrity is broken between the PLC and the alarm system.

    If this alarm is configured as “Scanned” alarm, the alarm should be cleared when Tag=0. Please contact Technical Support and raise this issue.

    I am not an expert in the DNPR field but hope my analysis is helpful.

Children
  • in reply to Jacky Lang

    Another thing to consider, since this is DNPR, is to check the configured integrity poll for the driver and tags. It does seem strange that Tag=0 and Alarm state =1. Best to contact AVEVA Support and troubleshoot this further. Enabling detailed driver logging will uncover what is happening at the protocol level.

© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.