Welcome to EtherNet/IP Industrial Protocol Support

[Brian Gapske]

Hello,

I'm using this on a cRIO target and (successfully) talking to a AB 1756-ENBT. I was hoping to get an idea of typical transfer rates. For instance, if I want to send sensor data for 8 transducers to the PLC using the I/O data messaging, what is the fastest update rate one can typically expect? (assuming each channel is a 32bit value and there are no networking issues)

Thanks in advance.

Sincerely,

Brian

[jlsmith1000]

Brian,

I'm not using this on a cRIO target so I can't speak to that, however, I am using it between LabVIEW on a PC to a Logix 5000 plc and I see reliable communications at 20ms with a reasonable (read:acceptable) amount of jitter.  I am not, however, passing I/O values over this, but handshaking between the PLC and the LabVIEW app.

[dwisti]

I/O assemblies are the fastest way to communicate via EthernetIP.   However, this is all  dependent on which cRIO (9002, 9014, 9023,9025) and how much CPU  time you are willing to sacrifice will ultimately determine how fast you  can communicate.  I would imagine the same is true on the Allen-Bradley  side.

[Brian Gapske]

Thanks for your replies jlsmith and dwisti,

Just to elaborate, I'm using a cRIO 9074 (soon to upgrade to a 9024 for other reasons) and have a test program that only does two things:  sends twenty random 32-bit values to the PLC and monitors the CPU usage. This example program loads the CPU at around 78%. (I'm polling the CPU usage every 100 ms in another loop and inserting the load value into the data sent to the PLC)

I'm seeing that the loop that updates the assembly data on the cRIO side takes approximately 1 to 3 ms to update (there is a 1 ms delay in the loop). On the PLC side, I have the Ethernet module set up with a Requested Packet Interval of 1ms, and a program that tracks how fast the data values change. On the PLC side, I'm seeing the maximum time between two consecutive updates to be around 10ms, though typically less than this.

I do realize that I’m probably taking some performance hit by connecting to the PLC with RSLogix and not running the cRIO code headless.

I was interested in how my results compared to others'

[BlueCheese]

BrianGapske wrote:

Hello,

I'm using this on a cRIO target and (successfully) talking to a AB 1756-ENBT. I was hoping to get an idea of typical transfer rates. For instance, if I want to send sensor data for 8 transducers to the PLC using the I/O data messaging, what is the fastest update rate one can typically expect? (assuming each channel is a 32bit value and there are no networking issues)

Thanks in advance.

Sincerely,

Brian

Hi Brian,

It is up to the PLC to configure the rate of I/O data assembly exchanges. There should be no problem going up to rates of 1000Hz (1ms intervals). The size of the assemblies should be irrelevant with regards to how fast you can go. As David pointed out, the impact to these higher transfer rates will be in CPU time on the cRIO, but it should be able to keep up.

Also, the EtherNet/IP stack uses a processing loop in the background that runs at regular intervals. On cRIO targets this is limited to 5ms by default because those targets tend to be a bit slower (we currently do not differentiate between speeds of different cRIO targets). This might limit you to 5ms update rates by default, but you can use a property node on the EtherNet/IP session to reduce this down to 1ms at the expense of more CPU time being consumed.

Eric

[jlsmith1000]

1ms RPI on the PLC side is WAY too fast, at least for the PLC and it explains why you're CPU usage is so high.  I would expect to see jitter at +8 to 9ms consistantly.  I would suggets that 5ms is the absolute fastest I would go, and 10ms is ideal.  The RPI of 1ms is forcing LabVIEW to refresh the data to the PLC every 1 ms.  The PLC communications updates asynchronously to the logic solve.  Assuming an overhead + program scan time of 5ms, with a 5ms RPI, you're looking at your data roughly every 4ms given the way the PLC time slices logic solve with system overhead.  I'd recommend that you not set that RPI faster than 10ms unless you absolutely have to.  In which case, you need to consider using a periodic task at 5ms to handle that incoming data.  If you need performance more on par with that 1ms RPI I strongly recommend you look at the L7x family of ControlLogix PLC(s), they are 400% faster than L6x and faster yet than CompactLogix.  That will alleviate issues with timeslicing with periodica tasks etc.

[Brian Gapske]

Thanks Eric!

That was very helpful.I decreased the the update interval for the stack and increased my loop delay. I'm now seeing around 7ms worst case on the PLC and just over 50% CPU on the cRIO. This is closer to where I want to be.

Brian

[Brian Gapske]

Thanks for the suggestions Jeff, for some reason I missed your post earlier.

Yeah, I'm not a PLC guy (yet)

We're still prototyping a few things and someone else has the PLC end of it for now. I'll pass your comments along though.

Brian

[Adam L]

Hello,

I am a mechanical engineering student the Milwaukee School of Engineering. As part of our SAE Supermileage program I am building an electric motor dyno system to test our engine.  I am trying to control an Allen Bradely Powerflex 755 motor drive with LabVIEW.

I am wondering if anybody has any examples or advise for communicating with this device.  I am running LabVIEW 8.6.

So far, I have installed the Ethernet I/P.   I have also tried creating a VISA devise with no sucess.

Thanks,

Adam

[jlsmith1000]

Hi Adam,

I suspect the issue you're going to have using the Power Flex 755 is that it is also an EtherNet/IP adapter as is LabVIEW using the EtherNet/IP driver.  The drive is incapable of behaving as a scanner, and I don't know that LabVIEW can, at least from what I've seen using the driver myself.  One of the two devices needs to be a scanner unless you're doing messaging, which the drive won't support for control of motion.

I don't know if LabVIEW can behave as the scanner for other communication types such as DevcieNet or a Profibus master but assuming not, I would suggest that you look at adding DriveLogix to the drive, which essentially is a CompactLogix PLC in a small expansion card form factor.  It communicates to the drive over the backplane and acts as an EtherNet/IP scanner which would interface to LabVIEW.  I know DriveLogix is available on the 700S and I belive Drive/DeviceLogix is available on the 755 family as well.

Other than that, if there's another way, I'd like to hear about it when you figure it out for my own benefit.  Hope this helps you with your efforts.

Regards,

Jeff