I have Freezing problem at Telvent HU-AF.

Can you clarify what happens exactly? Does Citect RunTime freeze and then the communication stops, or is it the other way around: Communication stops and then Citect freezes?

Also, do you run Citect in single process mode (Client, I/O Server, Alarm Server, Report Server and Trend Server as a single Citect32.exe instance)? Or do you run your project in multi-process mode?

If something (for example a SQL-query or file operation) blocks Citect in single process mode, then the communication will stop as well and the client animation will freeze also.
Multi-process mode is recommended if your project configuration allows it. It might require some engineering though.

Of course, I give you detail. I have 30 pieces rtu in area. These rtu connected with fiber line. Power Scada is in Control room and including to fiber line. I am running multi process mode. I have 2 pieces Server and 2 pieces client. Freezing is not in Power Scada. RTU is freezing. RTU cannot answer two queries from the same port at the same time and closes the tcp port (does not allow access to the device). That's why I've defined two ports in RTU. There are now two different ports in RTU. Scada server 1 and Scada server 2 are querying the device. RTUs on the field are still freezing. There is no period. Sometimes it works without freezing for 3 days and sometimes it works without freezing for 20 days. But in the end it freezes. Working times can vary. I still have a problem.

Hi Murat,

Can you confirm what version of MODNET (Modbus tcp/ip) driver you are using?

If you want to guarantee that only one IO Device is communicating with RTU at one time, you can enable "Exclusive" mode on the IO Device (via the IO Device configuration). See extract from help:

This setting controls the way in which redundant I/O device(s) configured with the same network number on different I/O servers activate communications to the physical device they represent.

When Exclusive is set to TRUE, only one I/O device (on one I/O server) will activate communications to the physical device at a time. The best available I/O device (online with the lowest priority) at a particular time will be chosen to actively communicate. When this I/O device is no longer the best available, it will deactivate, which will in turn trigger the best available I/O device on another server to activate.

When Exclusive is set to FALSE (default), the best available I/O device will typically be the only active I/O device; however this may not be enforced. When a different I/O device becomes the best it will activate immediately, without waiting for the other I/O device to deactivate. An I/O device that is not the best may also be forced into actively communicating with the physical device if a particular client can only communicate with the I/O server that I/O device is running on.

Note: The parameter [IOServer]PeerServerConnectTimeOut has been implemented so that on startup of an I/O server, all I/O devices with Exclusive set to TRUE will not be allowed to activate before the I/O server has successfully connected to its peers. This parameter defines how long an I/O server will wait until it ceases trying to connect to peer I/O servers.

Hi Olivier,
First of all thank you for help me.
-Modnet driver is MODNET_2.09.10.000_RELEASE.
-I will try Exclusive Mode.

You may also need to set [IOServer]watchdog to 0 if you haven't already. By default the standby server checks communication every 30 seconds. This will turn it off. Not sure if it is needed with exclusive mode turned on though.

Hi Stuart, Murat mentioned that it is the RTU that is freezing, not Citect. So I don't think it is necessary to set watchdog parameters. I would recommend Murat get in contact with Telvent to understand the issue from RTU side. Maybe there is a firmware update available which will fix the issue? If two masters communicating at the same time is the problem, then Exclusive mode will prevent that from happening.

Hi Olivier,

I think Stuart's comment is valid, or at least it was before the introduction of Exclusive Mode. Not setting [IOServer]Watchdog=0 leads to concurrent communication of 2 masters to the same RTU. We experienced the same issue with IEC61850 RTU units from a certain company.

Like Stuart, I'm also curious if turning on Exclusive Mode prevents this periodic watchdog communication from happening when the parameter is not set to 0.

Hi Patrick,
I shared wireshark record of Server 1 and Server 2.
Server 1 ip: 192.202.1.10
Server 2 ip:192.202.1.11
Rtu ip: 192.202.1.41

I don't understand errors in the red line. Is it important? if there is an error limit in rtu. Could the RTU have stopped because errors in the red line have filled the quota?