MVI56-MCM Prosoft Modbus SLooooww?

Hi Guys,

I have over a thousand registers setup in staggered polls from a device. Baud rate is at 19200. For some reason the slave wouldn't respond when I went higher. Anyway, for example my poll is set at 2 seconds but my values are updating after 15-20 seconds. Which is ridiculous. Is it something to do with the backplane data exchange? It's driving me nuts!

How many values are you polling each time?

I am polling about 40 holding registers at a time. Do you think the slave device is choking?

That is a lot of data for serial communication. You are most probably overwhelming the slave.

When you are polling, are you checking to make sure the transmission has finished before polling again?

What kind of performance were you expecting on this? The slave should have some specs on what it is capable of doing.

The slave is a ROC Floboss 107. Its a small RTU. It is quite a bit of data I guess. The Floboss manual doesn't specify any limitations or anything. I was hoping 10 second update intervals atleast. No I have not configured the prosoft module to wait before commencing the next poll.

It's almost certainly not a backplane data exchange issue; the MVI56-MCM can run through five backplane blocks of 200 registers in a hundred milliseconds, easily.

At 19200 bits per second, with 8/N/1 framing, you have 1920 bytes per second. Modbus at its very fastest needs 3.5 bytes worth of time between poll and response.

For the sake of argument, say you're reading 100 registers at a time with a Modbus function code 0x03.

The Modbus Poll will be 8 bytes and the reply will be 205 bytes. 216.5 bytes at 1920 bytes per second; that's just 113 milliseconds. Five of those will take only 1.1 seconds, so that's the absolute minimum time that any two Modbus devices could possibly, theoretically, communicate this data.

Fortunately the Command structure for the MVI56 is fairly straightforward; can you post a summary of how many Commands you have configured ?

I'm also curious about what variation of the MVI56-MCM you are using; the classic, the reduced-data-block, or the newer MVI56E-MCM ?

The classic MVI56's monitor mode will also give us some really good information on the actual performance of the data on the wire. Modbus can easily be decoded by hand.

I'm less familiar with how to monitor traffic on the MVI56E enhanced modules.

Is this an RS-232 or RS-485 or other media connection ?

Hi Ken,

I am actually using function code 4. Modbus poll commands are in the following structure:

Command1: Words 40, 2sec
Command2: Words 28, 2sec
Command3: Words 30, 2sec

The next few sequences are the same quantity except, the poll time is 3sec, and then 1sec.

I am using RS-485 which is going through a RS-485/RS-232 converter. Due to the distance I have to go RS-485.

It's a regular MVI56-MCM card.

I'm actually more comfortable with the analysis of the classic MVI56-MCM.... make sure you have another Prosoft serial cable handy and use a terminal program like TeraTerm or (my favorite) RealTerm to capture the data from the Data Analyzer mode on the Config/Monitor channel.

The way I understand the Poll Interval value, it is the time between repeats of individual Commands. This is typically represented in Seconds and can be a different value per Command.

The Minimum Command Delay value is the time between subsequent Commands. This is represented in Milliseconds and is a per-Port value.

With the Poll Intervals set for 1, 2, or 3 seconds, multiple Commands would be triggered, one immediately after another, in groups, on 1 second intervals. It would be like a lunch rush at the deli; there would be plenty of time to make sandwiches for everybody if they didn't all show up and order at noon.

What I would do is increase the Poll Interval (for every Command) to 5 seconds, and set the Minimum Command Delay for the Port to 100 milliseconds.

But before that, disable all but one of the polls, and run the Data Analyzer mode, so you can check how long it takes the device to reply to a single poll. Those "tick marks" that it will output for time intervals are not as neat as accurate timestamps, but they work.