Modbus RTU Prosoft

Hey everyone, looking for some insight on the prosoft MVI56E-MCMR module. I wasn’t the one who installed this system, but I need help to troubleshoot.

PLC is control logix L73, with the prosoft card in the rack. It is modbus RTU communicating with 3 slaves. The communication has been intermittent at best. Contractors this week started to work on the 3rd node(power down), which seems to interrupt communication. It is also showing a module fault for the prosoft card in rslogix, but I can ping the Ethernet module it is tied to. On the prosoft card itself I am getting “p1 master comm errors”. I don’t really understand the role the AOI56MCMR plays in the ladder logic, other than grabbing data from the prosoft card. Is there supposed to be logic that if there is a communication error on x node, try for sometime otherwise skip to the next node?

I am very new to modbus and it’s protocol so bare with me. I’m probably not doing the greatest job explaining the situation so let me know if there’s anything else you need for info.

Welcome to the PLCTalk forum community !

The "MVI56E" means this is part of the relatively modern "Mulitvendor Communications Module" family for ControlLogix. The Enhanced (E) versions supported nifty features like downloading configurations via RSLinx routing.

The "MCMR" has a Reduced data block size compared to the classic "MCM". That allows it to be more easily placed in a chassis remote from the CPU, especially over a relatively low-bandwidth network like ControlNet. It sounds like your system has this module in a 1756 chassis that is connected to the CPU over an EtherNet/IP link.

P1 Master Comm errors make sense if you've got one of the three slave devices powered down. The errors are on the serial port (P1) of the module, not between the module and the backplane or the module and the CPU.


>Is there supposed to be logic that if there is a communication error on x node, try for sometime otherwise skip to the next node?

Yes, that should be part of the configuration of any Modbus Master device, including the Prosoft ones.

Do you have Prosoft Configuration Builder, and/or the configuration files from the system when it was put in ?

There's also an "E1" Ethernet port on the module that should let you look at its embedded Web page.

Thanks for the reply Ken. I am still new in this position, and not entirely sure if I can send files or not under policy. Hopefully I can explain a bit more for you.

Modbus P1 is master with an RTU protocol at 9600 baud rate. Command error pointer = 1500, Error Delay Counter = 0, Response Timer = 5000ms?, Retry count = 10.

I am polling 10 commands per node (3 nodes). The polling interval differs for each command ranging from 1-30.

I read in the documentation that the prosoft module default RPI set at 50, where mine was set at 5. I am wondering if there is a conflict of timing, where the master is trying to poll data from a node, the node wont respond because it is powered down, which wont initiate the process to poll for the next command.

I could be way out to lunch, as this is the first modbus system I have worked on. Thanks for the help.

Hi. The default RPI of 50 msec seems reasonable as the Modbus side is normally very slow. That said, the 5 msec being used on this system should not be a problem. Normally these modules work asynchronously so the RPI settings is unlikely to be the reason for these communication errors.
In my experience when using RS-485 based networks such as Mobdus RTU, bad media is the cause of most communication problems.
My advice is to check the cabling. Is this machine using proper RS-485 media with shielding? Profibus cable may be a good solution, as Profibus physical layer is RS-845. Is the network terminated? Is the network connected in daisy-chain? Or is it using a kind of "star" wiring (daisy-chain would be my advice)? 9600 baud should not give communication errors if wiring is correct.
As Ken said, checking the web server in the Prosoft module may give you some hints if it has a diagnosis section. You should look for CRC errors or something similar which would indicate bad media. Good luck.

Hi Alfredo, the communication works when disabling the node that is powered down and I have checked the wiring. The problem arises when the master is looking to see data from the powered down node. I dont believe there is any logic that tells the master to stop looking for data after "x" time polling to that node. I believe it gets stuck and cant recover. I will definitely look into the embedded web page for more information. Thanks for the help!

Hi, OM. You say the error arises if the node in question is enabled on the master side AND the device is powered down, correct?
What is the behaviour of the Rx/Tx LEDs on the Prosoft master for the Modbus channel in question when the device is powered down?
What happens if having this device enabled in the master's configuration you disconnect the serial cable on the slave side? Do you still see communication loss with the other two nodes?

I have no experience with that module, but you said it is using Modbus RTU. So I have some questions that might help enlighten the experts on this thread.

Is it RS485?
Is the cabling 2 wire or 4 wire?
Are all the slave nodes on one channel wired in series?
None of that may matter if the communication is still attempting to poll the missing node ten times and waiting 5 seconds for a timeout for each of those polls, that would definitely interfere with (slow down) the polling of the other nodes.

When I deal with multiple slaves on a RS485 network, I usually set the timeout to a much smaller value. If you don't get a response in 1 or 2 seconds on a hardwired network you probably won't get one and can move on. In other words, set the timeout to a lower value and investigate if there are other options to take the missing device out of the polling sequence or reduce its priority.

AlfredoQuintero said:

Hi, OM. You say the error arises if the node in question is enabled on the master side AND the device is powered down, correct?
What is the behaviour of the Rx/Tx LEDs on the Prosoft master for the Modbus channel in question when the device is powered down?
What happens if having this device enabled in the master's configuration you disconnect the serial cable on the slave side? Do you still see communication loss with the other two nodes?

Click to expand...

When a device powered down the Rx LED only blinks. When disconnecting the serial cable, we still didnt see communication.

OkiePC said:

I have no experience with that module, but you said it is using Modbus RTU. So I have some questions that might help enlighten the experts on this thread.

Is it RS485?
Is the cabling 2 wire or 4 wire?
Are all the slave nodes on one channel wired in series?
None of that may matter if the communication is still attempting to poll the missing node ten times and waiting 5 seconds for a timeout for each of those polls, that would definitely interfere with (slow down) the polling of the other nodes.

When I deal with multiple slaves on a RS485 network, I usually set the timeout to a much smaller value. If you don't get a response in 1 or 2 seconds on a hardwired network you probably won't get one and can move on. In other words, set the timeout to a lower value and investigate if there are other options to take the missing device out of the polling sequence or reduce its priority.

Click to expand...

Thanks for the reply! I believe we use a rs232 to rs485 converter to deal with the length of the cable? It is a 2 wire cable. I think we are on the right track with comms loss due to timeout. Would you suggest a timeout of 2s, as well as bringing down the retry count? Currently I have all three nodes communicating as they have fixed the equipment and everything is powered up.

ObnoxiousWatermelon said:

Thanks for the reply! I believe we use a rs232 to rs485 converter to deal with the length of the cable? It is a 2 wire cable. I think we are on the right track with comms loss due to timeout. Would you suggest a timeout of 2s, as well as bringing down the retry count? Currently I have all three nodes communicating as they have fixed the equipment and everything is powered up.

Click to expand...

I'd monitor what normal response times look like and set the timeout a little bit longer than the longest normal response time. Retries I usually set at 1 or 2, sometimes zero on radio networks.

Hi everyone!
I did some testing on the modbus system. When to 2 out of 3 nodes were powered down, I reduced the response timeout to 1500ms and the retry count to 1 which made the system work. The thing is it takes roughly 1 minute to receive a response from node 1. When I completely disabled node 2 and 3 from the prosoft config builder, the response from node 1 is lightning fast. Is there any way to increase the speed of response?
TIA