MicroLogix 1200 to CompactLogix 5380 via ENI

Geospark, the PING results are in, 4 packets out, 4 packets in, 0% loss, average latency 4ms.

EDIT: This is with my laptop connected to the Netgear in the same port that the 5380 is using.

Ken Roach and Geospark, yet again you guys have aided in the solution to the worlds problems. I did as you guys suggested with recreating the Message Control and lo and behold the thing works!

I apologize for taking so much of your time, but at the risk of being called a fan boy, I got to converse with you guys.

I really appreciate all your patience, time and effort on helping me get this thing working. You guys are the best!

Edit: Also wanted to throw a thank you to everyone who contributed to this thread!

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...

Click to expand...

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

After Ken mentioned it, this was my problem on two other occasions, each time I called tech support and they eventually suggested the same as what Ken suggested in the quote. Basically the path of corruption is not having everything set correctly the first time you setup the message instruction. Then editing the instruction parameters to be correct - then it never recovers.

Each time I did not have to recreate the instruction, but only make a new MESSAGE type tag and use the newly created MESSAGE tag in my existing instruction. So online edits only.

Ken Roach said:

Another try: Create a new MESSAGE type tag to serve as the control tag and use that in a fresh rung.

While it's uncommon, MESSAGE tags can get their internal (not usually visible to the programmer) data corrupted.

Click to expand...

I would respectfully argue that it is more common than what Ken suggests.

Geospark,

Thanks for this information! I'm always looking to expand my knowledge a bit more, after all a day something is learned is never wasted.

As for the IP$00$00, where I saw this is after things already weren't working and multiple times did I change different settings in the Message Configuration Prompt, I began to look harder at the actual Message Control Data via the Controller Tags in Logix Designer. When I expanded the .Path and scrolled down to the 6 in the .60 part of the path I thought, what can I actually do with these parts of the Path at this level? Placing my cursor in the value box (as if I were going to edit the value of 6 in .60) shows a [...] button (as it would at any other part of the string). Clicking that button brings up a dialog box that contains the full path for editing in the format like you showed above, i.e. $14$0E192.168.60.160. When I opened the dialog box I seem to remember seeing it like this, $14$0E192.168.60.160$00$00. Even though I had removed 1,0 a while ago as per your instruction via the Message Control Configuration Prompt.

If I am remembering what I saw correctly, it would appear to me that the corruption may have began when I added the 1,0 then removed it and the Message Control didn't exactly follow suit and left it in as $00$00 appended to my .Path but changed everything else.

Also, note that I did not actually change anything when doing this, just simply trying to observe something out of place even if I didn't know what I was looking at.

A lot of times when I do something like this, it gives me a better position to understand what certain things mean or how to familiarize myself a little better with what I'm working. This also helps me better understand when good people such as yourself offer a fantastic explanation like the one you gave above.

I like the followup that we are doing here because it's not just important that we've come to a solution that fixed the issue, but maybe more important that we can figure out what "broke" so as to better understand for future installations.

Digression impending...
We have sales reps that will bring new and improved products to our shop and most of the time we will dismantle them in front of them to figure out how they fit and how they might malfunction so as to improve our understanding of why this product is "improved" or how certain features could be applied to application we might have. So, in essence we like to break shiny, new things and figure out how to fix them before we consider selecting them for applications.

EDIT: Lovell, I was in the process of typing this when you had posted, I agree that the corruption began at the beginning! Another note is that I was able to do this entire thing via online edits, from removing the entire rung to removing the tags and recreating new ones, so maybe I'm missing what you are saying on this. I appreciate your response!

GrownUpGerberBaby said:

...I like the followup that we are doing here because it's not just important that we've come to a solution that fixed the issue, but maybe more important that we can figure out what "broke" so as to better understand for future installations...

Click to expand...

Yes, root causing these things is important in some cases, and in others just interesting or satisfying to get to the bottom of.

For the "what" guys, the least we could take from this information is to remember the good advice to delete a troublesome MSG instruction, and/or backing tag, and start again. So we're concentrating on the what to do rather than worrying to much about the why.

For the "why" guys, the most we could take from this is the somewhat deeper knowledge of what is actually going on in the background, perhaps finding the erroneous data and manipulating it back into shape. Or remembering "something" about it from the Forum here and searching it out. This way we're concentrating on the why here more so than on the what. There is a greater sense of understanding and satisfaction in doing this, for some.

Having said that, I would err more on the side of using this knowledge to spot the possible error and then delete/rinse/repeat, rather than tinkering around with the path string.

This way, each reader, and their varying degree of patience and available time, can take what they will from this while hopefully reaching their goal.

And your thanks are more than welcome. Being receptive of appreciation is important in acknowledging to both parties that they have achieved something good. Both parties being the Forum contributors, and yourself, and the other likely readers, of course.

Happy holidays to you and yours

Regards,
George

GrownUpGerberBaby said:

EDIT: Lovell, I was in the process of typing this when you had posted, I agree that the corruption began at the beginning! Another note is that I was able to do this entire thing via online edits, from removing the entire rung to removing the tags and recreating new ones, so maybe I'm missing what you are saying on this. I appreciate your response!

Click to expand...

By "So online edits only." , I meant that no download was required. I could do all edit required to fix the program while online and in run mode. Same as what you are saying.

Lovell,

Two names for the same route it appears. Thanks for the clarification!

I hope everyone had a pleasant Holiday Season and is looking forward to the coming year!