MSG error 16#0008_0301

I have an existing system with one main PLC, a 1769-L35E, and numerous MicroLogix 1100 satellites. The system already sends messages, so I know it works. The satellite PLCs communicate in an indirect way using the multi-hop feature that I don't understand, while the main sends messages directly but only to a few of the satellites. I need to create a new message from the main to one of the satellites, so I copied the MSG command the main PLC uses for talking to another satellite and changed the IP address to my target. And of course it doesn't work because I ain't that lucky. I'm sending a single int, so it can't be memory. The error code I am getting is 16#0001 and the extended error is 16#0008_0301. I read somebody else's post on a similar error but they had a bunch of faulted VFD connections I don't have. This system is fully functional except for my little upgrade. Any suggestions from the smart gallery?

I copied the MSG command the main PLC uses for talking to another satellite and changed the IP address to my target.

Click to expand...

Create an entirely new MESSAGE control tag, and enter the arguments for the MSG instruction one at a time from scratch.

May as well remove the chance that something in the MESSAGE control tag got corrupted during copy-paste.

Is your message going to one of the "remote multihop" satellites, or one that's on the LAN with the CompactLogix ?

You may also want to poke around the message logic and see if these are Connected messages, and how they are re-triggered.

Also have a look at the embedded Web pages for the 1769-L35E; that's often a good way to get a look at the connection capacity / usage of the controller.

you did change the MSG file # and The Routing Information File correct?

further testing results...

Okay after some dumb luck I have found that when the operators go on break and the system is stopped, my message works. This is maybe due to the fact that no other messages are competing? The thing is all the other working messages are set to clear .EN and re-enable every time their .DN bit is set. They don't appear to check for anything first. So what could mine be missing? And by the way, thanks for answering.

Both PLC's are able to go online on my PC that is plugged into the main switch, so I think that means they are LAN, right? Both have 10.20.32.xx addresses. I explored the web pages but I don't know enough about networking to understand what I'm looking at. I added more info to my reply. Still experimenting...

The thing is all the other working messages are set to clear .EN and re-enable every time their .DN bit is set.

Click to expand...

That sort of logic is seldom appropriate, as it uses up the maximum amount of buffers and bandwidth and most systems that need fast inter-machine updates use a different comms method or a single controller.

I strongly prefer to use a self-resetting timer with a few hundred milliseconds period, and use the /DN bit to trigger an MSG (when the /EN bit of the MESSAGE Control is false).

It's possible that during system idle times, HMI devices are not active, which frees up some comms resources.

Let's take a step back: is there messaging initiated by logic in the satellite MicroLogix controllers, or solely from the central CompactLogix ?

The satellites send messages to each other using multihop but not to the main as far as I can tell. There are about 40 of them so maybe I missed it. The central only sends messages to some of the satellites, but what I just now discovered is that central is sending a read message to my target overlapping the time I'm asking the main to send a write to it. So I changed these 2 messages to stagger, and it's working perfectly. Hopefully this doesn't mess up the timing too much.
You are correct. Using up all the bandwidth does seem ridiculous. The fact that this place is so hokey is probably lucky for me though. Where else are they going to let a rookie have free reign over the controls? Thanks again for your help! I love my job!

Large, complex systems that lack documentation or institutional knowledge can be either overwhelming or an engineering and improvement challenge.

If I were asked to work on a system like that, I would spend some time documenting every MSG instruction's source and destination and trigger conditions.

Take screenshots of the embedded Web pages for the 1769-L35E CompactLogix that show the network connections and Ethernet statistics, so you can compare them when you make changes.

plclady said:

The fact that this place is so hokey is probably lucky for me though. Where else are they going to let a rookie have free reign over the controls? Thanks again for your help! I love my job!

Click to expand...

The upside to conditions like that is that you will be seen as a super hero in short order.

I wholeheartedly agree with Ken's comment about documentation. Add address descriptions to every word and bit of both ends of every message.

I like to prefix those comments with "FROM System X" or "TO System Y" for example. That makes it pretty easy to identify what is what when viewing addresses in a list or in and exported spreadsheet.

I do the same with operator interface addresses "FROM HMI" and "TO HMI" and if there is more than one interface, change the "HMI" to something more specific.