Modbus errors "Expected amount of bytes not received"

[rmayer]

Hi Gents, Question for ya...

We have a new design, PLC driven machine that loads its recipe at the beginning of each shift via Modbus write of 95 register values. On top of that periodic routine we wrote a vba-over-MSAccess app for simple DAQ, analysis, and troubleshooting via modbus as well.

The app grabs 800 registers and logs them with operator setting frequency (as fast as 1 sample per 500ms). Everything has been working flawlessly for about 3 months <<Segway to current problem...

The program grabs 100 registers per each 1 modbus read command and does this multiple times to gather the desired data. Recently this stopped working and through a lot of troubleshooting, we figured out that the error is only set when the modbus read command exceeds 80 registers.

So, is there some type of safe modbus usage rule of thumb that I am aware of that says 'thou shalt not as for more than 80 at a time lest he be riddled with errors"???

Next ??
Is it abnormally hard or more stressful on and PLC components to be polling it this way (100 regs per read, 8 reads in rapid succession)?

I'm using modbus TCP/IP over ethernet but also had the same issue using RTU over RS422.

Thanks in advance for puttin up with my newbie questions.

 

[djs]

The amount of data that can be returned via one call is device dependent. The only limit per Modbus spec is the limitation of the byte count register, limiting the return data to 256 bytes or words.

 

[danw2]

Device dependent indeed. I was astonished to actually read in one device's documentation last week that it would return a maximum of 26 registers at a time to 16 decimal query.

Frankly it was delightful to discover the limitation beforehand and to develop the read routine around it, rather than pound away wondering why a 30 register read doesn't work in the first place.

But more to the point here, since the transistors that make up the IC's that do this kind of work don't stress out over something like the number of bytes, I conclude that something has changed. It worked before, now it doesn't.

From your description, it sounds like it might be a consistent error, that now you can't get any 100 register reads, only 80 max register reads. Is that the case?

There's lots of pieces to this puzzle.

Which piece of puzzle got a firmware update?

Which piece of the puzzle got a software update?

What modifications were done to the sofware?

Is the current version the one you think it is? Did someone load a "former version" by mistake?

 

[rmayer]

Yes danw2. 100-reg-reads worked fine for about 3 months. Yesterday I stepped the register count up one by one and found that 80 is the exact cutoff. 81 is a no-go but 80 comes back fine consitently. I was hoping to have written the DAQ module in a way that it would be compatible with any future component replacements or switch-overs. However, reading your reply, it seems that I need to be a bit more conservative.

Going from 100-reg-reads to 50-reg-reads would double the volume of TCP/IP Packets and therefore slow down the DAQ a bit.

Thanks for the info

 

[dV8r]

If the slave device is a high end processor, you may be able to open more than one channel or port to the slave device and force it to 'multitask'.