This batch controller is having two separate channel for connecting modbus master. Both Channels are independently configurable. we have configured slave address 102 on both the ports. in modscan we are getting data from both ports. (we were polling one by one on the individual port). Batch controller is communicating on RS485. we have used RS485 to RS232 converter of Moxa Make(TCC-80I). we have used two converters and connected both channel of batch controller to two different ports of two different CI853 at individual Position.
Total number of read register are approximately 630 and total number of write registers are 75. We are not doing this read write in one single go. We are reading them sequentially in 3-4 seconds. in one port 3 such BCUs are connected.
When we are using MBConnect block we are able to communicate.
When we are using MBConnectR block with only one MB Read and one MB write block, are able to communicate and switchover is happening. But actually when we need doing complete cycle of read and write the communication is toggling between two channels for a while and then resulting in -7014 error code, means high load on CI module and stopping.
the logic made for handling this batch controller is having (2070 variables as parameter + variable).
am attaching the settings done under our controller and other screen shot. Also controller log of where this communication is happening.
Under Serial Slave we have made Poll Time as 0msec, but if we keep this value other than 0(1 to 4000) we are not getting valid pin true on MBConnectR or MBConnect. We are using serial cable similar to TK212A Cable.
Please advise how to achieve application based communication redundancy.
Poll time (Master)
The poll time is the amount of time between diagnostic requests, when the communication line is idle and a connection to a slave is established.
If the value is set to 0 the function is disabled.
Default value: 4000 ms.
I guess this is because the device you connect does not support function code 8 (Diagnosis) of modbus protocol. And in this case MBConnect.valid cannot be used to claim the channel is good or not.
To make redundancy in application level, we have done long ago in a project that reading both connections data and using NDR of MBRead as a heart beat signal and make a flag signal to indicate if the channel is allright. And use the flag to detemine from which port's variable should I read the signal and move the variable to final variable which will be used.
if MBRead1.Ndr is flashing
Channel 1 is good
Channel 1 is bad
if MBRead2.Ndr is flashing
Channel 2 is good
Channel 2 is bad
if Channel2 is bad
variable = variable1 read from channel 1
if Channel1 is bad and channel 2 is good
variable = variable2 read from channel 2
I know this looks ugly. However, at that time there is no MBConnectR. There is no instructions for MBConnectR in online help at least in 6.0 version although the communication mannual says seek in online help for more information.