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.
