RS500 msg instruction questions

hello,

I'm working on a problem concerning an MSG instruction in RS500 using a 5/04. I'm not exactly sure how to describe what it is i am communicating with, the best I've been given is a software package called 'factory link'. the message itself is set up for a PLC5 write.

Essentially the message is enabled when any one of the bits in the data table address goes true. so for example, data table address is N7:164, if N7:164/3 happens to be true, we enable the message. The /3 bit will only be on for one program scan as the logic setting it true is controlled with a one-shot.

The problem i am having is that it seems like we loose track of some of the information in the transfer of the message. i put counters on the EW (bit 10), EN (bit 15) and DN (bit13) and over time i get more enabled/waiting and done counts then i do message enabled counts. Its as if i'm sending more messages than i am enabling.

what this causes is more machine start/running counts than machine stop counts (N7:164/3 is machine running, N7:164/4 is machine stop) and the data basing in oracle and so on and so on gets messed up and i get blamed for it in production meetings, wahoo...

any input would be great!

It's definitely not possible for you to send more messages than you're enabling, so let's set that idea aside.

Post a screenshot of the logic that controls the MSG instruction. If you can post a zip file of the *.RSS program file itself, even better.

I've seen dozens of instances where folks made incorrect assumptions or bizarre control-bit logic that caused the MSG to work in a way they did not expect, so I always insist on seeing the logic before commenting.

i completely concede that i am bonkers for suggesting more writes than enables, so i know somethings flawed here...

hopefully enough is copied in and i did the zip correctly...

hanlonmi06 said:

i completely concede that i am bonkers for suggesting more writes than enables, so i know somethings flawed here...

hopefully enough is copied in and i did the zip correctly...

Click to expand...

What Ken ask for was the whole program ( the real one), not what you think he needs to see. The problem may be somewhere else in the program.

Is there some reason you can't post it?

I'm not entirely sure where the line gets drawn with my company's privacy policy. we have equipment and programs that a lotta people would probably love to get their hands on so im not exactly comfortable posting up the whole program.

it would take a minute, but i'm sure i can delete the stuff i think is the issue and post up a vast majority of it...?

One thing that jumps off the page is that there are two MSG instructions that use the exact same Control block (N7:165, length 14).

The term "major no-no" seems a little childish but it's all I can think of right now.

I understand what the programmer had in mind: the second MSG is triggered if the first one generates an Error. Either this issue or the clearing of the MSG counters while a couple of messages were pending replies explains the "more /DN then /EN" effect.

One essential rule to understand is that MSG instructions execute once on a false-to-true transition of the rung pre-conditions. The exception to this is the "Continuous Mode", which this program seems to be attempting to use.

Continuous Mode is like having a rifle on full-auto. It's a lot easier to control your fire in semi-auto mode, rather than holding down the trigger and attempting to operate the selective fire lever. You don't have to worry about running out of lead and brass in the controller, but if you want to get a handle on individual message transactions, Continuous Mode shouldn't be considered.

I'll take a further look at the logic to see if I can suggest a better way.

i noticed the same about the second message.

I've read around on a few posts, some peoples comments in here are far more funny then id ever have imagine...childish... i saw a posting about a garage door question by guest: faux Q...that was kind of annoyingly funny.

so anyhow, if this is enough to work off of, cool. if not, i am trying to whittle down a version that has all the ladders and addressing needed to complete the picture.

Can you clarify 'pre-conditions'? i get the false to true transition, but im not sure i follow the pre-conditions component.

i was reading the help files, i thought i read that the msg gets queued and then actually executed at the end of the program scan? did i interpret that correctly?

you can see i added a counter on the 'error' message and ive yet to see one. the N46:90/10 acts as a heart beat in some other logic that will stop the line if this comm link fails. is the second msg instruction redundant and more importantly causing issue such that it can be removed? i/we are willing to try just about anything here. this logic has been in for years and years now and i think its fundamentally flawed but it flew under the radar until the bean counters wanted every second accounted for.

That logic had all the hallmarks of "**** around until it works".

What I mean by "pre-conditions" is the logic to the left of the MSG instruction. A better term might be "rung logic state".

An empty rung with nothing but an MSG is an "unconditional" rung. The solution of EQU or NEQ or XIC or XIO instructions to the left of the Output instruction(s) constitutes the rung's logical state.


Any communications link can fail, so there ought to be some logic to re-try in the case of a genuine communication failure, or to detect the communication failure and take action on the PLC side.

I'm attaching a simplified bit of logic that detects any of your communication events occurring and sends a message just once.

your cracking me up...

OK, gotchya on pre-conditions, just a verbiage thing on my part.

If there is a complete failure after a 30 second heartbeat (via this message) the line will be told to stop, so i think that's covered.

What i see is:

deleting the second msg altogether
copying the word being written into a storage point (any address)
detecting off of the two error bits if we need to resend that storage word

Am i correct?

EDIT:

i re-read your post and re-read the logic...not re-writing the storage word but simply making it a condition to allow the message rung to go true again.....

also, you're implying that the original way it was programmed could allow multiple message writes?