Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: sclrick on March 13, 2019, 11:07:39 PM
-
I am having an issue with the BRX using Modbus TCP communications. Using it as a master, when communication is lost to a server, the comms will not restore unless power is cycled. I am testing this communication with a drive system. Everything is working fine. I unplug the Ethernet cable as a test for the drive system behavior in a communication failure and the BRX will not restore when the cable is reconnected. Changing to program and back to run will not restore communication. If I cycle power, the communications will resume with no errors.
Error messages
Operation timed out in MWX @0000006C (MWX at $Main@15)
Operation timed out in MRX @0000005E (MRX at $Main@1)
-
Not sure what the problem could be. What do you have for a timeout in the configeration "@IntModTCPClient". How are you running the comms? Continues on power flow at interval or using trigger on oneshot. Maybe when you have a comm error the the comms are not re-triggered. I have setup a similar system and comms do restart after the problem is fixed.
-
Is ST143 coming on?
-
For the record, this is very similar to an issue I posted a month or so back. I swapped out the BRX and the problem ceased. It also stopped my analog output from working (though it showed it was changing in the PLC).
-
Thanks for the suggestions. I thought I had the problem resolved by triggering the read and write instead of continuous. After several tries the comms restarted. Now it stopped again after interrupting the connection. ST143 is set. @IntModTCPClient is set at 1000, 2, 60. I have used a Do-more / 205 as well as a DL260 communicating with the same brand drive system before but using an Ecom100. Never had an issue.
-
If an MRX/MWX box is enabled to run on interval and the containing code block is being executed every scan, it should just work, and I know of no cases where it doesn't recover and continue following a comm error.
1. Verify that the code block (program, task, or stage) the instructions are in is running when comm stops. A good sanity check is to add a rung with a rising edge $1Second contact driving an INC. Simple heartbeat.
2. Check to see if ST145 or ST146 is set.
3. When you power cycled the PLC, did that also power cycle the Ethernet switch? Switches get dumb and occasionally go bad.
-
What I do is have my MWX and MRX in their own program with stage logic. Then have another code block monitor for a comm error in that code block. If a fault occurs, it jumps to an exit for that program. The monitoring code block detects the fault and resets ST143 (Driver Error) and waits a few seconds before restarting the code block. Sometimes other devices need time before you start talking to them again. This works for me, your devices may behave differently or it may not be possible in your application. Never had the PLC lock up or the fault persist after implementing this method. The client driver works very well.