MSG instruction from Compact Logix 5000

[Ones_Zeros]

I have two 1769-L32E Compact Logix PLC controllers.
One the remote plc I have two msg instructions
setup to read two separate ESD tags from the Main PLC.

This seems to work fine, I had some questions on
making sure I had this properly setup.

On the remote PLC after the msg instructions read
the two ESD tags from the main plc the .DN bit
stays on. I was just concerned that if the state was to
change on the main plc ESD tags that the remote plc
wouldn’t see this change.

For example anytime that the two ESD tags where
to change in state I want the remote plc to see this
change for both tags.

Do I need to do anything differently on the two msg instructions?
Is it normal for the .dn bit to stay on or do I need to have this
on a timer so it would reset the .en & .dn bits
of the msg instructions?

I appreciate the help and guidance

Thanks

 

[thingstodo]

I have two 1769-L32E Compact Logix PLC controllers.
One the remote plc I have two msg instructions
setup to read two separate ESD tags from the Main PLC.

This seems to work fine, I had some questions on
making sure I had this properly setup.

On the remote PLC after the msg instructions read
the two ESD tags from the main plc the .DN bit
stays on. I was just concerned that if the state was to
change on the main plc ESD tags that the remote plc
wouldn’t see this change.

For example anytime that the two ESD tags where
to change in state I want the remote plc to see this
change for both tags.

Do I need to do anything differently on the two msg instructions?
Is it normal for the .dn bit to stay on or do I need to have this
on a timer so it would reset the .en & .dn bits
of the msg instructions?

I appreciate the help and guidance

Thanks

The done bit comes on when the message instruction completes and stays on

When the message instruction transitions ON again, the done bit goes off, the EN comes on ... until the message completes again.

It would be easier to read your code, in my opinion, if you had one message instruction in the remote PLC, and used the done bit to copy the ESD tag to the other place in the PLC that you need to use it.

 

[Ken Moore]

You could use a timer, or you could just put a NOT .DN bit in the ladder before the MSG instruction. Then every time the MGS completes, the done bit will "break" the enable, and the instruction will execute next scan.

Why two MGS, why not one that gets all the information? You could create a UDT with all the information on both PLC's, and then read the UDT from 1 to 2.

 

[Ones_Zeros]

Could I send a copy of the code for you to look over?
I’m no expert and maybe I could learn from you

I want to make sure that I’m using the msg instructions
Properly and make sure there checking the main plc
Correctly for the ESD tags.

Thanks

 

[BachPhi]

If you want the remote PLC to read the ESD tags from main PLC when the tags changed, so why not push it to the remote from the main PLC instead?

If ESD_tag not equal last value then do MSG write, and move its value to last value.

 

[Ones_Zeros]

Once the msg instruction stays done after it
Has read the tag valve from the main plc
Into the remote plc.
Will that msg instruction keep reading the value from the main
Plc on the next scan while it’s .dn output is true?

I haven’t used the msg instruction a lot
Can I get some examples of the proper usage
Of this instruction?

Thanks for helping

 

[daba]

You *could* produce & consume these tags...

Advantages...

Once set up, there is no code needed, no timers, nothing.
You can containerise the tags into a UDT that contains a special "CONNECTION STATUS" member, that tells you that the remote PLC is running and the connection is healthy. That guarantees the data you see is 100% valid. You are, in effect, making the remote tag part of the I/O of the consumer PLC, just the same as an Input tag from an Input Module, for example.

Disadvantages...

You need to make offline changes to the tag configurations that will force a download, or you could create new produce/consume tags, and just retire the old ones.
You have to put the Producer PLC into the I/O configuration of the Consumer PLC, that can be done online.

If you want to go down this route, I'm certain there's loads of people on here can help get it set up.

 

[BachPhi]

If you want the remote PLC to read the ESD tags from main PLC when the tags changed, so why not push it to the remote from the main PLC instead?

If ESD_tag not equal last value then do MSG write, and move its value to last value.

I am sorry I did not see your private msg earlier, but in case you still needed and for benefit of others that may needed

 

[celichi]

I would recommend you do reads, instead of a read/write.

This way a search will show where the data is coming from.

Keep in mind, that that msg read can be done/complete on a PLC that is in program mode, hence the need for a heartbeat that required both PLCs to be in RUN mode.

I have seen bad things happen because PLC was placed in program mode (stale data).

 

[daba]

I would recommend you do reads, instead of a read/write.

This way a search will show where the data is coming from.

Keep in mind, that that msg read can be done/complete on a PLC that is in program mode, hence the need for a heartbeat that required both PLCs to be in RUN mode.

I have seen bad things happen because PLC was placed in program mode (stale data).

Which is why I recommend Produced/Consumed tags containing the CONNECTION_STATUS member.

No heartbeat required, the connection status is updated by the consuming controller based on the, dare I say it "connection status"...

The two BOOL flags provided by the "Connection Status" member of the UDT are ...

Connection Healthy
Producer is in Run Mode


What more do you need to ensure the integrity of the consumed data ?

 

[celichi]

Which is why I recommend Produced/Consumed tags containing the CONNECTION_STATUS member.

No heartbeat required, the connection status is updated by the consuming controller based on the, dare I say it "connection status"...

The two BOOL flags provided by the "Connection Status" member of the UDT are ...

Connection Healthy
Producer is in Run Mode


What more do you need to ensure the integrity of the consumed data ?

Nothing for data integrity, but lacks flexibility.

I think Produce Consume is solid as well, but having to make changes offline and download takes me back to MicroLogix. .

In my experience (I have used both extensively), msg reads accomplishes non-deterministic communications for my purposes.

Bottom line, I think it depends on your application.

 

[OkiePC]

For constant data transfer over a solid Ethernet connection, Produced/Consumed is the way to go. Don't put them on systems that rely on radio links as a general rule. With radio modems, I normally have logic that allows me to enable and disable the communication to each node as well as vary the timing programmatically.

I got called in to work on a very complex radio telemetry system that the designer used large produced tags over radio links in several places. There were over 40 nodes, two concentrators, and both UHF and 900MHz FHSS modems at the concentrators where they had the UDTs mapped back to the main plant. One of the radio links was flaky and it turned all the comms into a complete fuster cluck. As a trial, I replaced the Produced/Consumed tags with MSGs and then was able to get half their system working somewhat so I could see where the radio problem really was. I ended up replacing a lightning arrestor and reversing the changes made by others (they'd swapped radios in two places with units set up incorrectly), and made it limp along well enough for me to back away slowly and head back to OkieLand.

 

[daba]

For constant data transfer over a solid Ethernet connection, Produced/Consumed is the way to go. Don't put them on systems that rely on radio links as a general rule. With radio modems, I normally have logic that allows me to enable and disable the communication to each node as well as vary the timing programmatically.

I got called in to work on a very complex radio telemetry system that the designer used large produced tags over radio links in several places. There were over 40 nodes, two concentrators, and both UHF and 900MHz FHSS modems at the concentrators where they had the UDTs mapped back to the main plant. One of the radio links was flaky and it turned all the comms into a complete fuster cluck. As a trial, I replaced the Produced/Consumed tags with MSGs and then was able to get half their system working somewhat so I could see where the radio problem really was. I ended up replacing a lightning arrestor and reversing the changes made by others (they'd swapped radios in two places with units set up incorrectly), and made it limp along well enough for me to back away slowly and head back to OkieLand.

I think I have highlighted the important points.

Large : A single produced/consumed tag can be a maximum of 500 bytes of data, and will be transmitted by the producer and received by the consumer as one "packet", in one I/O exchange, in one "System Overhead Time-Slice" (SOT). You can be assured that the data consumed has not been "split".

A message, on the other hand, can transfer a data size larger than 500 bytes, but will be split up into multiple packets, which may span multiple SOTs. Buffering the data to ensure integrity will be essential.

Many : Will surely eat into the I/O exchange bandwidth. Coupled with "Large", data buffering will also be essential.

Large AND Many : Make your Produced/consumed tags as large as possible to conserve network bandwidth, use multiple tags if necessary, and use the configuration to set the RPI's to as long as is practicable to the application.

Messaging involves a great deal more communications than produced/consumed data transfer, especially if the "connections" are not cached.

The ultimate aim in any system is to get your project data in the fastest possible way, with the minimum coding effort, and have a guarantee of its integrity.

Produced/Consumed gives you all of that.

 

[mike3475]

check this:

 

[daba]

check this:

****ty article full of ads, and adds nothing to the discussion, just tells you how to configure either Messaging or Produce/Consume, no real discussion of the merits of either method of data transfer .....