Triggering MSG functions in Logix500

Hi All. I've set up a send/receive pair of MSG functions. They are on adjacent rungs in the program. I have used the not-DN bits of each block to enable the other (while sending, don't receive and vice-versa). Is this a reliable solution?

Thanks, Steve.

Hi Steve,
What I feel is there is no need to use that interlock based on whether 'DN' bit is set or not. Also, it doesn't seem the professional way because, in your case, you are using only 1 read and 1 write MSG instructions. What in case, you have to add more MSG instructions in future?
What I suggest is you should use the counter. Say, initially the counter value is zero. Then when counter value is zero (Should be the interlock for first MSG instruction), execute first MSG instruction. On 'DN' bit of that MSG instruction, increment the counter by one. When the counter value is '1' (should be the interlock for second MSG instruction), execute second MSG instruction.Increment the counter on its 'DN' bit. and so on..
If your total message instructions used are 'n' then reset the counter if the counter value = n.
Hope, this will be the best way which will be helpful in case there is any need to add more MSG instructions in future.

Regards,
--Rahul.

I use sort of a cascading scheme.
The done bit from MSG 1, triggers MSG 2, The done bit from MSG 2, triggers MSG 3, The done bit from MSG 3, triggers MSG 4,
and so on
Finally the The done bit from the last MSG , triggers MSG 1

To Ken Moore

I noticed that you live in upstate South Carolina.
I am in Spartanburg, most likely not to far from you.
Where are you at?

I've used Ken's method sucessfully on programs with dozens of message blocks, and it works quite well. We also put the error bit in the enable so if htere is a comm loss we dont hang up on a broken link.

I think it is actually easier to follow and modify than your method, Rahul. You simply have to make sure each message block usees the done and error bits from the block ahead, and make sure the bits in the first and last block are properly identified.

Thanks Tom and Ken

no DN, no ER, what's the deal?

Ken Moore said:

I use sort of a cascading scheme.
The done bit from MSG 1, triggers MSG 2, The done bit from MSG 2, triggers MSG 3, The done bit from MSG 3, triggers MSG 4,
and so on
Finally the The done bit from the last MSG , triggers MSG 1

Click to expand...

I implemented the "StaggeredMessages" sample code from the AB knowledgebase, and it works well...

..except..

After a time (days weeks), MSG instructions will hang up, no .DN bit, no .ER bit..and, of course, the StaggeredMessages example depends on one of these bits happening.

The only solution is to delete the MSG instruction, and replicate it with a new Tag for the instruction, with all the same parameters.

The host is a L32E (V19), the MSG target is a 1769-SM2 module talking Modbus RTU.

Can I "flush" a specific MSG instruction?

I have had a similar situation with a SLC and was able to use a TON to detect the condition and subsequently set the TO bit. Working from memory, I think that caused the MSG to error, which in turn moved my cascading sequence along to the next one, but there may have been more to it.

I am not sure it would work identically with a Logix MSG. See what RSLogix 5000 Help has to say about the TO bit (if one exists).

EDIT: BEFORE You use the .TO bit see the known anomalies in this document:
http://support.rockwellautomation.com/controlflash/FirmwareFiles/1756-RN017C-EN-P.pdf

I don't have software at home so I googled to see what might turn up.

Thanks. I was on k.b. already and really didn't see anything that leapt off the page at me.

I've had such issues with the 1769-SM2 that it is my first suspect...its just that the problem LOOKS like its in the PLC.,,... grrr.

Message instructions hang up for various reasons so when using the interlocking logic like described in previous posts I have a timer for each message instruction that will push enable the net message instruction if it does not complete in the set time which is normally higher than what the message instruction would ever need.

This prevents the 2 am call.

So interlock with .DN bits for control and a timer to push it when it gets stuck and I throw in a couter to tell which message got stuck and how many times. I also have a register that records the date when the fault /hang up counter is reset.

Yeah, Kid, I thought of that. Yes, it will prevent the 2AM calls, but I'd really like to resolve this one, without patch-arounds.
I've proved that the errent message really does the read, it just does not report DN or ER, so, in theory, your approach will work. Thanks,