Support Forums
Radios on serial ports and serial servers

I'll be bringing up a replacement server for one that got a hit by lightening and I need to know the trick for getting VTscada to only poll the serial modbus connections from the active server in a redundant server config.

I'll be bringing up a replacement server for one that got a hit by lightening and I need to know the trick for getting VTscada to only poll the serial modbus connections from the active server in a redundant server config.

Century Control Systems, Inc. www.centurycontrolsystems-inc.com

Make a service/server list for each of the serial modbus devices and only put the server physically connected to them.

Leave both servers in the default server list, which will be everything else (services) not explicitly defined.

Make a service/server list for each of the serial modbus devices and only put the server physically connected to them. Leave both servers in the default server list, which will be everything else (services) not explicitly defined.

Tried that with The Polling Driver Specified to Server1 first than Server2.

Absolutely no difference both the one physically hooked to com1 on Server1 and the one on the Serial Port Server that reads from both servers loses anything approaching decent polling.

Tried that with The Polling Driver Specified to Server1 first than Server2. Absolutely no difference both the one physically hooked to com1 on Server1 and the one on the Serial Port Server that reads from both servers loses anything approaching decent polling.

Century Control Systems, Inc. www.centurycontrolsystems-inc.com

I would build my tag structure as -

Serial port

- Modbus1 -- 

     -Poll Driver 1 - I set the poll sequence number to be the same as the 
                           modbus PLC address. This ensures they are not duplicated 
                           and sequential.

         - Various tags

Assuming a basic two server network with a primary and backup, just use the default server list. In Application Configuration, Edit Properties, Advanced mode, copy NoSoftDriverFailure Into the app and set the value to 1.

All polling will be done by the primary. Setting NoSoftDriverFailure ensures that if a device can't be reached, the polling for that device stays with the primary and does not fail to the backup. This ensures that the polling for all devices stays with the same server. If the primary goes off line, polling for all devices will fail over to the backup. The backup will not poll until it cannot reach the primary. In a small network, this should only be when the primary is offline.

This does mean that the serial ports on both servers have to be connected to the radio somehow. In house, we use serial-Ethernet converters and handle everything out of VTScada as an Ethernet connection. If you set the modbus device up as serial RTU (or Open Modbus TCP) and use a TCP port tag, the serial packet gets embedded in the TCP packet and unwrapped by the converter at the device so just the serial packet gets transmitted by the radio.

Be careful with poll rates. If you have 100 devices in the field and it takes five minutes to poll from device 1, go through all the devices and get back to device 1, then setting a poll rate of 60 seconds just means that polling will never stop. It can't go any faster than five minutes regardless. If you set the poll rate for six minutes, then you should have one minute of dead air at the end of every poll.

Polling the sequence can take longer than the average depending retries, stations being fast polled, etc.

Also be careful using data sources on control tags. Writing to a device puts that device into fast poll. This keeps an operator from having to potentially wait a full polling cycle to get a response. It does mean that if you have a data source that is changing constantly, or two PLC's that are writing back and forth to each other, you can tie up the polling. If you need to use a data source, make those control tags go to the modbus driver itself, not the poll driver. No one will be waiting to see the change anyway so it shouldn't matter.

One last thing. VTScada only writes on change and only writes once. If the user is changing set points and the connection to the device fails for some reason, the write will not complete and will not be re-written. There are ways to use get around this if necessary (using multiwrite and trigger tags), especially when data sources are used.

I would build my tag structure as - Serial port - Modbus1 -- -Poll Driver 1 - I set the poll sequence number to be the same as the modbus PLC address. This ensures they are not duplicated and sequential. - Various tags Assuming a basic two server network with a primary and backup, just use the default server list. In Application Configuration, Edit Properties, Advanced mode, copy NoSoftDriverFailure Into the app and set the value to 1. All polling will be done by the primary. Setting NoSoftDriverFailure ensures that if a device can't be reached, the polling for that device stays with the primary and does not fail to the backup. This ensures that the polling for all devices stays with the same server. If the primary goes off line, polling for all devices will fail over to the backup. The backup will not poll until it cannot reach the primary. In a small network, this should only be when the primary is offline. This does mean that the serial ports on both servers have to be connected to the radio somehow. In house, we use serial-Ethernet converters and handle everything out of VTScada as an Ethernet connection. If you set the modbus device up as serial RTU (or Open Modbus TCP) and use a TCP port tag, the serial packet gets embedded in the TCP packet and unwrapped by the converter at the device so just the serial packet gets transmitted by the radio. Be careful with poll rates. If you have 100 devices in the field and it takes five minutes to poll from device 1, go through all the devices and get back to device 1, then setting a poll rate of 60 seconds just means that polling will never stop. It can't go any faster than five minutes regardless. If you set the poll rate for six minutes, then you should have one minute of dead air at the end of every poll. Polling the sequence can take longer than the average depending retries, stations being fast polled, etc. Also be careful using data sources on control tags. Writing to a device puts that device into fast poll. This keeps an operator from having to potentially wait a full polling cycle to get a response. It does mean that if you have a data source that is changing constantly, or two PLC's that are writing back and forth to each other, you can tie up the polling. If you need to use a data source, make those control tags go to the modbus driver itself, not the poll driver. No one will be waiting to see the change anyway so it shouldn't matter. One last thing. VTScada only writes on change and only writes once. If the user is changing set points and the connection to the device fails for some reason, the write will not complete and will not be re-written. There are ways to use get around this if necessary (using multiwrite and trigger tags), especially when data sources are used.

Doug Spurrell

edited Jul 11 at 12:49 pm
69
5
3
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft