Welcome to EtherNet/IP Driver for Communication to Allen Bradley ControlLogix PLCs

[BlueCheese]

Carter and JF3M,

You're both seeing some of the implementation details of how Rockwell's devices store and communicate data differently then it may appear within RSLogix5000.

For instance, RSLogix5000 shows a DINT as simply being an array of 32 BOOLs. This is nice programming-wise inside their software, because you can use the DINT as a bit-field seamlessly in your ladder logic. However, the data item itself is not an array of BOOLs and the PLC will not let you access it as such over EtherNet/IP.

Furthermore, an array of BOOL values is not quite like an array of DINTs. With the array of DINTs you can index inside the array and read/write individual elements. However, with a BOOL Array, the it is actually stored as 32 bits packed within a single element. You can only read/write the array by multiples of 32 elements. You can also only index into it by that multiple.

In both of these cases you're running into limitations of the PLC. As a workaround you can always use a read/modify/write or use separate tags to read/write to and have the PLC use ladder logic to copy it into individual bits of a different element.

Eric 

Message Edited by BlueCheese on 06-11-2009 10:08 AM

[JF3M]

Thanks for the insight on this issue.  I had kind of thought it was something like this, but needed to verify.  The help file leads one to believe this is possible.  I suggest improving the info/detail in the help file in future releases to clear up this subject of exactly what is possible to access and what isn't.  That will help to avoid future questions on this subject.

Thanks again.

[Vincent_R.]

Hi,

I'm new with Ethernet/IP code. One of my customer uses the code to interface with a SLC-500 PLC.

He uses a LV windows machine connected via a HUB to the PLC

He noticed following things, can you confirm?

** It takes about same time to read an entire file or just one element from a file.

** It takes about 80ms per file. Is-it the standard performance I can expect? On my side, I'm a little surprised, I'd have expected something like 20-25ms.

I asked him to confirm, if possible, with another Ethernet/IP client to check what is the fastest reading rate he can reach?

Do you have any other caveats? Things to check?

Best regards.

Vincent

[BlueCheese]

Hi Vincent,

To answer your questions:

- In general I have seen that the PLC takes a fairly constant time to handle a request, regardless of size. This would generally be expected since Ethernet is so fast that the transfer time of a larger request is tiny in comparision to the servicing time of the PLC.

- I do not have a SLC 500 to benchmark against. The MicroLogic 1100 I have is quite a bit newer and if I remember correctly was <15ms per request. The ControlLogix 5561 I have is about 5ms by comparison.

In general, the EtherNet/IP support of this driver is limited to an absolute minimum of several ms to do a request due to the overhead of submitting the request, the PLC processing it and sending a response, and the reception and processing of it. This is due to the nature of the explicit messaging protocol and the architecture of the driver.

Eric

[Vincent_R.]

Good evening,

Thanks a lot for your answer. Your figures look good to me. As I mentioned in my previous email, I asked to my customer to check with another client to compare reading performances. Once done, I'll post results.

Best regards.

Vincent

[GNR]

Hi,

I'm new to this EtherNet/IP Driver. I'm able to use the Tag Read and Write vi to send and recieve an array of DINT from the PLC. Now I want to send and receive a 2-D array of DINT. Does this driver support this function?

Thanks.

[BlueCheese]

Hi GNR,

Currently the driver does not have built-in support for reading multi-dimensional arrays (this may be an item supported in a future version). However, there are some alternative options available in the meantime...

I have not tried it, but the PLC may let you address a single dimension of the multi-dimensional array. If so, you may be able to iterate through one of the dimensions and then read an array for each.

Another option would be to use the Raw read and take a look at the data coming back when you read the 2D tag. For simple datatypes like a 2D array of DINTs you can likely deduce how their multi-dimensional arrays are sent across the wire with little effort. LabVIEW's flatten/unflatten to string methods can be used to easily convert the bytestream data to arrays of a particular type while doing proper endianness conversion.

Let me know if you have any success or if you run into any issues and I can try to help,

Eric

[GNR]

Hi Eric,

Thanks a lot for the reply. I will try and let you know the result.

I have another problem regarding  the I/O data part. I see your code 'Demo EIP Adapter" at page 5 of this post. Both get and set assembly instance data VI are put in a while loop. What I did is that I didn't put them in a while loop(I just run 1 time) and at PLC side I got a connection fault. I'm new to PLC so I'm not sure if this cause the problem.Thanks again.

[BlueCheese]

Hi GNR,

You are likely getting the connection fault because the assembly on the LabVIEW side has been removed and so the PLC is not able to remain connected to it.

The assembly will be removed by any of the following conditions:

-The Remove Assembly VI is called (this was at the end of the loop in that example)

-The refnum for the EtherNet/IP session in use is explicitly closed

-The top-level VI running your code stops or is aborted, causing LabVIEW to stop and clean up all running resources.

Eric

[Vincent_R.]

Hi again,

My customer has moved forward in terms of testing. When there is only the LV-Windows application wired to the PLC (not running the actual process), the performances are correct. The customer is currently finding out where is the difference with the final setup (there is another EthernetIP client, an HMI required for the process and, of course, the PLC will run the process control) to identify bottlenecks.

I've a question about Session In and Session Out input/output in our VIs. In the documentation, it's mentioned that there is no point using it except to kill a previous request as everything (session opening and closing) is done automatically. Do you confirm that playing with this information won't improve performance?

Best regards.

Vince