@woodsb02, you were right. We have identified that on the PLC comms device settings, there are allowed 16 concurrent connections on one comms device for MODBUS-TCP option. But these needs to be 'Enabled' on the PLC comms device level depending on how many connections are needed (out of 16), and each connection assigned to the respective modbus-tcp slave IP address.
This will allow concurrent device connection on Ignition scada.
1 Like
This might be of interest:
This is fantastic - thanks - Iāll definitely give it a try. This will definitely be an advantage for us to use your advanced modbus driver.
Iāve also submitted this as an āideaā to add support for redundant slaves to the Modbus TCP driver that comes out of the box in Ignition. If others would like to see this supported added to Ignition, it would help if you up-voted the idea at the link below.
https://inductiveautomation.canny.io/ignition-features-and-ideas/p/modbus-tcp-driver-redundancy
Heh. You know I'm not gonna up-vote it... 
2 Likes
Quick update - correct me if Iām wrong, but the system.device.setDeviceHostname solution doesnāt work if youāre running on the redundant gateway, because Ignition only allows you to make configuration changes on the master gateway.
Does that sound correct?
The scenario here is redundant ignition servers with a redundant Modbus connection. If the master ignition server is down (so the backup server is active), and then the primary modbus connection fails (so the backup ignition server has to failover the device connection to the secondary modbus hostname/IP address).
That sounds right.
Thanks.
Am I correct that when the backup ignition server is active, whilst you cannot write to device configuration - you CAN write to UDT parametersā¦ and therefore the alternative solution of using UDT inheritance to dynamically modify the OpcItemPath should work on the backup server?
That also sounds right, but I'm not sure, so it's probably best to try it and see.
@Kevin.Herron do you think there is a chance the feature to use the system.device.setDeviceHostname function on the backup server could be implemented? (Would it help if I submitted it to the ideas page?)
USE CASE 1 (higher priority) - After a gateway failover, when the backup server is active - to allow redundant PLC comms from the backup server to continue to work.
USE CASE 2 (lower priority) - when the backup server is standby with a āwarmā configuration - when comms to PLC-A address is good from the primary server but bad from the backup server (so only the backup server could fail over to PLC-B address for warm).
No, configuration of the backup gateway is fundamentally not allowed to be modified.
8.3 is introducing a new concept where essentially anything with configuration can optionally have a backup-specific version of that configuration that is used when the running gateway is in the backup role.
1 Like
That sounds like a nice feature for 8.3.
However, it doesnāt help in this case, because we want the hostname configuration to be able to be dynamically changed on the (active) backup based on health communication status to the PLC.
Anyone with redundant servers connecting to redundant PLCs is likely to want this.
Is it possible to make this one gateway configuration editable on the backup server (an exception to the rule)?
No, sorry, not going to happen.
What you really want is first class support for network redundancy in the drivers, like what Kepware calls media-level redundancy (I think). Something like that isn't going to get implemented in an 8.1 point release and neither is some hack to make setDeviceHostname somehow work on the backup gateway.
Ok, thanks for letting me know.