5380 DLR / Dual-IP Status

Hi all,

Is there a way to programmatically determine whether the controller is configured for DLR or Dual-IP? Not the biggest issue at present, but I’m hoping to make more “elegant” some utility code to parse IP info when DLR is enabled (i.e. I don’t want to trigger and error pointless messages to a non-existent A2 port).

I have an open ticket with Rockwell, with hopes of (however slim) of obtaining some internal documentation about messaging and obtaining info from the newer 5x80 controllers.

Thanks!

Jeremy, I don't think we have one of these new processors handy, if I'm wrong, I'll figure this out in the morning.

I've helped people find obscure CIP objects, Wireshark is critical. Recently, someone needed access to the Grand Master Clock Priority 1 value. Here is basically how I found it:

• Get online with a PLC, preferably one with nothing in it to minimize the number of packets.
• Open wireshark, select the appropriate adapter but don't start capturing packets
• Put wireshark and Logix side by side
• Open the Controller Properties, go to the Date/Time tab
• Start wireshark, quickly switch to Logix and click the Advanced button (to open the advanced clock tab).
• Stop Wireshark.
• Start looking through packets

Sometimes you get lucky and wireshark already knows some of the details and has the stuff you are looking for labeled. Like in my case, there was a packet that contained TimeSync object and a bunch of the attributes.

The key here is triggering RSLinx to query what you are looking for, and capturing as few packets as you can because there will be a LOT in a short period of time.

Another potential hangup, is RSLinx has the ability to intercept incoming packets and obscure them from the network stack. In this situation, you will see outgoing packets, but not inbound ones. I bought a sharktap for this. I suspect that a sharktap won't be necessary to find the port settings.

To get the Dual IP setting, I'd probably do what I described above, you should get the packet as soon as you open controller properties. Or maybe a better way is simply to right click on the controller in RSLinx and open Module Configuration. I'd guess that the dual IP configuration would be there as well.

If you do capture some wireshark packets, I'd be willing to help you take a look at the packets. I started making a list of these CIP objects, this would be a nice addition. I hope to someday publish a comprehensive list.

But maybe someone will come along and already know the information and all this was just a bunch of words

EDIT: Well now I see that the priority 1 value could have been retrieved using GSV, but to be fair to me, the guy I was helping was trying to get the value via python. I suppose I could have had him use the GSV, then just read the value, but that would have been no fun

Thanks! I’ll give it a shot.

Try a CIP generic message:

• Service = 0x0e
• Class = 0xf4
• Instance = 0x00
• Attributes = 0x09

Make the destination an array of INT. Since it's getting 9 attributes, I suppose a length of 9, but you could make it larger.

I'm not 100% sure that the dual IP stuff is in there. The PLC I was checking was already configured for dual IP mode, but I was not able to change it to see if any value in the array changed. Hopefully I'll be able to borrow one tonight and dig in more.

Try this:

Dual-IP mode, A1 enterprise port, use path=THIS and instance=2
Dual-IP mode, A2 device-level port, use path=THIS and instance=3

Tried Wireshark earlier, and yes, there’s tons of stuff to dig into. I’m not even sure where to begin parsing the packet payload.

I’ll test that, dmroeder.

Is there a Rockwell reference floating around with their objects/classes/attributes?

JeremyM said:

Tried Wireshark earlier, and yes, there’s tons of stuff to dig into. I’m not even sure where to begin parsing the packet payload.

I’ll test that, dmroeder.

Is there a Rockwell reference floating around with their objects/classes/attributes?

Click to expand...

Not really. There is a KB article that basically points to all the various other KB articles talking about different CIP objects. I'll see if I can dig it up again. As asked Rockwell for some sort of list or documentation on the various CIP objects, they basically said that they only provide that to encompass partners.

edit: KB QA36669 is the most comprehensive "document" that they publish

Isnt my post sufficient? Do a read , if you get error then it's DLR, no?

My MSG didn't work at all in a L310ER (I only had a L30ER to test it).

Looks like BachPhi has a solution. Looking at wireshark, it appears that RSLinx asks for DLR status, which returns an error (0x05 path destination unknown) when the PLC is configured for dual IP. In that scenario, it makes a few more requests for information, some of them failing, then eventually asks for the port labels. I'm guessing when it sees that the labels are "A1" and "A2", it has indirectly confirmed that it must be Dual IP mode. Something like that.

Checking for DLR is something like Service 0x0e, class 0x47, instance 0x00, attribute 0x01. It would error when configured for dual IP, value of 3 is returned when DLR. But again, BachPhi has a solution he is happy with it, and it's similar in that it either works or it doesn't so I'd probably go with his.

A GetAttributeAll request to instances 1 of the DLR object (class ID 0x47) to the IP address of the Logix processor will return a "Path Destination Unknown" in case of "dual-IP mode". And will return the information of the DLR object in case of "Linear/DLR" configuration.

The easiest way to check this is with the ODVA's EtherNet/IP tools by Molex which can be download for free from the Molex website. Below I post two screenshots of this test.

BachPhi said:

Isnt my post sufficient? Do a read , if you get error then it's DLR, no?

Click to expand...

I've been doing so in this fashion so far, but I was hoping to find a more elegant way than a bombed message to determine the setting.

I now recognize this is as Exhibit #17721185 demonstrating why Rockwell and clean solutions don't always coexist.

AlfredoQuintero said:

A GetAttributeAll request to instances 1 of the DLR object (class ID 0x47) to the IP address of the Logix processor will return a "Path Destination Unknown" in case of "dual-IP mode". And will return the information of the DLR object in case of "Linear/DLR" configuration.

The easiest way to check this is with the ODVA's EtherNet/IP tools by Molex which can be download for free from the Molex website. Below I post two screenshots of this test.

Click to expand...

Thank you! I played with this tool and it became clear that the "DLR/Dual-IP" mode selection is seemingly an enabled/disabled state of 3 independent interfaces: Class 0xF5 Instance 1 (DLR), Instance 2 (A1), and Instance 3 (A2).

Instances 1 and 2, never coexisting, have the same MAC address. Instance 3's MAC address is just an increment by 1.

Curiously, IP message paths begin with '2' for DLR, '3' for A1, and '4' for A2, so I suppose a programmatic means of adjusting message paths with knowledge of the state of DLR/Dual-IP without the need to manually do so, might be worthwhile...

Jeremy, good to know my post was useful. I use the ODVA EtherNet/IP tool all the time. I wish it could be updated. Newly added attributed of the Ethernet Link object for instance are not supported. But well, it is free so I guess we will have to live with it.

dmroeder said:

Checking for DLR is something like Service 0x0e, class 0x47, instance 0x00, attribute 0x01. It would error when configured for dual IP, value of 3 is returned when DLR. But again, BachPhi has a solution he is happy with it, and it's similar in that it either works or it doesn't so I'd probably go with his.

Click to expand...

I'm glad you mentioned this (the instance happens to be 1). Since this thread's creation, I've made several generic CIP AOIs to be able to obtain class-specific attributes from anything you can hit by path. Testing the DLR module against both configurations revealed what you were saying it would. I can condition this module's code to flag a first-pass read failure, stop further attempts to message, and provide external status.