Applies To:
  • CitectSCADA
  • CitectHMI
Summary:
When using a high speed (H) model Q PLC with a large complex program leading to a high PLC Scan time (>130ms) and Citect MelsecQnA Driver 1.00.03.002, Citect will display "phantom alarms" in the alarm page even though the bits driving the alarms are OFF in the Mitsubishi Q0 PLC.

If I look at the Syslog.dat file I see General errors;

Mon Oct 14 18:01:17 2002 294:07:17.663 Error: General error
READ 0008 PORT1_BOARD1 IODev1 D*0 1
Generic 000008 Driver 00114782 (0x0001c05e)

What could be wrong?

 

Solution:
This is a special problem that is only reproducible under a number of different prerequisites:

The "combination" problem:

High PLC CPU Scan time.

H-series CPU´s. (Q02H...Q12H)

Standard MelsecQnA driver settings in Citect.ini.

If one of the above cases are not met, you will not get this problem

 

Or,

 

The "single" problem:

High PC CPU Load.

For hardware related reasons, the Ethernet communication module (QJ71E71-100) temporally loses communication to the Q0 CPU. This leads to an internal Mitsubishi error:

CPU.Monitoring.Timeout hexcode=c05e. (See Syslog above)

At exactly the same time, Citect will get the hardware-error, General error in the syslog.dat.

Immediately after the connection is restored, the PLC Ethernet module will reply with a frame containing multiple replies. If you have set your Citect.ini file to standard MelsecQna parameter you will get "phantom alarms" in the alarm page even though the bits driving the alarms were OFF in the PLC. In other words: The Citect MelsecQnA driver overreacts to the hardware-related Mitsubishi error. The temporary workaround is to tune the driver parameters in the Citect.ini files to be tuned to the performance of the PLC network.

Increase the Driver parameter TimeOut= to match the worst response time. This is usually around 3000ms. If the problem persists, try to increase the parameter to 10000ms. And decrease the Maxpending parameter to 1. If you still have problems you can adjust the scheduling timer of the Citect request manager. The scheduling timer is controlled by the parameter [Req]Delay (default 50ms). Set the [Req]Delay parameter to 10ms.

[MelsecQnA]
MaxPending=1
TimeOut=10000 or more

[Req]
Delay=10

If you are experiencing "phantom alarms" and have temporally a high PC CPU load (ex. Printing) you should increase the TimeOut Parameter to 10000 or more to rectify to problem.

Notes:

The above communication errors are not necessarily Citect caused, unit not responding indicates that the PLC has gone silent, possibly due to overload with communications requests.

Driver parameters show up in run time in the Citect Kernel window, view drivers. You can adjust the above parameters using the Citect Help Topics | Find | type in the protocol name, then in the topics you will see "protocol parameters".

 
Keywords:
 

Attachments