M580 - CompactLogix PLC explicit communication

[desa]

Hi,

Could anybody help me to setup explicit communication using the DATA_EXCH block without being a CIP expert?
I read the docs here: https://www.se.com/ng/en/faqs/FA409179/
The example of the CIP request in the last page of the pdf is the following:

The meaning of the registers - as I figured out - are:

00: 0252 - I don't know what the 0x02 means, the 0x52 is the service code of the unconnected send request.

01: 0620 - 0x06 is the class ID of the connection manager, but what is the byte 0x20?

02: 0124 - I suppose 0x01 is the connection manager instance number, what is the instance segment 0x24?

03: 1007 - timeout ticks & priority/tick time, does it depend on the partner or this value will be ok?

04: 000C - number of bytes from the next register to the "Data: 0001" row.

05: 044C - 0x04 is the number of words from the next register to the end of the tag name, 0x4C is the Rockwell read tag service.

06: 0591 - 0x05 is the number of characters in the tag name, 0x91 is a constant to read a tag by name.

07: 6170 - from here comes the name of the tag.

08:

09:

10: 0001 - number of elements to read.

11: 0001 - 0x00 reserved, 0x01 route path size. Does it mean we use one word from the next register (EIPRequest[12]).

12: 0001 - 0x00 route path address, is this the slot number? 0x01 is the port. Why is this 0x01? Is it always 0x01?

If I try this example with a 1769 Rockwell PLC and created the "parts" variable. A Wonderware CIP DA server can read it, but the response in the M580 PLC is:

00D2 - ????

0006 - by the docs this means "Only part of the expected data was transferred"

On the address pin of the DATA_EXCH block the value is: ADDMX('0.0.3{192.168.0.161}UNC.CIP').

I cannot guess the exact meaning of the following bytes:

00 MSB: 0x02 - request path size

01 LSB: 0x20 - segment, path segment

02 LSB: 0x24 - instance segment

03: 0x1007 - timeout ticks & priority/tick time

11: 0x0001 - route path size

12: 0x0001 - route path address, route path port

Any help would be appreciated

[JerryBartlemay · Accepted solution]

Hello, desa,

You're in luck.  Early this year I completed a white paper on this topic, with a pair of companion DFBs.  The document you reference was a key to figuring out a solution.

I've attached the document and DFBs.

Feel free to message me if you have questions.

[desa]

Hello Jerry,

Two hours ago we were able to successfully communicate with the Rockwell PLC. The only problem was we forgot to write the message length in the management parameters. It is working fine now. As I saw you created special FBDs to read/write variables.

We are going to try your blocks. 

Thank you!

Yours sincerely:

Dezső Sajtos

[Wak71]

Hello, I have a question regarding the Service code of "00CC" being returned vs "00D2".

Originally, I used your DFBs in conjunction with an M580 using a NOC-301 to talk to a ControlLogix L83E. These were the devices I had available in my lab.

My initially testing return values from the array in the Control Logix. 

The ReadResponse registers had the following values.

ReadResponse[1]  =  16#00D2

ReadResponse[2]  =  16#0000

ReadResponse[3]  =  16#00C3

Fast forward to applying this to my project in the field. I am using an M340 with NOC-401.2 and a CompactLogix L24ER-QBFC1B.

The ReadResponse registers had the following values.

ReadResponse[1]  =  16#00CC

ReadResponse[2]  =  16#0000

ReadResponse[3]  =  16#00C3

I am getting data back from the CompactLogix PLC. However, because the ReadResponse[1]  =  16#00CC, the EIP_Sym_Read_EDT DFB does not respond properly with the Last_Read_OK status. It thinks the last read was Not OK because it is solely looking for a value of 16#00D2.

Assuming I was doing something wrong or maybe there was some sort of difference in how the Control Logix responds vs the Compact Logix, I installed an NOC-401.2 into an M340 in my lab. I have it talking to the same ControlLogix L83E in my lab and I get the same response as my field testing (ReadResponse[1]  =  16#00CC).

Maybe this is the difference between the NOC-301 and NOC-401?

Is there any downside to receiving the 00CC response vs the 00D2 response?

[Wak71]

FYI, I had a need for the READ DFB on a project of mine.

I initially tested using an M580 with NOC-301 talking to a ControlLogix L83E.

Using the EIP_Sym_Read_EDT in my office I was able to read tag data back from the ControlLogix PLC.

When I tried to apply this same logic to an M340 with NOC-401.2 talking to a CompactLogix L24ER-QBFC1B, it looked like it wasn't working as the "Last_Read_OK" tag was always FALSE.

I found that the value of ReadResponse[1] was 16#00CC. (Not 16#00D2 as the DFB is looking for).

The ReadOut2 (aka Data_Out) had the proper data from the CompactLogix.

So I modified the DFB to allow for a ReadResponse[1] value of 16#00CC as a valid response.

I had a hard time finding the resource document to determine what a response of 16#00CC meant.

I consulted ChatGPT and found that "00CC" means that the device or controller has successfully processed a read tag request and is responding with the requested data.

The only difference between my initial testing and my field installation was the use of an M340/NOC-401 vs. an M580/NOC301. I'm not sure why these received two different responses. The CIP construction was the same for both so the CPU/Module must do doing something different behind the scenes.

 JerryBartlemay do you have any idea why these would behave different?

[JerryBartlemay]

Hi Jeff,  I haven't tested this with an M340.  The response should be the same in both cases.  It is derived from the unconnected send service request echoing back with an offset of 16#80.  The CC would indicate it is echoing back the 16#4C Read Tag Service code with an offset.  I need to explore this.  Thanks for pointing it out.

[JerryBartlemay]

One question, are you reading the array data correctly in the fourth and beyond words in the response?