Studio5000 Message Path length not following path changes

[Dirtleg]

So I'm using a single message instruction to read data out of multiple VFD's through an HMI screen. This is not new to me and I've been doing it for quite a while without issue. Until now. All the VFDs are in the project IO tree.

On my previous projects all my VFD IP addresses started at XXX.XXX.XXX.101 and went up from there.

I've started at a new company this month and was asked by my boss to get this submitted for standards approval. The hiccup is that their IP addresses for VFDs start in the XXX.XXX.XXX.51 range and go up to XXX.XXX.XXX.199.

When using something below the value of 100 the Message.Path.LEN value is 16. When using 100 or more the value of the Message.Path.LEN needs to be 17.

The problem I'm having is that when I update the message path to a value over 100 the Message.Path.LEN stays at 16 and so I get an incomplete (or pointed at the wrong device) value in the path as it leaves the last digit off in the message path. If I go to the controller tags the correct value is in the path in the ASCII data array but is not being used in the path.

I have tried to manually update the path length with compare and move instructions when cycling between the 2 different length paths but even though the path length changes in the message.path.LEN to the now correct length the message path does not update properly.

At that point if I look at the Message.Path.Data array everything is where it should be but when I look at the path in the actual message it is pointed to a VFD with a different IP address.

I'm using an emulator so the messages aren't actually completing but that shouldn't be an issue when just changing the path.

Anyone have any insight here? Seems like it would be a simple thing but??

 

[Ken Roach]

I've encountered the same thing for a similar reason; I had over a hundred single-axis motion controllers and had to message to each one.

I'll go check my archives, but my recollection is that the solution was... inelegant. The CIP Path was meant to be entered via the Studio 5000 dialog and changing it at runtime is something I recommend against unless there is a very good application reason like yours.

 

[OkiePC]

Can you pad the field with a leading zero when the last octet < 100?

If that can work, then the length could remain constant.

 

[Dirtleg]

Thanks for the responses.

My inelegant solution was to have 2 separate messages. One for a path length of 16 the other for a path length of 17 and trigger them based on a value of less than 100 or GEQ 100.

It works but I don't like it.

 

[Ken Roach]

I have tried to manually update the path length with compare and move instructions when cycling between the 2 different length paths but even though the path length changes in the message.path.LEN to the now correct length the message path does not update properly.

You've put your finger on it; the .LEN of the CIP Path string is not the only factor.

The CIP Path is stored in the MESSAGE control tag as a sub-element of STRING data type (.PATH).

That STRING contains the CIP path to get to the backplane, then the Ethernet module, then the network port, then the target IP address (and beyond, if that's where your message goes).

The IP address of the message target is just part of that path. When the IP address changes in length, you must adjust TWO parts: the .LEN of the .PATH String, and one byte in that string that designates the length of the IP address.

Example message control block .PATH String, where .PATH.LEN = 16

$01$01$12$p192.168.1.11



Just our luck; Studio 5000 considers "$p" to be how it encodes hex 0x0C = decimal 12. The IP address itself is 12 bytes "192.168.1.11".

If we change the IP address, both that third byte and the overall length change:

$01$01$12$0B192.168.1.3


$01$01$12$r192.168.1.100$00


For IP address 192.168.1.3, the length byte is $0B = 0x0B = 11
For IP address 192.168.1.11, the length byte is $p = 0x0C = 12
For IP address 192.168.1.100 the length byte is $r = 0x0D = 13

The last thing I saw is that the CIP Path . LEN seems to auto-adjust add one more null byte on the end, to make itself an even number of bytes. I'm not sure if this is to account for string handling elsewhere in the firmware, or what. But it makes sense to be sure that the subsequent bytes in that CIP Path string are all a value of 0x00, so you don't inadvertently add a digit.

 

[Ken Roach]

Here's an example of how I did this in ladder logic:

 

[Ken Roach]

Can you pad the field with a leading zero when the last octet < 100?

Ooh.. fire up the wayback machine !

For reasons lost to the mists of time, leading zeroes in IP address octets indicate that the value is being represented in OCTAL, not Decimal !

There is no formal standard for a operating system or application to ignore that ancient tradition and discard the leading zero, or to apply it to the dismay of programmers who don't remember Atari or the '85 Bears.

I have not taken the time to figure out how the Logix OS handles it.

 

[Dirtleg]

You've put your finger on it; the .LEN of the CIP Path string is not the only factor.

The CIP Path is stored in the MESSAGE control tag as a sub-element of STRING data type (.PATH).

That STRING contains the CIP path to get to the backplane, then the Ethernet module, then the network port, then the target IP address (and beyond, if that's where your message goes).

The IP address of the message target is just part of that path. When the IP address changes in length, you must adjust TWO parts: the .LEN of the .PATH String, and one byte in that string that designates the length of the IP address.

Example message control block .PATH String, where .PATH.LEN = 16

$01$01$12$p192.168.1.11



Just our luck; Studio 5000 considers "$p" to be how it encodes hex 0x0C = decimal 12. The IP address itself is 12 bytes "192.168.1.11".

If we change the IP address, both that third byte and the overall length change:

$01$01$12$0B192.168.1.3


$01$01$12$r192.168.1.100$00


For IP address 192.168.1.3, the length byte is $0B = 0x0B = 11
For IP address 192.168.1.11, the length byte is $p = 0x0C = 12
For IP address 192.168.1.100 the length byte is $r = 0x0D = 13

The last thing I saw is that the CIP Path . LEN seems to auto-adjust add one more null byte on the end, to make itself an even number of bytes. I'm not sure if this is to account for string handling elsewhere in the firmware, or what. But it makes sense to be sure that the subsequent bytes in that CIP Path string are all a value of 0x00, so you don't inadvertently add a digit.

So what you're saying is that if I were to update the value of Message.Path.DATA[3] to correspond with the new path length that it should work.

This is new info for me so thanks for shedding some light on it. It makes sense now that you've put it in perspective.

Thanks Ken.

 

[Ken Roach]

This is not a standard thing that you should expect to know or understand out of the box. I'm an A-B networking expert and it took me a lot of poking and swearing to figure it out.

 

[alive15]

Couldn't you write logic to where it uses 16 as length, and if you get a fault, then use 17. If it passes, then 16 was correct. So that way, you are checking both lengths and the PLC will eventually use the right length. Wouldn't this method use less logic in the long run.

 

[Ken Roach]

and if you get a fault

Good point. But what if the length 16 logic sends to MSG to Node 11 instead of Node 111 ?

I have used "if fail, then change and retry" logic in some circumstances.

But here, where the right solution is relatively straightforward and can be read and understood by somebody years later, I would be willing to put in a small handful of ladder logic rungs.

 

[Dirtleg]

Little more info. I've got it working just fine now. I did find that using the destination node string length to update the message path string length by adding 14 didn't work when the length is 3. When the Path string length is set to 16 it works but not on 17. If I make it 18 it works. You alluded to it wanting to make the length an even number so when 17 didn't work I tried 18 and it works. So the length needs to be manipulated if the node value is above 99.

Again thanks for sharing your insight on this Ken.

 

[alive15]

Makes sense, thanks.