Forcing I/O's in logix 5000

[Ron Beaufort]

Thanks for the clarification on that point, Ron.

you’re welcome, Paul ...



to follow up, this is the way I’ve been explaining the concept in the classroom lately - with good results ...

the sketch at the top is the BASE tag (Local:1:I.Data.0) with the signal coming in from the field device ... and we have a confusing assortment of aliases of that tag - and even aliases of the aliases ...



but the good news is that no matter how complicated the path becomes, the whole thing ACTS LIKE the sketch at the bottom ... in other words, we can picture that there is ONLY ONE bit location - regardless of how many “nicknames/aliases” we attach to it ...



so ... keeping that mental image in mind makes it a little easier to see that we actually CAN do forces when an alias of a “real-world” tag is involved ...



IMPORTANT! ... the official book does NOT recommend assigning an alias to an alias as I’ve shown above ... (although some programmers do get caught up in the magic of the moment and do it anyway) ... this is not recommended because reportedly the alias assignments can come “unglued” along the way - which would definitely fall into the “bad” column on the giant clipboard of life ...

 

[JeffKiper]

Sorry Ron

Ron I should know this, but I have slept since you overwelmed me with knowledge. I don't see any good reasons for having multiple aliases. Would or could you point out some reason why to use them or not? I understand why to use a alias but why use multiples?

 

[Ron Beaufort]

Greetings Jeff ...



the point is that you CAN do it - but you should NOT do it ... some programmers (usually young ones) just try pushing the envelop whenever - and wherever - they can ... personally I can't think of a "good" reason to have an alias of an alias - but I have seen in done in a few programs ...



the "official" book says that you should NOT make an alias of an alias ... the point of my post was to show that IF we ever run into such a situation (probably left behind by a previous programmer) then there IS a way to decode all of that malarkey by simply considering that ALL of the aliases in the network “point back” to ONE (and ONLY one) “base tag” ...



the idea is that if a technician is trying to figure out “what hooks to what” at 3:00 am, he needs a way to preserve his sanity - regardless of what traps and pitfalls the original programmer has placed in his way ...



you might remember the “Searches” exercises that we did during the class ... here’s our old friend TALLY - a tagname which was scoped at the ALARM_PROGRAM level ... and here’s his “family tree” showing how he is related (by numerous layers of aliasing) to a lot of other tagnames ...

the main point is that the Cross Reference feature (bless its little heart) can show us how all of these tagnames are interrelated - and most importantly - that they ALL point back to ONE “base tag” ...



so the moral of the story: do NOT make an alias of an alias ... if you do, you might run into trouble down the line ... going further: if you run into an existing situation where someone HAS ALREADY assigned an alias of an alias, then do not despair ... the Cross Reference “Tag Hierarchy” feature will show how the tagnames are interrelated to each other - and may help preserve your sanity by showing that the tagnames in that particular network ALL point back to just ONE “base tag” ...



specifically: if the “base tag” has a ONE status, then all of the alias tagnames have a ONE status ... if the “base tag” has a ZERO status, then all of the alias tagnames have a ZERO status ...



hope this helps ...

 

[daba]

the "official" book says that you should NOT make an alias of an alias ...

Interestingly, Rack Optimisation is one example where Alias Tags do point to other Alias Tags, and those are created automatically by the system.

Example :
Suppose you have a remote chassis on Ethernet, you put the remote ENBT in your I/O configuration, name it "Rem_ENBT", and choose the Comm Format "Rack Optimised".

This will create module-defined base tags Rem_ENBT:I and Rem_ENBT:O.

Suppose you now add an IB32 Input module to the remote chassis, in slot 3.

This will create module tags Rem_ENBT:3:I and Rem_ENBT:3:C.

When you look at the actual I/O data-words you will see they are all aliased to the data-words in the Rack-Optimised base tags.

example:- Rem_ENBT:3:I.Data
alias for Rem_ENBT:I.Slot[3]

so when you create an Input tag called :-
Start_PB
as an alias to :-
Rem_ENBT:3:I.Data.5
then the word-alias fetches the data from :-
Rem_ENBT:I.Slot[3].5

It can be hard to make sense of alias chains, but they can't easily be broken (you would not be able to verify the code).

It can be even harder to make any sense of multiple alias tags pointing to the same base tag, because that does verify and works, but it's a pain to debug and trace code.

specifically: if the “base tag” has a ONE status, then all of the alias tagnames have a ONE status ... if the “base tag” has a ZERO status, then all of the alias tagnames have a ZERO status ...

I always tell people the golden rule : only a base tag holds data. An aias is just a means of referencing a tag by another name, a sort of indirect name.

 

[Ron Beaufort]

Greetings daba ...



here is a screen shot of page 1 in the Glossary of the “official” manual that I mentioned ... most forum members know that I personally place very little blind faith in the “books” - but for what it’s worth, here it is ...

so clearly assigning an alias to an alias can be done - and we know that from experience ...



and here is a shot taken from page 46 of the Glossary in the same manual - which makes us think twice about going merrily down this particular path ...

so being a “hands-on” kind of guy, naturally the next thing I did was download the “Searches.ACD” file (Version 15) into a handy processor - and then I did an upload operation ... regardless of what the book said, the TALLY tagnames all stayed properly connected - so at least in this one instance the note about “chains of aliases” didn’t bite me ...



even so, I still can’t come up with a really good reason to assign an alias to an alias - so personally I try to avoid that type of situation ...



finally, my main objective lately is not to design or to write PLC programs - but merely to help technicians interpret and understand what they’re seeing on their terminal screens ... I think that you and I are on precisely the same wave length here ... which is what I meant to convey with my original sketch ... namely: one little box - with a lot of different names attached - but still only one status ...



party on ...