PLC to AC Drive Via Modbus RTU

[jiml3412]

I've been using Modbus RTU for some time know communicating from a PLC to various devices, including AC Drives. My biggest complaint is the delay between sending a run command and getting a response at the drive. This delay seems to be random in length and is always a problem whether I am using one drive or 10. I am using 19200 baud rate and I have experimented with changing all sorts of settings with no luck.

Any ideas as to why this occurs? Am I just using a slow network? The drives I use only have Modbus RTU networking available.

 

[niallnz]

If the drive is taking a random amount of time to respond to a run command then I would think that it is seeing a corupted modbus message and is returning an error to the PLC. The drive should have a CRC error counter (Assuming RTU), check this and see if it is increasing. If it is then you probably have noise problem.
Alternatively if you are communicating with multiple drives you may have to wait until the PLC has finished with the other drives befor it can process you request.

What type of PLC and Drive are you using?

 

[jiml3412]

I am using Idec PLC's and Altivar Inverters. All components are usually very close together using twisted pair communication. I have not check the CRC error. I suppose this information is received by the Master and can be monitored there? Would this error information be specific about the type of error, i.e. noisy communication?

 

[itsmoked]

I can't answer that specifically but are these delays completely random?

Do they always vary in time?

How long are these delays you speak of?

Do you ever get cases where nothing actually occurs at all?

Keith Cress
kcress -

http://www.flaminsystems.com

 

[jiml3412]

Yes, the delays are always random.

Yes, the time varies every time and is not consistant.

The delay time varies from 0 to 2.0 seconds.

This happens all the time, on every system, regardless of drive quantity.

For example, if I have 4 drives and send a run command to all of them at once, one might start in 1/2 a second, then another in 1 second then another may start in 2 seconds. The stop commands works the same way. The next time it would be completely different.

 

[jraef]

Modbus is not the best communication standard, only the cheapest. Most other comm protocols involve a licensing agreement and maybe a special chip set, Modbus is "Open Source"; kind of like freeware. Vendors provide it so that they appear to be compliant to industry's demand for fewer proprietary systems, but they do so almost begrudgingly.

A VFD has a somewhat complex microprocessor based control system that must make constant updates to the operating parameters of the motor firing circuit, so that always gets priority. Modbus communications, besides being relatively slow, usually requires processing power in the mP of the VFD to convert the commands to ts machine code, but it is not given very high interrupt priority. That is why most VFD manufacturers have their own protocol for communication between their VFDs and their PLCs; it is optimized to keep the overhead as low as possible. You have chosen to use a PLC from a vendor who does not make VFDs, and a VFD from a vendor who has no reason to optimize Modbus comms because it allows the use of other vendor's equipment. As long as you do that your comm rate will be less than optimal.

That said, one of the few VFDs on the market that does do a decent job of open communications is the Altivar 71 drive, because they went with a dual mP topology. One processor does nothing but the firing control, the other does all the other peripheral stuff such as communications, protection etc. But that is only the ATV71, none of the rest of the Schneider drives have that feature.

 

[controlsdude]

If it is not the modbus as a problem

then it sounds like a noise issue, then upgrade the cable that you use to better quality cable. If you have a shield is it grounded on one end only. Is the sheild carried through to the other drives?

Typical comm problems, shielding and quality of cable.

 

[dpc]

You may want to sniff the Modbus packets to see if there are a lot of comm errors and repeated messages.

 

[jiml3412]

I will try and run error records and post my results.

Thanx

 

[AE6BH]

Download MODScan32 & look at the Modbus traffic

 

[ozmosis]

jiml3412
Do you only get the problem when the VFD's are running? (meaning, when you are not running, can you monitor the data from the VFD with no problem?).
If yes, then it is highly likely the problem is HF noise. A very common problem with connecting VFD's on an RS485 based network. Chances are the body of the VFD's are not bonded too well and the HF noise is getting into the comms network and causing the disruption to your communication.
How far apart are the VFD's? if quite a distance, then (as a test) try running a large ground cable between VFD's and to good grounds to ensure they are all of the same ground potential.
Try things like reducing the PWM switching frequency in the drives, this will reduce the level of HF noise in the network.

 

[LionelHutz]

Do you have some sort of error timeout control in the PLC. Generally speaking, the Modbus master sends a command and then waits for the response for a set timeout delay. If you have a long timeout set then when there is a communications error it takes a long time before the master will acknowledge and address the error. ie, the master sends a command and the slave does not receive it and therefore does not respond leaving the master hanging for the delay time before trying again or continuing to process new commands.

 

[roydm]

Try adding a PC into the loop to monitor the traffic as AE6BH (Electrical) suggests, Any old laptop with a serial port will do. Connect ground to ground and RX data to the the negative wire of the twisted pair, I know 232 and 485 are "not compatible" but it works anyway, I haven't tried Modscan32 but even a terminal program will show a pattern.
Roy