ControlLogix changing MSG Path Data issue

Dirtleg

Member
Join Date
Dec 2014
Location
Virginia
Posts
25
So first let me say I'm sure this is an easy one to solve but it's thrown me off today.
Background, I am using a single message instruction to read data out of 23 Powerflex 525's by changing the instance and IP address in the message path. This is not an unusual situation overall but I'm having an unusual issue.

For the record I've done this with Powerflex 40's on DeviceNet and Powerflex 753 over Ethernet before using the same fundamental logic and it's worked without issue.

The message Path is a String FYI. When trying to modify the message path in the tag at MessageName.Path.DATA[15] for example if I move a '4' in SINT format into that data location it ends up being '$04' instead.

This throws off my IP address and the message doesn't work due to communication errors. If I manually replace '$04' with a '4' in MessageName.Path.DATA[15] of the message tag it starts working right away.

What I'm trying to figure out is how to get the data moved without gaining the additional characters.

I should mention it's a Compactlogix L43 running revision 20.18 and the Powerflex 525 drives are at revision 5.1.

TIA.
 
You aren't "gaining additional characters", you're inadvertently substituting actual hex values for ASCII characters.

The PATH String is a combination of hex values and ASCII characters. In the case of a MSG going out to an Ethernet device, the first four SINT elements in the Path string data array are the CIP hops, after which comes the IP address in ASCII format.

My guess is that you're trying to change the last octet of the IP address.

The problem I've run into with this is when the last octet changes the number of digits, i.e. when I go from .9 to .10 or from .99 to .100.

That affects the Length element of the path String, and also changes the fourth byte of the path string itself, which describes the length of the ASCII parts of the array.

In ControlLogix, you can convert a DINT to a String with the DTOS instruction. If you move the characters created by that instruction into the part of the string for the last octet, and then correctly modify both the Path String .LEN and the path string's DATA[3] value, then your MESSAGE control data block changes should work.
 
Thank you Ken.
I will admit I don't have much ASCII experience.
I tried using a DTOS earlier in the day with a CONCAT to create the IP address in string format and then copy that to DATA[3] but must have been messed up on the LEN.

I'll give your method a shot in the morning.
 
You aren't "gaining additional characters", you're inadvertently substituting actual hex values for ASCII characters.

The PATH String is a combination of hex values and ASCII characters. In the case of a MSG going out to an Ethernet device, the first four SINT elements in the Path string data array are the CIP hops, after which comes the IP address in ASCII format.

My guess is that you're trying to change the last octet of the IP address.

The problem I've run into with this is when the last octet changes the number of digits, i.e. when I go from .9 to .10 or from .99 to .100.

That affects the Length element of the path String, and also changes the fourth byte of the path string itself, which describes the length of the ASCII parts of the array.

In ControlLogix, you can convert a DINT to a String with the DTOS instruction. If you move the characters created by that instruction into the part of the string for the last octet, and then correctly modify both the Path String .LEN and the path string's DATA[3] value, then your MESSAGE control data block changes should work.

Ken, I'm wondering if it would work if the path decimalised "octets" had leading zeroes?

e.g. "010.001.125.035" instead of "10.1.125.35"

That would make for easier substitution of the path in the MSG tag, without changing its overall length.

I can try this tomorrow and report back... it's way too late here to do it now.

Of course a simpler answer would be to re-address all the IP's to start at 100, i.e. 3 digits already, but that may be too big a challenge to even consider.
 
This method frazzled me until I realized I have to account both for the total .LEN of the CIP Path as well as for the length of the IP Address string embedded in the CIP Path.

Here's a bit of logic that should work, but because I did it on a 1756-L71 you'll need to be sure your CIP Path to the 1768-ENBT and out onto Ethernet is similar.

CIP_Path_Calculate.jpg
 
Dave,

If you ever want to see our in-house Unix guy turn a particular shade of University of Washington Department of Computer Science purple, show him that the ControlLogix OS doesn't interpret leading zeroes as octal, but the closely-related RSLinx Classic software does.

Poking the correct values into both the .LEN and the .DATA[x] location that holds the IP Address String works in this case.

For anything less than twenty devices I would recommend using individual MSG control tags. They don't take up that much space, and brute force can be elegant in its own way.

In my case, I had 120 identical devices and needed to direct the attention of some MSG instructions to just one of them at a time, so the manipulation of the CIP Path in a MSG instruction made sense.
 
..... show him that the ControlLogix OS doesn't interpret leading zeroes as octal, but the closely-related RSLinx Classic software does.

OMG !! then you have to blame the choirmaster, not the choirboys... different song-sheets !

It reminds me of the time I discovered that JSR/SBR parameters are handled in the reverse order in SoftLogix, as opposed to "as specified" order for a hardware controller. It was a complete b@11$-up for our tried and tested "software standards"
 
Okay I got it. Probably just needed to sleep on it.

My mistake when using the DTOS to convert my DINT value to a string was that I wasn't selecting individual elements of the converted string when trying to insert them into the message path string.

For example, when I only need to change the last digit of the IP I copy String.DATA[0] into Message.Path.DATA[15] with a length of 1. If I need to change the last 2 digits of the IP I copy String.DATA[0] into Message.Path.DATA[14] with a length of 2. If all 3 need to be changed then it's the same but Path.DATA[13] and length of 3.
(disclaimer: depending on your particular setup the location of where you copy the data to may be different)

So now that that is sorted it works perfectly.

Thanks guys for helping me get out of my tunnel and look a little more broadly at this situation.
 
About the "copy one character, or two, or three" issue:

That's what my snippet does with the FLL and COP instructions.

The FLL is to zero out any characters that are present after the last dot in the IP address string. A hexadecimal zero value = a "null" character in ASCII, so when I execute the FLL instruction, all the characters after the dot become null.

The COP instruction copies either one, two, or three characters because the source and the destination are both SINT[x] arrays. I used the .LEN value of the string I created with the DTOS as the LENGTH argument of the COPY instruction, because that's going to be 1, 2, or 3.
 
In the "there's more than one way to skin the cat" department, I had an OEM who was doing something similar - they needed to send a command to each of 16 Cognex cameras, located at 192.x.x.11-18, and 192.x.x.21-28.

They had a loop with a counter that would go from 1-8 , and then build their command string by adding either 10 or 20 to the loop counter, then a DTOS, then a CONCAT with a fixed string containing the CIP jumps and first 3 parts of the IP address, ending up putting that into the .Path parameter of the MSG.
 
Ken, yes your FLL and Copy is definitely the more eloquent solution. Thank you for sharing it as I could see using it in the future.

In this instance as my customers maintenance department will ultimately inherit this I try not to use instructions they are most likely not familiar with. Some are much stronger in the PLC world than others.
Sad but unfortunately relevant.

And since the input for the path change was coming from an HMI I just used the last 3 digits of each IP as the Control List State value in the HMI and moved them into the path. That way it was a simple 1 rung of logic with a couple branches.
 

Similar Topics

Hi, I am curious to know what will happen to a Running 1756 ControlLogix L73 controller if the keyswitch is changed from Remote Run to Program...
Replies
3
Views
1,596
I've got a AB ControlLogix that I'm gonna be installing into a smaller chassis and upgrading its firmware. I've never done so before so I want to...
Replies
2
Views
1,342
There was a bit of discussion on this in another thread (@Maintenance Man - Going from 500 to 5000). Instead of continuing to hijack the thread...
Replies
17
Views
8,154
I'm newish to Rockwell and I have a situation where a lot of setup parameters have been entered and I've made a lot of code changes offline. I...
Replies
4
Views
5,321
Hi guys,I'm a newbie with Allen bradley PLC's and we're about to change a 1756 controller with a new one of the same type, would it be fine if...
Replies
6
Views
3,496
Back
Top Bottom