Controllogix processor tag names changed problem

[Glenn Mac]

HI all.
We have found a weird issue with our 1756-L72 controllogix processor.

After it was opened the other day and closed, (we guess this is when it happened because of the automatic backup timestamp) the local data tag names changed for some reason. and example is BR1:11:1.Data.1 became BR1:11:1.point_1.
the tag also does not show the description linked to it. The system is all running fine with no errors which is even weirder as some remote devices get information and still work.

When we open our saved project file everything is fine, but when we go online we are prompted to upload due to program differences and and this is when we see the difference. We are going to download the original back into the processor on Saturday.

I am unsure if this is actually in the processor or something in my studio 5000.

I have attached images to show what I mean

[JeremyM]

What version of Studio?

I encountered this junk (alias tags on rungs being auto-magically replaced by the aliased I/O point's name - how useful!) on v24. Never saw it again on v29.

[Glenn Mac]

Hi Jeremy

It is :V28.00.00 (CPR 9 SR 8)
Built on: 11/10/15 19:26:17

[jstolaruk]

First example is how the s/w handles a device that it doesn't have the eds definition installed for; it doesn't know what it is so it treats it as generic. The second time the s/w uploaded, it found it had the eds installed and was able to apply the eds definition.

[Ken Roach]

This is probably related to how Aliases work, not EDS files or Studio 5000 revision levels.

When you upload from a controller without a matching project file, it's well known that you won't get the Tag Descriptions or the Rung Comments.

What's less well known is that because Studio 5000 is creating the Tag Database from scratch, it "collapses" Aliases and reads the base tag.

I'm most familiar with how this works if you have multiple levels of Aliases, where an Alias tag points to another tag which points to a Module-created base tag.

I'm not certain what's happening here. I think to investigate it, we should start with a description of the I/O platform whose tags were "converted" in format.

[jstolaruk]

The second example doesn't show as an alias so that can't be it. I've confirm what I described.

[Ken Roach]

Interesting... I wonder if it's a matter of a Module-Defined Data Type that came from an EDS-Based Module Profile.

I can't figure how it would happen on the same computer, though; EDS files and Module Profiles should be registered no matter if the user is uploading into an existing project or an empty one.

It's interesting that the Tag Descriptions for the non-Module Defined tags like BR1_B27[x] appear to have been retained. Maybe there were never any Rung Comments. That's consistent with the "upload to correlate" step.

[jstolaruk]

A project I was working was started by an associate and they used some EDS files for some Atlas Copko nut runners. I uploaded the program directly out of the processor and I got generic modules in place of the nut runners. I was able to edit online just fine. I was NOT able to download from an offline file until I resolved the missing EDS file issue. When I later installed the EDS file, everything came into place.

[Glenn Mac]

Originally Posted by Ken Roach

This is probably related to how Aliases work, not EDS files or Studio 5000 revision levels.

When you upload from a controller without a matching project file, it's well known that you won't get the Tag Descriptions or the Rung Comments.

What's less well known is that because Studio 5000 is creating the Tag Database from scratch, it "collapses" Aliases and reads the base tag.

I'm most familiar with how this works if you have multiple levels of Aliases, where an Alias tag points to another tag which points to a Module-created base tag.

I'm not certain what's happening here. I think to investigate it, we should start with a description of the I/O platform whose tags were "converted" in format.

We use a common project file stored on our network server, all pc's that we used to check it after this happened had the same issue, load the project file it looks fine connect to plc and it prompts for upload, do upload and tags are changed to the point type.

Interestingly, when we used a backup that was created just before the last "save and close", it was fne. We used that backup to upload to and then saved it as our new master project and the issue resolved itself.

I think to investigate it, we should start with a description of the I/O platform whose tags were "converted" in format

I am unsure if what you mean here? I think the tags were edited in as the program was developed, I don't think it was an import from excel for example


Thanks for all the answers so far, I am continuing to investigate based on the replies to date

./scratch head

[Ken Roach]

I'll re-phrase; what are the I/O modules whose tag format changed ?

Are they 1734 POINT, or 1794 FLEX, or 1769 Compact or 5069 Compact ?

The type of module might help us understand the structure of the underlying Module-defined Tags.

I'm sure an A-B tech support engineer would recognize them, but I haven't had to focus on low-level addressing in a while and I can't say what they are.

[Glenn Mac]

They are 1746 modules on remote racks.
Below is an interesting picture of when I expand the controller tags, it shows "dual" tags for the module.
It does not do this for the 1769 main rack modules

[VAN]

This is why you have an input routine and an output routine that maps to the IO.

NEVER use direct IO in code. If you have to I suppose... but make it a bit that turns on another bit in that routine so you can map the IO. This would be a non-issue.

[Geoff White]

If you have more than one alias for a tag it will merge them all to one if you upload.

[Ken Roach]

Van, I don't think it's a functional issue. The I/O should still run fine, even though the address points to an alternate tag.

Glenn, thanks very much for the additional information. I think you've encountered an uncommon issue with an uncommon implementation.

My guess (and it's only a guess) is that this is an issue related to how stacked Aliases work, but with the extra twist of a special Module-defined datatype for the 1746 modules in the 1747-AENTR adapter.

The 16-point discrete input module datatype is actually 8 bytes long:

ConnectionStatus is a BOOL that takes up 4 bytes.
Data is an INT that takes up 2 bytes
Point_0 through Point_15 are BOOLs that take up 2 bytes.

The "Point_x" BOOL tags aren't a BOOL[16] array, but rather individual points. I think that's similar to how the discrete points are addressed in 5069 series I/O modules, but I have not worked with those yet.

So they aren't "overlays", but they aren't "really aliases" either.

The resolution of the issue might boil down to "use the BOOL tag addressing to avoid this upload database issue". It would be interesting to see what RA technical support makes of it.

[VAN]

Originally Posted by Ken Roach

Van, I don't think it's a functional issue. The I/O should still run fine, even though the address points to an alternate tag.

Oh, the code should be fine I was thinking more along if you have an HMI that was referencing the inputs. (Although find and replace would fix it on the HMI.)