Rslogix 500 Msg Instruction

Dani610

Member
Join Date
May 2018
Location
Adelaide
Posts
33
Hi All, this forum has been of a great help for me in learning.

i have two problems

1- I have setup an alarm so i want to calculate the number of times the alarm goes on for that i can use a counter but in counter i have to set a specified value upto which it can count so what is a better approach

2- below I have attached a pic of my output window i am using two ML 1400. Input is given at plc1 and output is at plc2. They are connected via ethernet switch now when i unplug the cable of plc1 the output goes off with error bit being enabled on message command but when I plug the cable in again the error bit stays on and i have to go offline and then online again to turn output on. what is the solution to that when i plug the cable in again the program starts working again.

thank youd.jpg
 
The logic driving your messages is depending on the message either not being enabled or being in an error state in order to trigger it.

The error bit will go true after the timeout specified by the channel configuration. If you want the error to occur sooner, you can either change the channel configuration timeout setting or manipulate the MTO word for the messages. I have a couple of applications in which I wanted the error to occur if a remote node could not be reached in a maximum of 5 seconds, so for those nodes, I write (MOV) a constant of 5 to the MSG control element MTO words. This is done in a routine that runs once on startup for dozens of MSG elements. In your case, it would be MG10:0.MTO and MG10:1.MTO. If those values are set to a smaller value than what gets assigned based on the channel configuration, then the channel config can be left "normal" for other connections and the error will occur sooner.

I would take a different approach to triggering the messages and monitoring the status.

Some folks ignore the message error bits and simply use a self resetting timer to trigger them once per second or so. This can work in many situations but can also cause a situation where the channel buffers get filled up if there are many errors, so my preference is to always wait for a done bit or error bit before triggering the next message.

I have seen some programs that use separate timers to manipulate the TO bit (turn on the timeout bit through ladder logic) to speed up the normal error mechanism of the message. This works well, but if you have a program with dozens of messages, you can end up with a boatload of extra timers and associate logic to make this happen for all of them.

Another thing to consider is what happens not only when the ethernet connection "goes away" but what if the PLC on the other end is faulted but still responding to messages?

I will normally read a "hearbeat" value as part of the block of data. If the remote PLC is running, it constantly changes the heartbeat address (For example MOV S:4 "Free Running Clock" to N10:9 "Last word of data to master PLC"). The master PLC will compare that hearbeat value to a copy of it taken on the previous scan. If the values remain equal too long, the remote PLC has either stopped communicating or stopped running. If the data changes frequently enough to keep the timer from getting done, you have proof that not only are the messages working, but that the remote PLC is actually executing logic.

Tomorrow, when I am at work, I can post some code snippets of the way I set up MSGs in a Micrologix 1400.
 
The logic driving your messages is depending on the message either not being enabled or being in an error state in order to trigger it.

The error bit will go true after the timeout specified by the channel configuration. If you want the error to occur sooner, you can either change the channel configuration timeout setting or manipulate the MTO word for the messages. I have a couple of applications in which I wanted the error to occur if a remote node could not be reached in a maximum of 5 seconds, so for those nodes, I write (MOV) a constant of 5 to the MSG control element MTO words. This is done in a routine that runs once on startup for dozens of MSG elements. In your case, it would be MG10:0.MTO and MG10:1.MTO. If those values are set to a smaller value than what gets assigned based on the channel configuration, then the channel config can be left "normal" for other connections and the error will occur sooner.

I would take a different approach to triggering the messages and monitoring the status.

Some folks ignore the message error bits and simply use a self resetting timer to trigger them once per second or so. This can work in many situations but can also cause a situation where the channel buffers get filled up if there are many errors, so my preference is to always wait for a done bit or error bit before triggering the next message.

I have seen some programs that use separate timers to manipulate the TO bit (turn on the timeout bit through ladder logic) to speed up the normal error mechanism of the message. This works well, but if you have a program with dozens of messages, you can end up with a boatload of extra timers and associate logic to make this happen for all of them.

Another thing to consider is what happens not only when the ethernet connection "goes away" but what if the PLC on the other end is faulted but still responding to messages?

I will normally read a "hearbeat" value as part of the block of data. If the remote PLC is running, it constantly changes the heartbeat address (For example MOV S:4 "Free Running Clock" to N10:9 "Last word of data to master PLC"). The master PLC will compare that hearbeat value to a copy of it taken on the previous scan. If the values remain equal too long, the remote PLC has either stopped communicating or stopped running. If the data changes frequently enough to keep the timer from getting done, you have proof that not only are the messages working, but that the remote PLC is actually executing logic.

Tomorrow, when I am at work, I can post some code snippets of the way I set up MSGs in a Micrologix 1400.

Thank you for your reply and i will wait for the snips.

All I want to do for now is that when i plug the ethernet cable of plc1 back again the plc2 should start reading the message again rather than i have to go offline and then online again to start reading the msg again
 

Similar Topics

I'm getting an Error code on my MSG instruction that I can't clear. The Error Code Number is d0. Description "No IP configured for the Network"...
Replies
0
Views
844
Is it possible to configure the MSG block (RSLogix 500 / Micrologix 1400) to have a dynamic destination IP adress?
Replies
1
Views
1,516
Hi Everyone i have attached a file below kindly have a look. so the problem i am facing here whenever the binary bit B3 goes on it goes into...
Replies
7
Views
2,369
Hi All, I am new to plc programming. I have created a ladder logic in rslogix 500. Now I want to give input at one plc and get the output on the...
Replies
16
Views
10,953
This tripped me up yesterday, thought I'd share the results of a conference call with RA this morning: There is a change between version 10 and...
Replies
3
Views
3,063
Back
Top Bottom