Path to Freedom...
That is good news and well done you for persisting. I know what it's like when you get some downtime on a normally busy production line and you just want to get in and get something important done. I've been waiting two months for a line just to fit a flow sensor and guess what? Today is the day. A 40+ year old machine on the line decided it might be more productive to split itself in half (cast housing). It wasn't a good idea after all, bless its old soul.
Your kind of issue is just a process of elimination but it is important for the future that you provide us the "bigger picture" from the outset and let us be the judge of what is or is not important in the details.
Then we can get the "easy to check" things out of the way early on and focus in and prioritize what's left. The PING told you the road ahead is clear and then you just needed to get your vehicle in working order.
"Messing around" with MSG instruction settings (you did nothing wrong) and in particular the path, can sometimes corrupt the string containing the full path, even though it shouldn't. This is apparently one of those cases.
As a little add-on now that the pressure is off...
GrownUpGerberBaby said:
...I started thinking about earlier today I thought I might have noticed that the Message Data file started leaving things in that I had removed from the prompt i.e. I believe that the string still read as having 0,0 after I removed 1,0 in the form of IP$00$00...I could very well not even know what I'm talking about either...
Let's make sure you do know what you are talking about here...
The MESSAGE data type tag member
.Path is data type STRING. This, as you are aware, contains the full MSG instruction instance's Communications Path, as assigned by you.
Your path:
4,
192.168.60.160
When you enter the Path for the MSG instruction as a port/address pair it is converted to a hexadecimal string ($). The port number is Decimal "4", and although it's Hex equivalent is "$04", the CIP specification requires it to be preceded by a "1". So port "4" becomes "$14", "3" becomes "$13", port "2" becomes "$12", and so on.
So the conversion places
$14 at the beginning of the hexadecimal string.
The next part of the hexadecimal string is trickier. The conversion will ignore the comma after the port number but use it as a delimiter to signify that everything after the comma is the address of this port/address pair. The conversion will then read how many characters are included in the address. This includes both the numerical characters and the period "." characters.
So for address
192.168.60.160 there are 14 characters in total.
The conversion then places a Hex header after the port number and before the address to signify the character count to follow.
Decimal 14 = Hexadecimal
$0E
So now the conversion so far has
$14$0E which signifies the port number and address character count.
The conversion then appends the 14 address characters.
$14$0E192.168.60.160
When we look at the MESSAGE
.Path STRING we should see now see the above hexadecimal string. If we expand
.Path we can see that the STRING data type is made up of a
.LEN Length DINT and
.DATA SINT[82] character array. The array holds the individual characters. The
.LEN DINT member will hold the current decimal character length value for the hexadecimal string. This should now be displaying a length of "16" characters with the above path entered. This again is tricky. If we count the visible characters for the hexadecimal string:
$14$0E192.168.60.160
We will get a length of 20 characters. So why "16"?
The
$14 port number, and the
$0E address character length are special and are counted as only one character each with respect to the MESSAGE data type decimal character length. So instead of them representing 6 characters in total, they only represent 2 characters. The remaining 14 characters of the address are added to give us the decimal length of "16".
It doesn't end there though...
The address character total must be an even number of characters or else the conversion must add padding after the address to even it up.
Example:
192.168.60.16 (instead of
.160 = 1 less character)
So now our address contains "13" characters instead of "14". The hexadecimal equivalent here for "13" is "
$r".
The conversion will change the header for the address character count.
$14$r192.168.60.16
The conversion, reading an uneven header of "13", must now pad this out to an even number of characters. To do this it appends a hexadecimal "
$00", which is a decimal "0". In our case this has added back in one character to restore an address count of "14".
$14$r192.168.60.16$00
OK?
If we now add back in the correct
.160 octet and move on.
$14$0E192.168.60.160
Next, if we go back and enter the path you were trying earlier, where you incorrectly appended the "1, 0"...
4,
192.168.60.160,
1,
0
We can then see the two extra characters "
$01$00" appended in the
.Path hexadecimal string...
$14$r192.168.60.16$01$00
If you will notice here, there is no
"$00$00" hexadecimal character representation. The "
IP$00$00", that you mentioned seeing before deleting the MESSAGE tag, I would assume means you saw...
$14$r192.168.60.16$00$00
If so, then to have seen that in the hexadecimal string, you would have had to have incorrectly entered the path...
4,
192.168.60.160,
0,
0
Or started manually manipulating the
.Path string itself.
Either that, or the
.Path hexadecimal string somehow became corrupted. If I'm misinterpreting your meaning of having seen "
IP$00$00" then never mind. But the above explanation should do you or other readers no harm to know going forward.
The hexadecimal string conversion
.LEN attribute is probably the key stumbling block I've seen users trip up over where they are attempting to dynamically change the IP address of a MSG instruction on the fly. It is not the overall decimal character count in the MESSAGE
.Path string that we need to manipulate. It is the hexadecimal address character count header within the
.Path string itself that we need to manipulate, after first counting how many characters are in the new IP address, including the period "." characters.
Tricky, tricky!
But hopefully now you will "know what you're talking about" a bit better in future, or else you'll just forget it again, like I often do!
Regards,
George