DHRIO - Ethernet Bridge -Read Message From SLC DHRIO Routing Table

Hello Everyone,

I am looking for some help on setting up a routing table on a DHRIO Module or perhaps the message configuration is wrong.

I am trying to get a SLC (Talking to a DHRIO over datahighway) to "read" a message from a controllogix plc through another controllogix plc basically setting up the DHRIO and Ethernet as a Bridge.

See "General_Overview.png" Attached for an idea of what I am trying to do.

I have setup the SLC "Passthru Link ID" to 2 (as well as all other nodes on the same datahighway network).
I also Set the DHRIO Module configuration to Link ID 2 as well.

See "SLC_Channel_General.png" to show passthru link id setup

I have also included a copy of the current Routing table in the DHRIO
"DHRIO_Cfg_Route.png"

"RSWho_Enet_Browse.png" shows the network.

And of course the message configuration file in the SLC
"SLC_Msg_Config.png

Also
I Have included
"DHRIO_Cfg_Chn.png" to show its setup for 0

"SLC_Channel_General.png" to show how the Datahighway is configured on SLC

"SLC_Map.png" To show how controllogix SLC Mapping is setup

"RsWho_Browse.png" to show the datahighway only in RSWho

and

SLC_Msg_Logic.png" to show how the Message command is being called.4


I already know I could use ControlLogix to "Write" a command to SLC without a routing table but I don't want to do this.

I have been through a bunch of examples and setup from Rockwell.

Thank you,
Dave

Thanks for all of those details !

Everything you've done looks correct to me.

Did you cycle power to the 1756-DHRIO after re-configuring it ? What about to the SLC-5/04, if you changed its DH+ channel Link ID (though the default is 2, which you are using).

What error message does the MSG instruction give you in the SLC-5/04 when you execute it ?

Hello Ken,

I figured that I would try provide all the information that I "know" is or could be relative to this.

I have not power cycled the DHRIO Card so I will try that.

I can't remember if I changed the link ID or if it was already set for 2 to be honest. I did change some of the Link ID's on other processors but they required a transition from remote run to program mode and back so I assumed.....here we go again.....that any changes would have taken place then. I will have to try schedule a shutdown to power cycle Node 01. Or maybe the utility company will do it for me. I will look back in previous revisions and see if its actually changed.

I have tried the same message / configuration on a PLC 5 with same results. Which I can power cycle easier.

No error message given....also no data received.

In the DHRIO configuration there is an option to set a LINK ID for BackPlane (very top of DHRIO_cfg_Route.png)

In most examples from rockwell this is not set. I have set it and also left it undefined and doesn't seem to make a difference.

Thanks,
Dave

Does the DN bit come on in the message instruction? I'm wondering if the one shot is the issue. I tend to latch the message instructions on using "EN is true, DN is False, ER is false" so they get a chance to execute.

Is the "control slot' correct address on the DHRIO? you have it on slot 0 but I thought should be slot 3, also in your overview you have both CLX racks labeled as slot 0... just a WAG

MSG trigger logic

It's great to get a bunch of eyes on the same documents; I often overlook or assume things.

I also would try to use a manual trigger before the MSG instruction instead of relying on Bit 0 of the Seconds system status register. In general, a MSG instruction will always return a /DN or an error code, and they only execute on the rising edge of the true rung conditions that precede them.

Also, on the SLC-5/0x controllers you can disable the Real-Time Clock by writing all zeroes into the registers, so that feature doesn't always run. And Bit 0 of the RTC.Seconds on a MicroLogix doesn't change at all, so I prefer to avoid using it as a standard method to prevent that logic from migrating to MicroLogix programs.

When you use a repeating timer, or a bit in the S:24 free-running clock, I also put an XIO with the /EN bit before the MSG, so that the clock can't trigger a bunch of Messages that stack up in the processor's buffers when a MSG can't get through and is waiting to time out.

Ken Roach said:

[...]I also put an XIO with the /EN bit before the MSG, so that the clock can't trigger a bunch of Messages that stack up in the processor's buffers when a MSG can't get through and is waiting to time out.

Click to expand...

I was once in a meeting at JPL, where there was a discussion about the "partition" value in a timing protocol, to account for discontinuities in a spacecraft's clock with respect to continuous time: it could be reset, or commanded to jump a few seconds to offset a sequence in time without re-programming the entire sequence, or it could simply rollover (Vee-Jer).


And the engineers on the mission said that would not be needed, that the clock on this particular spacecraft would never be reset, and it had enough bits that it could not rollover before the mission ended, so the partition was not necessary.



I said "I don't know if you all noticed, but I am wearing a belt and suspenders today. We are going to use the partition."


Heh, it looks like Ken wears a belt and suspenders as well.

Hello Everyone,

So the Power Cycle on the DHRIO seems to have solved my issues. ARGH thats crazy.


I will forsure be changing the conditions. I was not aware of the SLC having the real time clock disabled, not normally an issue as I would have a OneSecond Pulse off a timer but good to keep in mind for sure.

There a whole bunch of small messaging that needs to take place across multiple processors but datahighway wiring is a mess and message writes and reads all going to the same address its a mess.



I'll have to try dig some suspenders out of the closet...if I have any.

Control Slot in DHRIO Routing Table as far as I know is the "pointer" to where Local DH messages are sent. Both ControlLogix Processors are in Slot 0.


The Message was toggling between EN and DN with no errors so I figured the One Shot wouldn't be an issue.

Thanks Ken and Everyone for your help

Dave

You should monitor for message failures and adjust the messaging rate based on a number of drops over a given period of time. DH+ is notorious for comm issues. I know controllogix allows you to reset messaging without the need to cycle power. That's a very powerful tool; you should be able to do something similar with the SLC....
though in this case if the messaging wonks out, I'd reset both the SLC messaging and the DH+/RIO.

Though... why not just use the intermediary controllogix process handle everything? That way you'd have more tools at your disposal, or consider simply writing the message from the target controllogix processor? It's easy enough to drill through with minimal hassle.

I'd have a lot of questions and concerns regarding reliability before going too far down this rabbit hole of code.