SLC 500 MSG Instructions

this is just a "wild guess" - feel free to ignore it ...

you aren't (by any chance) trying to read all of this data (from multiple MLX1200s) by doing some sort of fancy "looping" action are you? ...

specifically, are you using 12 separate MSG rungs to do the 12 reads? ...

another thing that I've seen create problems ... sometimes programmers will Copy and Paste the first MSG rung - and then modify the setup from that "starting point" ... I do NOT recommend that - I've seen it cause problems in the past ... specifically, I recommend that you make a brand new rung for each and every MSG - and then enter a brand new MSG instruction on that rung ...

I definitely didn't copy and paste the rungs but Im not absolutely sure what you mean by loop messaging. Therefore, Im not sure if Im using loop messaging.

quick question: how many (actual count) MSG Message instructions are in your SLC program? ...

=========================

explanation: some programmers use just ONE message instruction - and have their program change/shift the parameters inside the MSG ... that "changing/shifting" would usually be done in a "loop" - using Indirect Addresses ...

many programmers consider that type of thing to be an "elegant" solution ... ("Look, Mom, I only needed ONE rung to send twelve messages!") ...

personally I don't recommend it - mainly because it's a nightmare to troubleshoot ... think: how do you troubleshoot message number 6 - if the parameters (and the error messages) are constantly shifting among all of the other messages in the loop? ...

Attached is a PDF showing the general format we use to communicate with several devices. In this case it is a MicroLogix 1100 using Modbus but I don't think that takes away from illustrating a method that works for us.

This general format can be used for any number of messages. The file would consist of N+1 rungs for N messages. I show the first rung. The next rung is typical of message rungs 2 through N. So it will be repeated, with modifications, as many times as needed. The last rung tests that the final message is done and then reset the control bits so that the first message starts again.

In each subsequent middle rung the conditions test that the previous message has started and it has either completed, errored out or was bypassed. If so then it starts the next message. Note that each message gets its own message control structure.

As I said, this works for us. By the way, when we create the middle rungs (for messages 3 - X) we DO copy and paste from the previous rung. ALL the elements in the rung must be modified but most of the bit references just get changed to the next bit in line. The next Message entry is also set. It is then 'setup' for the message information for this particular message. It actually goes rather quickly.

I have twelve different message files within the project and no looping.

Does your logic ensure that one message is complete before beginning another?

3 messages transmitted at one time and the fourth is waiting in a buffer. The rest are waiting for a done bit.

Interesting. I have always used logic to ensure only one message is active at one time (as in my example). I can track progress easier that way. But, whatever works ...

rbepple said:

3 messages transmitted at one time and the fourth is waiting in a buffer. The rest are waiting for a done bit.

Click to expand...

A quick test to see if this is the problem, disable all but one message and see if it cures the problem. Then add one at a time.

I thought the same thing but i use the same program on a different network with nothing but slc 5/04 plcs and it works fine and will read as many element as i want successfully.

Well..... I hate to say it but I feel defeated and I think I am going to have to use some government money and replace the ML 1200 PLCs with SLC 5/04s!

If you're doing any sort of serial communications, the best money you'll ever spend is on an EZ-Tap:

http://www.stratusengineering.com/EZTap.html

I think the first essential question is "is the data arriving in the response packet". A captured set of serial data will answer that question unambiguously.

The second question is "why isn't that data going into the registers I expect".

And that's a question that can only be answered by direct examination of the program and the system. If you need somebody who can sign a federal nondisclosure agreement, hire one from RA or from one of the Tri-Cities integrators. Walt at CES Pasco can help you find the right guy.

If you can show me a MSG instruction that completes successfully but delivers the wrong number of bytes to the destination data table, I'll eat a pound of kimchi. It just doesn't happen.

Ken Roach said:

If you can show me a MSG instruction that completes successfully but delivers the wrong number of bytes to the destination data table, I'll eat a pound of kimchi. It just doesn't happen.

Click to expand...

There speaks a man of experience, and I second his opinion, although I don't like kimchi, so i'll settle for a bottle of good red wine !