Powerflex 700 with Micrologix 1100 Ethernet

[Edwardp]

Hello,

I have an existing application that has a Powerflex 700 with a 20-COMM-E adapter controlled by a Micrologix 1100 via Ethernet. The setup works great sometimes but not other times. The micrologix is sending run, enable and speed commands to the drive using MSG commands. For seemingly no reason the MSG stops commanding the drive and stars generating timeout errors. After 15 minutes to an hour of sitting, it starts communicating again. According to the 20-COMM-E status lights, the Ethernet link is good but the drive is not receiving commands.

The Ethernet link is a direct connection from the micrologix 1100 to the 20-COMM-E.

I've tried a different 20-COMM-E module with the same results.

I've tried a new PLC with the same results.

Any ideas or solutions would be greatly appreciated.

Also, what would be the best method for setting up communications between the micrologix and the powerflex? I've been reading that Ethernet is not a good solution. I prefer get the Ethernet connection working but I'm open to converting to a different communication setup.

Thanks!

[mylespetro]

How many MSG commands are you using? Are they controlled in any way whatsoever or just constant rapid-fire sending/reading?

[tarik1978]

ID: IN6353 | Access Levels: Everyone
PowerFlex Drives: Controlling via EtherNet/IP from MicroLogix, SLC, PLC5, CLX V15 and below
https://rockwellautomation.custhelp....slc,-plc5,-clx

[Edwardp]

Originally Posted by mylespetro

How many MSG commands are you using? Are they controlled in any way whatsoever or just constant rapid-fire sending/reading?

Hello, Thanks for the response.

I have three messages. Two writes and one read. I'm not sure why, but the read is set to PLC5. I tried changing to SCL500 but it did not make a difference.
I have attached screenshots for review.
Also, I tried restructuring the logic to use an unlatch for the MSG like is shown in the 20-COMM-E manual. That did not help either.

[Edwardp]

Thanks for the response. I saw that doc. The one thing I did notice is that I only need to write N42:3 one time when the power is cycled. I'm going to try changing that.

Also, please see the previous reply to mylespetro

[OkiePC]

The way you have those MSG instructions programmed, they will fire off repeatedly as fast as possible all the time and bombard the drives and anything else on that network with packets. I would recommend throttling them a bit. I have a somewhat elaborate scheme i use with serial radio modems that is overkill for what you are doing but it does allow you to selectively skip nodes, adjust the rate of polling and will prevent you from hammering the network and filling up PLC and VFD ethernet buffers.

Since you're just dealing with a handful of messages, I would recommend using a self resetting timer to trigger them in series with the EN bit for each. Fire them off every half second or so. Fast enough to meet or exceed your control performance needs, but not faster than necessary like you have them now.

[Edwardp]

Originally Posted by OkiePC

The way you have those MSG instructions programmed, they will fire off repeatedly as fast as possible all the time and bombard the drives and anything else on that network with packets. I would recommend throttling them a bit. I have a somewhat elaborate scheme i use with serial radio modems that is overkill for what you are doing but it does allow you to selectively skip nodes, adjust the rate of polling and will prevent you from hammering the network and filling up PLC and VFD ethernet buffers.

Since you're just dealing with a handful of messages, I would recommend using a self resetting timer to trigger them in series with the EN bit for each. Fire them off every half second or so. Fast enough to meet or exceed your control performance needs, but not faster than necessary like you have them now.

I agree with everything you mentioned. The drive and PLC are the only thing on the network but I still have no need for the speed it's currently firing.

However, I don't think that it's going to fix the problem. When the problem occurs, the firing rate becomes the timeout time since the MSG done bit is not set.

Either way, I'm going to try slowing things down and see what happens. I'll have an opportunity to work on it again on Thursday...

Thanks for all the suggestions!!