Sign in to follow this  
Followers 0
ASForrest

MSG instruction staging

9 posts in this topic

Hi all, I've got an application where I have a ControlLogix talking to a half dozen other PLC's. Most are CompactLogix, so I'm just using Produced/Consumed tags, but there are two ML1400's, for which I'll have to use a MSG instruction. For each of those PLC's I want to read one DINT (or in the ML, a LONG) for my discrete data, and 20 REAL's (or FLOAT's in the ML). Then I have to write the same amount of data back. In my understanding, this will mean I need four MSG instructions for each PLC. My question is, with 8 MSG instructions, is there a smart way to stage them to create minimum network congestion? A colleague went to a Rockwell training course last year where they showed a couple of different ways of staging them, and the result on the network traffic, and apparently the difference was quite significant. Unfortunately, it seems a lot of it went in one ear and out the other, and he doesn't remember a thing about that. The way I've currently got it set up is that every second, the last MSG instruction is triggered, and all the others are triggered of the MSG instruction after it's .EN signal. So effectively, every second, I read one MSG instruction per scan, for 8 scans. But I'm not sure whether separating them by one scan is enough to achieve what I'm trying to achieve. At any rate, I need to read/write data about once a second, so I guess the other way would be to trigger them all sequentially 1/8 of a second apart. Any thoughts?

Share this post


Link to post
Share on other sites
One time I worked on a project that had 16 MSG instructions. If you look at the Instruction Help for MSG in RSLogix5000, it says "If you want to enable more than 16 MSGs at one time, use some type of management strategy." Such as enable the MSG's in groups. I did this by creating two timers, half the MSG's were enabled when the 1st timer was timing and the other half when the 2nd timer was timing. Also, I made use of the ".DN" bit of the MSG's (this bit is set when the MSG has been transmitted successfully). I did not allow the 2nd timer to become enabled until all the .DN bits of the 1st group of MSG's were set. This strategy worked fine for the project I worked on. The speed of MSG transmission was not really an issue in this project, the important thing was to make sure all the MSG's were getting across. I had to test several different timer set ups until I found the one that worked.

Share this post


Link to post
Share on other sites
I typically only allow only one MSG at a time, the next waiting for either the .DN or the .ER of the previous to be completed. The completion of the last message clears all flags and start the process over. I know they have queues etc but I like to control my own fate.

Share this post


Link to post
Share on other sites
In MSG's that use radio making queueing a bigger factor, I use a mix of the above. I use a timed on second sequencer and monitor how many MSG remain enabled at once, when it exceeds four, I pause the sequence and start a timer, if the timer goes /dn I reset all the MSG bits and continue on. Ideally I would do this for each MSG separately similar to b-carlton's recommendation (which I am currently constructing). but this technique eliminated a long standing stall of MSG when one or more would get held up because the radio couldn't reach its target.

Share this post


Link to post
Share on other sites
I like b_carlton's method. So my only question then is, is the MSG instruction a one-shot? i.e., if the rung in condition was always true, would it execute once on startup and then never again?

Share this post


Link to post
Share on other sites
I'm not sure. FYI here is a manual I found that goes over MSG's in RSLogix5000 (actually Studio 5000, which is what the latest version of RSLogix5000 is called), there are some programming examples in Chapter 2 on managing multiple MSG's. http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm012_-en-p.pdf I went over the manual quickly to look for an answer to your question but did not find anything.
1 person likes this

Share this post


Link to post
Share on other sites
The chapter 2 example seems simple enough. While my messages are mostly in RSLogix this is roughly the same structure as what I do (though they do 2 at a time while I only do 1 at a time.)

Share this post


Link to post
Share on other sites
Looks good to me. And yes, it was in the manual, albeit in very small text in a spot I wouldn't have thought to look for it ;) "Because a MSG instruction is a transitional instruction, it executes only when its rung-condition-in changes from false to true." Thanks guys!

Share this post


Link to post
Share on other sites
One way of "staging" MSG instruction execution is to trigger them in a periodic task. Include a counter that increments each time the task is run (put an OTU of the .CU bit in the routine, or it won't count more than once). Use the counter's .ACC value to trigger MSG instructions on successive executions of the periodic task. Task 1st Run - Counter.ACC = 1 : trigger MSGs 1 & 2 Task 2nd Run - Counter.ACC = 2 : trigger MSGs 3 & 4 etc. RES the counter when all MSGs have been triggered to repeat the cycle.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0