DoMore and MB-GATEWAY problem

[Gummi Ben]

Hello, I'm using MB-Gateway connected to DoMore CPU to communicate with ABB Drive. For testing I have set up two drives, connected on RS-485 to the MB-Gateway and I'm using MRX and MWX functions in DoMore to read and write to and from the drives. All works well until one of the drive drops from the bus (powerfailure or something that would cause the drive to stop communicating). Then I get an error on the MB-Gateway and also lose communication to the other drive. What is there to be done ?

Best regards

Guðmundur

[Greg]

This sounds more like an issue on the RS-485 network itself rather than the MB-GATEWAY.
1. How long is the cabling between each of the 3 devices?
2. Is the cabling shielded?
3. Do you have termination resistors installed at the end devices?
4. What baudrate are you running?
5. Is the environment electrically noisy (e.g. drives, high-voltage)

[Gummi Ben]

Thanks for the response Greg.  Since this is still on experimental base and I wanted to test it before final installation the distance from the MB-GATEWAY to first drive is about one meter long and then maby 0.5m between the drives.  I have turned on termination on the second drive and installed a 120ohm resistor on the MB-GATEWAY end.  The cable is not shielded and the baudrate is  9.6k.  This in in my office with no electrical noise.

I tried the following: 
1. Reduced the timeout to 300ms. 
2. Set the retries to 0

Then I was able to still communicate with one drive after cutting the power from the other one. I wonder how it will be when I have all 14 drives on the RS-485 bus ?

[Garyhlucas]

I am interested in how to do this as well because shortly I will have 8 drives on line. Currently have 6 and if drive were to blow its fuses I am guessing we'd lose commuication with the others. Really need this to be more bulletproof.

[plcnut]

Here is a code block that I use to control 8 drives. It will work even when some of them are offline. I believe I had to tweek some of the timeout settings in the drives, but cannot remember for sure... To use, just copy all the text in the file below, and then right-click the Program folder in a new project and click Paste-code-block.

[Greg]

Gummi Ben, on the MB-GATEWAY, did you change the "Inter-packet Tx Delay" at all? What is its setting?

[Gummi Ben]

Hello Greg, no I did not since I did not understand the functionality of that one.  Thanks plcnut for the code, nicely written.

[Greg]

The Modbus RTU spec recommends a 3.5 character interpacket delay time between frames. In other words, a Modbus message is framed. It is a continuous stream of characters made up of address, function code, data & CRC. But the receiver must know when the frame begins. To know this, there needs to be at least 3.5 characters of delay time (silence) between frames.

So to calculate the minimum value it should be you must know the serial port transmission settings. So, for example, what is the length of one character?

Start bit: 1
Data bits: 8
Parity bit: None
Stop bits: 1
TOTAL: 10 bits per character

Time for one character: 10 / 9600 bits per second = 1.042 ms
3.5 characters: 3.5 x 1.042 ms = 3.646 ms

It can be longer than that, but it should at least be that. So in the settings make sure it is at least 4 or greater.

[franji1]

The key is that you MINIMALLY need 3.5 character delay.  On your 485 Modbus/RTU network, if just ONE device is "slow" and cannot turn around that quickly, then you have to delay it even more for the entire network.

Also. you do NOT want to be on the "hairy edge", because you really need 99.99% of packets to work when everything is "up and running", especially with 0 retries.

[Greg]

Yes, I have encountered certain drives that when communicating with them their receivers needed at least 8 ms of interpacket delay. It was slightly smaller at faster bauds, but not much. So a setting of 10 ms was used and all was well even though a setting of 10 ms was way over 3.5 characters.

[Greg]

...1. Reduced the timeout to 300ms. 
2. Set the retries to 0

Then I was able to still communicate with one drive after cutting the power from the other one. I wonder how it will be when I have all 14 drives on the RS-485 bus ?

14 drives should not be a problem. But I will caution you on a common mistake. When you utilize the on-board Ethernet port on the Do-more as a Modbus TCP Client (Master), it also has some timing parameters. For instance, by default, if you go to the System Configuration --> Device Configuration and double-click on @IntModTCPClient device you will see that the Timeout is set to 1000 ms (i.e. 1 second) and the Retries are 2. This means if he sends a TCP telegram to the MB-GATEWAY and then doesn't get a response back in 1 second, he will send another TCP request.

On the other end of the MB-GATEWAY, it also has timing parameters. By default it is also set to 1000 ms and 2 Retries for ALL SLAVES. This would not work well together with the @IntModTCPClient timing if, say, one of your slaves disappears off the RS-485 network. Think about it. It would take 3 seconds for the RTU side to fail. But in the meantime the TCP side has received multiple requests every second.

If you are polling at a 1 second rate in ladder logic, this can get even worse.

So, the bottom-line, you have to manage your polling in ladder when there is a timeout. And you should set the timeouts and retries on not only the slaves, but also the @IntModTCPClient to where they make sense. For instance I might have the Do-more timeout set to 4000 ms. That way, it won't retry until after my slave has retried 3 times on the RTU side.

Make sense? So managing this is why folks usually find it difficult to do their own I/O over Modbus TCP, especially if you are going to a Modbus RTU network through an MB-GATEWAY.

Hope this helps.

[BobO]

Yes, I have encountered certain drives that when communicating with them their receivers needed at least 8 ms of interpacket delay. It was slightly smaller at faster bauds, but not much. So a setting of 10 ms was used and all was well even though a setting of 10 ms was way over 3.5 characters.

Framing is a key detail that gets lost. The spec calls for 3.5 character times, but unless you have a hardware implementation that allows you to precisely time the silence, it is very difficult to know whether the requirement was met...at 115200, 3.5 character times is just 300us. When the required hardware isn't available, implementations have to evaluate silence as part of the normal device scan, so the silence has to be something longer than one scan and probably more like two. So regardless of the spec, the reality is that 2x the scantime of your slowest device may be what is required.

[Controls Guy]

I once tried to set up a DL-260 with H2-ECOM to talk to multiple ACS-550's via a Prosoft bridge.  The bridge has four RS-485 ports and if memory serves, you set it up to poll the RTU slaves and fill in a memory map inside the device, which then looks like a single Modbus/TCP server to your client.  You can poll all the slave data on one shot (or how many ever max-sized transactions you need).

Anyway, I found that the internal RS-485 transceiver in the 550's started responding in like 5ms or something after conclusion of the poll, and the Prosoft hadn't ceded control of the bus yet.  Since both transmitters were trying to set the bus voltage, it sort of came out averaged between the two, and the initial bit or two had distorted enough voltage that the Prosoft saw the response as misframed and wouldn't process the data.  AND, the 550 Modbus slave config has no adjustment for response delay.  Seemed like a good idea at the time.

I have successfully use the Digi One IAP, so it must yield the bus faster than the Prosoft, or else ABB changed their driver.

[Gummi Ben]

Wow, thanks guys for all the information.  I am so much wiser on the subject now.  

Just one more question regarding the DoMore CPU.  Do I need to have a mechanism in the ladder such as stages or can I just pile up ST1-lines with MRX and MWX operation, operation at a certain time interval and trust that the DoMore will handle the execution in the right fashion ?

I will test the communication in late August and report back, hopefully with a success story


All the best from Iceland

Regards, Gummi Ben

[Greg]

You can set the poll rate in the MRX/MWX instructions themselves, or, you can turn them all ON (as you said using ST1 ($On)) and the internal "token passing" will happen such that they will all get executed one right after another as fast as possible. In your case, that may NOT be a good idea since you are having timing issues already.

Instead, I would certainly use Stages, myself, because I would want to not only control the poll rate of each slave when they are all working perfectly, but also be able to manage when one or more slaves drop offline. The ones that drop offline, I would probably reduce the poll rate to them drastically until they come back online. In this manner the working slaves won't suffer (drop in poll rate), when some of the other slaves disappear from the network.

But these ideas are much easier said than implemented.    But such is the responsibility/beauty of writing a master control on your own.