PowerFlex + EtherNet/IP start up time?

How much time does your PowerFlex drive with ethernet module take to become "ready" on power up?

Here's one setup I have - CLX 1756-L63 B cpu with a 1756-ENBT module in the chassis connected to a 10/100 Hirschman switch, 5 PowerFlex 70EC drives.

Looking at the communication status lights, it appears the COM-E module is ready within a few seconds. However, the connection from the drive to processor varies from 5 seconds to 30 seconds. IP addresses are programmed in (No DHCP/BOOTP) and all devices are set on auto-negotiate.

The processor obviously polls to check for the drives, but it seems like it should be consistent - at least within a few seconds. Anyone have ideas or experiences to share? I need to consistently have the drive ready in under 10 seconds of power on.

Thanks,

J

I have a project I am working on that has a CLX 1756-L63 and 2 1756-ENBT cards talking to 16 power Flex 70 VFD's. 10 of the drive are on one ENBT card and 6 share the othe card with some PanelView's, I have noticed when I unpluged the Panenviews. the drives on that card came onine faster.
For this project time was not an issue.

I think you should take a hard look at your RPI settings.

Answer to issue from AB

We received an answer back from Tech support that explains the issue. It turns out it's actually an issue with the processor itself. When you power down a drive, the Control Logix processor tries 3 times to reconnect at your RPI (say 5ms). After those attempts, the processor only updates the I/O configuration every 30 seconds. Depending on when you power up, it could be anywhere from 0 to 30 seconds before the drive is seen. Hopefully AB will resolve this in the future.

J

There is a way to speed up the process. We did this with our Panelviews which power was shutdown when the machine was "turned off". We had an input on the processor that told us whether the Panelview was on or off. When the Panelview was off, we inhibited the I/O connection in the processor. When the Panelview was turned on and we knew it was booted up (used time) we enabled the connection. Solved the problem for us. Should be able to do the same the the Powerflex drive

Good idea, I will try that. Thanks for the tip!

I'm rather new in the ControlLogix arena. Can you talk about how the connection is 'inhibited' and 'reenabled' in the program? I'm experiencing the same slow startup using Etherrnet connected drives.

Got to run out for a while so can elaborate later if you need it.

Create two tags, type INT and call them ModuleEnable and ModuleInhibit. ModuleEnable=0, ModuleInhibit=4. You can name them something else just easy to follow

INHIBIT
SSV
Instance Name = Name of module you want to inhibit
Attribute Name = Mode
Source = ModuleInhibit


Enable
SSV
Instance Name = Name of module you want to inhibit
Attribute Name = Mode
Source = ModuleEnable

Once you enable a module it will stay enabled until inhibited. Only need to execute the SSV once and suggest you only execute one to keep execution low. Same goes for inhibiting a module

I think techsupport gave you correct answer - just guessing who was that . Why 30 seconds? Connection initiation goes over inconnected message and default value is 30 seconds. I don't believe you that it is changeable, because this is an internal message, but I will need to check on this.

bernie_carlton: you will use GSV to check for connection status and and inhibit modules.

Exploring TW's idea: Once you detected broken connection, and inhibited the module, you can "ping" it with unconnected CIP generic message, like "Device who". Set timeout for this message at 2 seconds.
If you got error 16#0204, repeat.
If you got .DN bit, then it means that device is alive and you can un-inhibit it and disable ping

Never tested it, but I guess it may work.

Thanks for the answers. We have two machines on our assembly floor. Will be able to try out the ideas tomorrow.

Just a verification for Contr_Conn's post. I was in a hurry and may not have been clear. I'm not sure how the ping idea would work, never tried it for the Ethernet lag problem we had. There may be inconsistencies in the time this way. But I have used the ping idea before. Don't use the connection for this. Do a DeviceWho with a short timeout. But this would be a plan b

What we had was a discrete Input telling us the Panelview did not have power. The Panelview was powered by our input power so we had an unconditional input anyway for diagnostics of the inputs. I just added code so if that input was not on the Panelview connection would be inhibited. Power on enable the connection.

If this would not work for you because you do not have an input or something let me know. I may have another method but would need to dig through the manuals


Anyway it goes let me know what you figure out

Am I dumb?
I don't know how to do an unconnected DeviceWho. Would anyone care to expand on it?

MSG instruction.

Message Type - CIP Generic
Service Type - Device WHO

Service Code - 1
Class Code - 1
Instance - 1
Attribute - 0

Destination - I like to use .Data[0] of a string. You can read what it returned if you like that way. Just manual put in the length of the string.

Contr_Conn may be thinking of something different but this is my idea of a ping instruction. It is the most basic CIP instruction I know of.

Edit - I put the Attribute incorrectly. It is now the correct value of 0

Any MSG can be used for "ping" as we don't care about response - please note that this is not a DOS "ping".

I prefer device who as it returns short usable data.
Destination length is different for every device, so you may experiment a little. I prefer DINT array as native logix type

And make sure that this message is unconnected!!! Connected message will not do anything good.

Make sure timeout changed as well!!

This is a great idea for proper stop and start of communications on an intermittent device.

I really don't like the I/O LED to blink on my processors unless there is a real problem. I like the discrete idea better that way I know when I "should" be getting a good connection. I think that using the discrete input with the "ping" MSG it would be really slick.

I usually reference my I/O LED light status to trigger a communications alarm on my HMI's. So I like these ideas a lot.

RSL

RSL said:

I usually reference my I/O LED light status to trigger a communications alarm on my HMI's. So I like these ideas a lot.

Click to expand...

I don't use the I/O LED status to trigger a communications alarm, I use it to trigger deeper communications diagnostics.

Once you have I/O LED blinking do this on all I/O devices

GSV
Class Name - Module
Instance Name - (Name of module)
Attribute Name - FaultCode
Destination - Tag Type DINT

This equates to the same fault codes that are displayed when you click on a module that is faulted.

By using this only when the I/O LED status is not solid it does not slow down your scan time except when there is a communications problem

Edit - And of course use the inhibit method above to mask communications faults that are caused by the power being off