Modbus RTU, interference and 230V VFD

[rQx]

Hi,

I have 5 Parker IP66 VFDs, 3pcs 400V and 2pcs 230V.
Two of them are located on a filtrating machine and three of them are located on a buffer tank before the filtrate machine along with the control panel.

They are running on modbus RTU and a S7-1200. They are running through 18 modbus blocks reading and writing, with no error. I can start any of the 400V VFDs without getting errors. But when I start any of the two 230V VFDs I get errors on the modbus blocks "80C8 slave timeout". The operation is still fine, it is communicating with the VFDs and the VFDs continue to run but it returns error from the block. And not just its own blocks, it also effect all the other modbus blocks aswell. So the 400V VFDs also returns the same error.

I'm thinking that this is something in the layout or hardware since it only start to cause errors when I start them. All motors except one is with shielded cable (the unshielded is on a 400V drive) and with 360degree metall cable gland in both sides of motor cable. All communication cables are shielded and grounded in the panel side only.

Also, the COM_LOAD was set to 500ms response and 0 retries. I changed this to 5000ms and 2 retries, however this didn't make the loop slow down. If there would be a slave timeout, I would suspect it to pause the loop I have for 5000ms two times before returning an error. And it doesn't it just continue to loop through all the blocks. Returning errors everywhere, it doesn't impact the operation since I don't evaluate the errors unless there are to many but it make me feel unsure that the operation will be fine in the long run.

Can a interference on the Modbus RTU line make the Modbus block return values but distort it to make the block go into slave timeout?

It seems strange that the block return Slave timout when there is no timeout?

Can the 230V VFDs somehow cause more interference, or should I look elsewhere?

 

[rQx]

I have found a solution and that is to have the response time to 50ms and retries to 10. It seems a little bit odd, so still wonder what can cause this issue in the first place :/

 

[Puddle]

I've spent quite a bit of time recently using modbus RTU in a 1200.

Unless you're doing it very differently to me, the COM_LOAD should just set the hardware parameters and the rest of the setup is through the master block.

Can you post a screenshot?

 

[rQx]

I've spent quite a bit of time recently using modbus RTU in a 1200.

Unless you're doing it very differently to me, the COM_LOAD should just set the hardware parameters and the rest of the setup is through the master block.

Can you post a screenshot?

The com load, specifies how long timeout and retries for each "non-response" at least it seems like that when you play with it.

 

[Puddle]

You're right, I was getting RTU and TCP confused with how the DB is laid out for each one.

It sounds very similar to the issues that I had to work through.
I found that unless the enable is dropped from the master block, it won't allow you to change the configuration. It also didn't seem to like changing the mode and I ended up throwing in a 10ms delay into my sequence to allow for that.

There's always the chance that the drive is also not communicating properly. I've had an instrument that would stop communicating after a few minutes of powering up, which showed as an 80C8 error.

 

[rQx]

You're right, I was getting RTU and TCP confused with how the DB is laid out for each one.

It sounds very similar to the issues that I had to work through.
I found that unless the enable is dropped from the master block, it won't allow you to change the configuration. It also didn't seem to like changing the mode and I ended up throwing in a 10ms delay into my sequence to allow for that.

There's always the chance that the drive is also not communicating properly. I've had an instrument that would stop communicating after a few minutes of powering up, which showed as an 80C8 error.

Yes, I have also implemented a delay between the cals although I have done it so it wait 1 scan cycle. I'm leaning towards hardware problem like you said