ControlLogix tags not visible

I have several ControlLogix connections that are operating normally. Once device, though, is giving problems. I can browse to the device, global tags, and I can see the “first tier” of some tags. Under that tier, we have UDT tags that do not show. I know that they exist because I have been accessing them from another product for 4+ years. Knowledgebase article 147 shows a tag properties dialog with an option for setting “External Access”. Looking at RSLogix 5000, the Tag Properties dialog does not have that option. The Logix 5563 device is rev 16. That may be the problem. Do I need a later revision or does anyone have a suggestion for revealing the tags?

What version of Ignition do you have?

Is that the only rev. 16 clx you’re using?
I’ve had to update the rev on those before because of spotty comm to a PanelView Plus.
I don’t remember the details exactly, but as I remember it, the way that rev 16 handled messages was not quite right.

Whether or not that’s the problem, it’s worth looking into.
But be sure you have the firmware updates for the other modules before you update the processor.


We are running Ignition 7.5.2. I believe all our other ControlLogix (about 5 devices) are on version20.
From our current device, which I am trying to replace with Ignition, the tag looks like XCplr_Hood1.XCplr_Hood1.MSG088.Batch_ID. Since that device is a module in the ControlLogix Chassis, it reads the processor across the backplane and can only “see” global scoped tags. What I can see with the OPC Browser is [Line400].Global.XCplr_Hood1 as a “folder”.

I am checking with our Server Support group about installing 7.5.3 to see if that affects the problem.

Oops, forgot to note that upgrading that particular ControlLogix from ver 16 to 20 is not a trivial task. It is running in an environment with RSBatch, RSView, and FactoryTalk. I believe they all have to be at a compatible version. I am checking with Rockwell Automation on that point.

I talk to a couple v16 processors w/out a problem. Both ControlLogix and CompactLogix.
What ethernet module are you using w/ the CLGX? 1756-ENBT , EN2T ?

Do you have RSLinx Professional?

Because you’re using a different communication architecture from your previous device, it would be good to cut the possibilities in half by doing a little test:

In RSLinx, browse to your PLC.
Then on the menu, select DDE/OPC and go to Topic Configuration. If your PLC is not in the topics list, add it and make sure it’s pointed to the right path.

Open the OPC Test Client (from the start menu) and connect using RSLinxOPCServer. Add a group and try to add an item. If you can browse online to your point using the test client, then the problem is most likely on the GUI side. If not, AB tech support is your best bet.


The old device used a proprietary connection via the backplane of the ControlLogix Chassis.
With Ignition, I’m using the OPC-UA server to connect to the ControlLogix via the ENBT ethernet module.
We are trying to stay with the OPC-UA server, but using a connection through RSLinx is an option we are looking into.

The External Access feature was introduced in v18, I think, so that’s not the problem.

It sounds to me like Ignition is having trouble browsing the structure of the UDT. Maybe there are overlays, or nested UDTs, or something that Ignition hasn’t encountered before.

I agree that the RSLinx Classic OPC Test Client is a good browsing test.

I’m revisiting the XCoupler myself… I’ll be interested to see if there’s another development generation of that product in the pipeline at Automation Fair 2012.

Can you access the tags if you type the path in directly? Or does that fail as well.

We got a notice that the xCoupler was going out of production in 2009. We started comparing systems to find a replacement. I had several problems with the xCoupler (no expressions, no run a schedule while a trigger is high, etc) I created several stored procedures to workaround those problems and had PLC code developed to handle some of the problems. Our major limitation was the 250 triggers per minute. We had to split our transactions and buy additional xCouplers. Also, the xCoupler replacement, tManager, was rated at 25 triggers per minute. RSSql and Ignition solved a most of the problems. Because of scripting with Python, Vision for HMI development, and licensing, we selected Ignition as our replacement.

And, for Dravik, I tried to type the path in directly, and still get an “unknown” quality flag. We are testing some old fashioned, synchronized, arrays to replaced the UDTs. If that works, it will take care of my last 64 problems and we can complete our migration from xCouplers to Ignition.