Application Note

Verifying PowerFlex Drive Still Present on EtherNet/IP

Overall Description
This application note details how you can check whether communications to a drive product is lost / present on EtherNet/IP in your Logix controller. In addition this application note has been amended to include good practice guidelines, that reduce delays with reconnection when the drive power is removed and returns. .

Background
EtherNet/IP contains 2 methods of communication, UDP implicit connections for realtime I/O control, and TCP/IP explicit messages that are non time critical initiated within the program or from other external software. As EtherNet/IP is an extension of the standard EtherNet, so it must conform to the public specification of EtherNet, which allows for considerable time-outs (up to 240s) A Logix controller communicates with a drive using the UDP part of EtherNet/IP, by establishing a connection between the drive and controller. This connection remains open and is executed at the specified Requested Packet Interval (RPI). The PowerFlex drive EtherNet/IP adapter 20 or 22-COMM-E is powered from the drive, so when the drive power is removed, the connection is broken with the EtherNet/IP scanner. The EtherNet/IP scanner retries the connection based on the RPI (=>100ms), until the TCP/IP stack keep-alive timeout occurs after 2 minutes, or after 5 minutes the inactivity timeout will tear down the connection. These retries consume communication buffer space, which may become congested dependant on the quantity of messaging, and the number of lost nodes. This congestion may take many minutes to clear before the scanner is ready to resume normal control of the drives. Therefore the configuration of power distribution to the drives and motors, is critical to drive operation when using EtherNet/IP. In general the configuration of installations are: 1. Input Contactors / Circuit Breakers often one circuit breaker for a large group of drives 2. Output Contactors after each drive keep the drive active, but remove power to the motor 3. External Comms Box keeps the comms card powered, so maintains the connection 4. Safe Torque Off optional card added to the drive, keeps drive active and removes power to the motor. 5. Auxiliary Power Supply option on PowerFlex750 series, keeps logic supply of drive powered Options 4 or 5 provide the best solution for installation configuration, whilst option 1 provides the cheapest solution. With option 1 when 1 drive needs isolating to open a guard on the machine, the circuit breaker often powers a large group of drives and I/O, which drop off the network resulting in the EtherNet/IP communication buffer becoming congested. When the power is restored it may take several minutes for the communication buffers to clear, and so prevent normal operation of the installation. This application note details how we can monitor drives, and then mitigate scanner congestion by inhibiting drives, so that Logix connections are re-established and drives are ready to run with minimal delay.

Page 1 of 3 RevC

Application Note

Checking the drive is communicating

The EtherNet/IP scanner does NOT contain a scanlist accessible in Logix, so it is not possible to interrogate a scanlist to check whether the drive node is still live. Therefore it is necessary to write a small program for each drive, using a GSV instruction looking at the EntryStatus of MODULE (the drive).

The example above shows a PowerFlex40 drive on EtherNet/IP called PFLex40_Line1. Using the GSV instruction, we can interrogate the EntryStatus of the MODULE PFLex40_Line1, and store the value of this in tag PF40_Sysvar. This can then be used to compare against the predefined values of EntryStatus: 16#4000 (16384 dec) Running: all connections to the module are established and data is successfully transferring.

The above program shows that Comms is OK. which could be used in your program to unlatch your start commands to the drive.

Inhibiting the drive when powered down

As previously mentioned, to minimise recovery time of the scanner, it is good practice to inhibit the drive / group of drives. However as inhibiting a drive also kills the drive communications, we need some feedback from the circuit breakers to determine whether drives are powered. The example below shows Power_Ok from an input on the circuit breaker. A further comparison of the tag PF40_Sysvar, is used to check whether the drive is inhibited, which is used as an interlock in the logic below. : 16#6000 (24576 dec) The MODULE object is inhibited To inhibit the drive (MODULE), we use an SSV instruction to send a value to the MODULE . MODE object: Value = 4 Value = 0 Inhibits the MODULE, shutting down all connections Re-establishes connections, and allow the module to generate a fault condition should comms fail

Page 2 of 3 RevC

Application Note

Therefore when the circuit breaker is operated to remove drive power, the drive is inhibited which prevents the scanner creating messages to regain the connection. This inhibit will be necessary for each drive grouped on that circuit breaker.

Page 3 of 3 RevC