2 CompactLogix Controllers in the same network

Hello everyone,

I'm using the following controllers in RSLogix5000 version 30:

1769-L33ER
1769-L30ER

They are sending data between each other via consumed/produced tags.

I want to know if there's a bit one controller can produce and the other one consume, that let the consumer know there's another controller in the network.

I would like to know this because they are 2 different machines that behave different when they are connected than when they are working by themselves and in case of data loss due to a bad Ethernet connection I need to take some precautions.

Thank you,

It sounds like you just want each controller to know whether the other is running. Can you setup a simple heartbeat logic between the two PLCs ?

Hello Jim,

Thank you for responding.

I tried to consume an always ON bit from the other PLC, but when I interrupt the Ethernet connection the consumed bit remains active.

Do you have any other idea?

Did you use the status bits as part of the Produced/Consumed tags?

You need to monitor the connection status and clear the data manually if there is an issue. There are many ways to do this. I prefer to increment a number on the producer every scan and compare it to the previous number on the consumer. If the number doesnt change for x seconds, you have a comms failure.

FYI, this same problem exists for every connection to the controller, including the local I/O. Remove an input card and the data will freeze in its last state.

There are three straightforward ways to do this.

One is to set up a Heartbeat, where one bit of the Consumed connection changes state periodically. Use watchdog logic to cause an alarm or action if the value stays the same for too long.

The other two are to read the Connection status directly.

Since RSLogix 5000 v17, there has been an option to create a UDT with a specifically formatted header with the data type Connection_Status, which will reflect the Connection Status of a Consumed tag when you use that UDT as the data type for the Consumed Tag.

Knowledgebase document 60813 (Access Level: TechConnect) describes this in detail, and it should be in the Help file too.

Or, you can read the Module object status of the Producing controller, just like you would with any other I/O object, by using an GSV instruction. Read up on the Module object in the GSV/SSV Objects section of RSLogix 5000 Help.

We have a boiler with two plcs , one for Burner Manager System and the other for Control, between them we have a safety relay that receives a pulse from each plc and at the same time we use produce/consumed tags, just for safety.

widelto said:

We have a boiler with two plcs , one for Burner Manager System and the other for Control, between them we have a safety relay that receives a pulse from each plc and at the same time we use produce/consumed tags, just for safety.

Click to expand...

IMHO the "Connection_Status" member of UDTs produced and consumed between processors is as safe as it can get, especially when you consider relays will have a finite lifetime.

daba said:

IMHO the "Connection_Status" member of UDTs produced and consumed between processors is as safe as it can get, especially when you consider relays will have a finite lifetime.

Click to expand...

Just curious- does the connection status go zero if the producer is in program mode? How long does a connection have to go bad before it notices?

RA Knowledgebase Article 60813 (Access Level: TechConnect) has good details about the feature.

Connection_Status.RunMode = 1 when the Producer is in RUN mode.
Connection_Status.ConnectionFaulted = 1 when the Connection is broken

The UDT subelement reflects the status after 100 ms, or 4x the RPI, whichever is greater.

I like Ken's approach of a heartbeat. It's straight forward and can be done with two lines of code. The link is for setting up a heartbeat when using Spectrum Controls Universal Gateway (not related) but on the first page is an example of using the heartbeat in a Logix processor. Give it a read and it should make sense.

https://www.spectrumcontrols.com/media/2071/gt004d1_gateway-heartbeat.pdf

Firejo said:

I like Ken's approach of a heartbeat. It's straight forward and can be done with two lines of code. The link is for setting up a heartbeat when using Spectrum Controls Universal Gateway (not related) but on the first page is an example of using the heartbeat in a Logix processor. Give it a read and it should make sense.

https://www.spectrumcontrols.com/media/2071/gt004d1_gateway-heartbeat.pdf

Click to expand...

Heartbeats can be troublesome. I know I got bitten a few times.

Say PLC#1 is turning a heartbeat on and off at regular intervals, and PLC#2 is monitoring it. What if it gets in sync ?

Its not such a problem these days with mega fast processors, but it used to be in the days when some programs had scan times over 1 second.

If I were setting up a heartbeat between 2 processors that didn't produce/consume, I would have a "bit-chase", where one PLC maps input to output, the other inverts it. Regardless of any other considerations, those in/out bits will keep on toggling so long as comms is active. There's no timers needed to generate it, you'll just need timers to see if comms has frozen. Simple and effective. In the Logix5000 world I would exclusively use Connection_Status

In the ladder example the data coming from the Gateway isn’t cycling, it’s a constant “1”. The logic works like this:
The receiving PLC is getting a Tag from the sending PLC (call it “HB”). The value of that Tag is “1”. On rung 0 when HB is “0” (setting bit “HB.0” to “0”) the rung is true and the timer starts. When the Tag HB is updated to “1” (setting bit “HB.0” to “1”) rung 0 goes false stopping the timer. On rung 1, when HB goes to “1” setting bit “HB.0” to “1” the rung is true unlatching bit “HB.0” setting it to “0” which re-enables the timer starting the process all over again. This will run as fast or as slow as you want it to depending on how often the Tags are updated and what the timer’s preset is configured for. The done bit of the timer in plcplcplc1’s case would indicate that the sending PLC has not sent the Tag I.E. isn’t communicating. As soon as it does communicate, the timer will re-enable, it’s done bit will go off and you will know that the sending PLC is back communicating. I used this logic in a display I built for AF2018 and it worked like a charm with no false alarms.