Factory Talk Tag Bit Reference

DamianInRochester

Lifetime Supporting Member
Join Date
Jan 2011
Location
Rochester NY
Posts
1,292
There has got to be a better way than what I have been doing.

Say for example I have a PV+ talking with a SLC5/03 via DF1.

I want to make a Screen that shows the state of the inputs.

I don't want to send over every single input on a separate tag, so I copy the Input status to an N integer in the PLC.

On the FTView end, I create an internal tag called {InputCard3} that points to the N integer.

Why Rockwell decided not to allow you to simply reference a bit of that tag like this "{inputCard3}.5" is beyond me.

So I have been skinning this cat by using these expressions for each instance of my bits.

{InputCard3} & 1 <> 0
{InputCard3} & 2 <> 0
{InputCard3} & 4 <> 0
{InputCard3} & 8 <> 0
{InputCard3} & 16 <> 0
{InputCard3} & 32 <> 0

etc.

There has to be a better way right?
What am I missing?

And yes, you can do bit shifts but this is just bad and probably less efficient behind the scenes.
 
Unless I am missing something you have to type the bit .5 in your example. Tag browser will only show you to word level [in this case] and you have to type the rest. If I am misunderstanding your question just ignore me.
Another example would be if you wanted a B3 bit it would show you B3:0.0 and you will have to type in the rest. B3:0.0/0

Hope this helps and am I close or all wet......
 
If you do a direct reference to the tag, then yes you can manually type in the bit reference at the end for each and every one.

But ......... this means that if you want to look at all 16 bits it requests it 16 times instead of just sending the word once and then parsing the bits on the other end.

For example ....... If I buy 5 things from a vendor, they will send me perhaps 5 invoices. I don't write out 5 checks and make out 5 envelopes and send them all separately. I add them all up, write one check, put it one one envelope, and send all at once.

Even more glaring is when you are for example using the KEP modbus driver. You have to then declare internal tags for all variables. But there does not seem to be any clean way of referencing a sinlge bit in an internal flag.
 
Access the bits directly. RSLinx is smart enough to manage the packets that are requested when it accesses them in the controller. I would be shocked if referencing several bits in the same word in digital HMI tags would cause individual bit read requests to fetch the data even with FT me.
 
So I have been skinning this cat by using these expressions for each instance of my bits.

{InputCard3} & 1 <> 0
{InputCard3} & 2 <> 0
{InputCard3} & 4 <> 0
{InputCard3} & 8 <> 0
{InputCard3} & 16 <> 0
{InputCard3} & 32 <> 0

etc.

There has to be a better way right?
What am I missing?
Well, for a start you could leave off the "<> 0" in each expression. If you just AND the bit tag name with the bit number, if the tag value is equal to the bit number, then the result will be "1" or TRUE. If not, it will be "0".
 
Access the bits directly. RSLinx is smart enough to manage the packets that are requested when it accesses them in the controller. I would be shocked if referencing several bits in the same word in digital HMI tags would cause individual bit read requests to fetch the data even with FT me.

Nothing would shock me in that regard with FT. If I have a page with 32 bits where they were all part of two integers then you would expect the comms to only be refreshing two integers. But I have noticed significant performance delays when pages like this are displayed that led me to believe it was calling for those integers for every instance of the bit reference.

Direct reference still does not help when you have to use another driver such as Modbus where you have to bring them in as internal tags.

I will try and create an eavesdropping setup sometime this week to test the theory and see if it does or not for certain. I've posed the question in the past on this forum and never got any response.
 
Well, for a start you could leave off the "<> 0" in each expression. If you just AND the bit tag name with the bit number, if the tag value is equal to the bit number, then the result will be "1" or TRUE. If not, it will be "0".


I added the "<> 0" to force all evaluations to be either 0 or 1. Otherwise the Multi-State indicator will give an error on all evaluations larger than 1 that are not defined. I could define values for the indicator of 2,4,8,16,etc but that would be even more work than the "<> 0"

For example 0101 & 0100 is 0100 which is decimal 4 not 1.
 
I added the "<> 0" to force all evaluations to be either 0 or 1. Otherwise the Multi-State indicator will give an error on all evaluations larger than 1 that are not defined.
It always worked for me in RSView. I used that method to use a 16-bit tag to contain 16 separate bit tags. Putting the "& BitNumber" at the end means that you only get a 1 if that particular bit is ON. Otherwise, you get 0. I never had any problem with it evaluating to undefined.

For example, the expression "{InputCard3} & 1" can never have a value other than 0 or 1. There is no way it could evaluate to anything else.
 
It always worked for me in RSView. I used that method to use a 16-bit tag to contain 16 separate bit tags. Putting the "& BitNumber" at the end means that you only get a 1 if that particular bit is ON. Otherwise, you get 0. I never had any problem with it evaluating to undefined.

For example, the expression "{InputCard3} & 1" can never have a value other than 0 or 1. There is no way it could evaluate to anything else.

The problem is it only works for the " & 1" case.

If you AND it with 2 it will evaluate to 0 or 2, not 0 or 1.
If you AND it with 256, it will evaluate to 0 or 256, not 0 or 1.

If I want bit 8 of the word I have to AND it with 2^8 = 256.

To be clear, I never said it evaluates to undefined. I said that values above 0 were not defined in the Multi-State indicators I created. Only "states" 0 and 1.

Would love to see an example .APA of your method as I don't remember this working any differently in RSView.
 
I didn't mean to infer a preference for direct referencing, it is a waste of time for all but the Logix5000 controllers, and even then, you need them for alarms and any sort of data manipulation/scaling to be simple.

I have seen a performance degradation any time there are more than about a dozen busy objects on the screen, just flashing colors seems to bog it down pretty badly, even if the reference for the color was common among them all (they all flashed the same colors at the same time).
 
Would love to see an example .APA of your method as I don't remember this working any differently in RSView.
Sure, here is a picture of the second set of 16 derived tags in a project, which pull out individual bits from a 16-bit tag. This particular project has 8 x 16 derived tags like this set. It has been working that way for years. Each tag of "16-bitTagName & X" where X is bit position ONLY produces a value of TRUE or FALSE (1 or 0), because the & is the AND operation which says to AND the same bit positions of the Tag Value bits with the X bits. If they are not equal, the result is 0, same as if you logically AND 1 AND 0, 0 and 1, or 0 AND 0. Only if both are equal (1 AND 1 = 1) do you get an output of 1. It is a lot simpler than you think. Notice that the outputs of all these derived tags are either 1 or 0, ON or OFF and nothing else.

The problem is it only works for the " & 1" case.
Do you think that I went to all the trouble to set this up only to have it work for 1 out of every 16 tags? It works for all of them, the same way as it works for the "& 1" case. Remember that the program is comparing the binary values of only certain bits, not the decimal values of the numbers (even though you use decimal numbers in the expression). The & X part of the expression serves as a mask to prevent looking at other bits in the tag. This method allowed the RSView program to read 128 PLC inputs and create 128 internal derived tags, using only 8 "real-world" tags.

RSView32 Derived Tags.jpg
 
Last edited:
Comparing Apples to Oranges

Do you think that I went to all the trouble to set this up only to have it work for 1 out of every 16 tags?

Do you think that I went to all the trouble to put in all these "<> 0" if it worked without them?


Sure, here is a picture of the second set of 16 derived tags in a project, which pull out individual bits from a 16-bit tag. This particular project has 8 x 16 derived tags like this set. It has been working that way for years. Each tag of "16-bitTagName & X" where X is bit position ONLY produces a value of TRUE or FALSE (1 or 0), because the & is the AND operation which says to AND the same bit positions of the Tag Value bits with the X bits. If they are not equal, the result is 0, same as if you logically AND 1 AND 0, 0 and 1, or 0 AND 0. Only if both are equal (1 AND 1 = 1) do you get an output of 1. It is a lot simpler than you think. Notice that the outputs of all these derived tags are either 1 or 0, ON or OFF and nothing else.

Do you think that I went to all the trouble to set this up only to have it work for 1 out of every 16 tags? It works for all of them, the same way as it works for the "& 1" case. Remember that the program is comparing the binary values of only certain bits, not the decimal values of the numbers (even though you use decimal numbers in the expression). The & X part of the expression serves as a mask to prevent looking at other bits in the tag. This method allowed the RSView program to read 128 PLC inputs and create 128 internal derived tags, using only 8 "real-world" tags.

Lancie,
Look at your expressions. You are ANDing an INTEGER with another INTEGER. When you AND two INTEGERS what do you get? You get another INTEGER. This not opinion it is fact.

But ............ now I understand why it is working for you the way you did it. You declared a whole new set of BIT tags that can only be 0 or 1. When you have a BIT tag and give it an expression the tag will only evaluate to FALSE if the expression evaluates to FALSE. It will evaluate to TRUE in all other cases.

Straight out of the help file:

"For expressions that return true/false values, 1 and other non-zero values signify True, and zero signifies False."

So for example, your "Pusher Manual Extend Pushbutton" expression will always evaluate to either 0 or 8. Since you assigned it to a BIT tag, it interpretted 8 as a TRUE because it is non-zero.

This is completely different from what I was doing. I only made one integer tag and I was putting my expressions directly into the Multi-State indicator. The Multi-State indicator by definition can take on more values than just FALSE and TRUE, so if the expression generates an integer value it retains that integer value.
 
The bitwise operators (defined as &, |, ^, >>, <<, and ~) only work with BIT tags, therefore it will do you no good to use these operators with any other type of tag. Your method only works because you force the result to be a bit value. Mine method works as defined in the RSView manual, chapter 14, "Creating Expressions, Bitwise operators" Note that "&" (the operator symbol for a bitwise AND operation) returns only a 1 or 0.

No, that is for the "logical" operators. Not the "bitwise" operators. You used bitwise operators in your expressions. They return INTEGERS. What good would the >> and << be if they only returned 0 or 1?

Right from the chapter you quote:

"&" "AND" Compares two integers or integer tags on a bit–by–bit basis.


Returns an integer with a bit set to 1 if both the corresponding bits
in the original numbers are 1. Otherwise, the resulting bit is 0.

Look at the top of page 14-14 for examples of bitwise operations.
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/vw32-um001_-en-e.pdf
 
Why Rockwell decided not to allow you to simply reference a bit of that tag like this "{inputCard3}.5" is beyond me.

i know its been years, but the question is still valid. I was searching an answer for the same question, and it is possible access the individual bits.
The bit has to be inside the brackets: "{inputCard3.5}"
 

Similar Topics

The client has an application that when communication between the PLC and the Factory Talk VIEW supervisory fails, the object in the supervisory...
Replies
5
Views
223
What's the best way to move a tag value from the panelview+7 to the clx plc. We display amps from a power meter on the panelview screen, read in...
Replies
1
Views
382
Hello, Which syntax I need to use for write on value on a “local tag” that have “Machine” as scope? Thanks
Replies
0
Views
429
Hi , i currently have data logs running but i need a way to link a tag to them so if there ever not running i can trigger an alarm? what is the...
Replies
4
Views
1,803
Hi, We have added some new valve timing functionalty to AB programs and are running it out across 6 units. I have verified that the code works...
Replies
2
Views
1,938
Back
Top Bottom