1 of 1 people found this helpful
I was not able to reproduce your issue on my environment.
I am currently using PI Data Archive 3.4.400.1162. What is your PI Data Archive version?
Have you tried to use PI Analysis? It is more efficient and accurate than Performance Equations.
I created a source tag called TagTest and a PE Tag called BigNumberTest (both Float32) and the expression 'tagtest' = 2147483648 works fine.
hope this helps.
3 of 3 people found this helpful
The AND operator in PE evaluates True, if operands A and B both evaluate to true. If both A and B are integers, returns the result of a bitwise AND operation.
I am curious about your choice of numbers (2147483648). 2147483647 is the Max Value for Int32. What is this your tag data type? Are you checking for maximum?
I agree with Thyagarajan Ramachandran, what is the use case you are trying to achieve with these performance equations? and what are the data types of the operands? It is difficult to discern exactly what you are trying to do from the expressions.
I did not realize you were comparing the tag value and a number to a number. In this case case Thyag is correct, this expression will be evaluate in a bitwise fashion.
What is your final goal with this application?
4 of 4 people found this helpful
Be warned: The answer is long and boring and may not solve your problem
As I understand, you have 32 individual boolean signals packed in one 32-bit PI-Tag of type int32.
Converting your mask 2147483648 into hex gives 80000000 or binary 1 and 31 zeros. So, you try to check the most significant bit (31, counting bit positions from 0).
And exactly this bit 31 is the catch, because its meaning depends on internal implementation/definition of type int32. It may be
- Unsigned, with range 0 to 2^32-1 or 0 to 4294967295
- Signed, with range -2^31 to +2^31-1 or -2147483648 to +2147483647
In PI the int32 is implemented as Signed. All values above 2147483647 are too big to fit into 31 bits + sign and may (or may not) be converted - it is implementation dependent and may be different in old PI Performance Equation Subsystem being part of PI Data Archive and PI Analysis Subsystem being part of PI AF. So don't rely on it.
If you need to check this particular bit, just try it out with -2147483648 (which is possible to store in int32) instead of 2147483648. It may work. I didn't have time to check it.
If it doesn't, just try to avoid checking bit 31.
EDIT: It's trivial, just check if the value is <0 - it's only possible if the bit 31 is set.
Thanks all for your help and sorry for my late reply.
As suggested by Gustavo 'M_MachineAlarmReasons1_32_R' = 2147483648 works but is not cumulative.
I try to explain better, I've 8 alarm reasons that can come single or multiple:
('M_MachineAlarmReasons1_32_R' and 16777216)=16777216 alarm 1
('M_MachineAlarmReasons1_32_R' and 33554432)=33554432 alarm 2
('M_MachineAlarmReasons1_32_R' and 67108864)=67108864 alarm 3
('M_MachineAlarmReasons1_32_R' and 134217728)=134217728 alarm 4
('M_MachineAlarmReasons1_32_R' and 268435456)=268435456 alarm 5
('M_MachineAlarmReasons1_32_R' and 536870912)=536870912 alarm 6
('M_MachineAlarmReasons1_32_R' and 1073741824)=1073741824 alarm 7
('M_MachineAlarmReasons1_32_R' and 2147483648)=2147483648 alarm 8
all of them works fine alone and and if I've number result of alarm 5 plus alarm 4 plus alarm 7 for example, they became all true.
as above alarm 8 doesn't work at all, if I use 'M_MachineAlarmReasons1_32_R' = 2147483648 it works alone but not cumulative with Others.
thanks again for any suggestions, Alfonso.
data type of 'M_MachineAlarmReasons1_32_R' is Float64
Oddly enough, the bitwise comparison in Asset Analytics can compare Int64 but the resulting comparison is an Int32. Which means you will need to convert during the comparison:
I will reach out to one of the developers and ask if this is intentional. While the PI Data Archive does not support an Int64, an AFAttribute does, and I would hope that I would expect (Int64 And Int64) to return another Int64.
The best solution would be to change the data type of 'M_MachineAlarmReasons1_32_R' to be an Int32. This should not be a problem with the interface sending a UInt32. Except instead of 2147483648, you would need to use -2147483648. This solution makes the most sense since it truly compares the 32 bits as they were read from the interface.
Or you could try changing the PE to:
Int('M_MachineAlarmReasons1_32_R' And Int(2147483648)) = Int(2147483648)
But that's a lot of repeated effort to achieve something that needs to be done only once when reading the 32 bit integer from the interface.
I've already tried to use -2147483648 didn't work, now I'm trying the formula Int('M_MachineAlarmReasons1_32_R' And Int(2147483648)) = Int(2147483648)
and also this doesn't work.
I understand the point that Int32 is until 2147483647 but I'm comparing simply a number in PE and it doesn't work....
is there any other suggestion for my problem?
The suggestions kindly received so far have not even given solution to the problem.
Thanks to all.
Have you tried defining the PI tag to be an Int32? I don't see where you attempted that in this thread.
Yes I've tried but with Int32 the value 2147483648 is out of range, as we already pointed out max for Int is 2147483647.
If the out of range error coming from the interface, or later in your PE?
Directly from the tag when the value is higher then 2147483647