Digital State Sets and Bit Flags
a common data type encountered are Double Integers as bit flags, where different combinations of each bit of the binary representation of the double integer corresponds to a state. PI's Digital State Sets do not handle these well.
First, it requires that even unused states are created in the set . . . annoying, but not a total hindrance (there is another idea posted pertaining to this particularly)
Second, digital state sets have a maximum of 16383, which is only 14 bits, which is only sufficient for single integer (8 bit) flagging techniques.
probably more accurate to say obfuscate the bit wise representation with the corresponding state name . . . but yes, we are in agreement
Ok, now it's clear. You want to ingress bit wise representation to the Data Archive, but from the client perspective, you want to obfuscate the bit wise representation with the corresponding numeric value.
i'm not certain anything needs to change on the client side per-say. The clients are just seeing a State number assignment on a trend with the value being the state name. clients would still just be intepretting a number assignment (bit number) on a trend with the value being the state name.
Its almost like there needs to be Digital State Set Type that can be chosen (and this is just an example/idea). The type we are used to now is where the State Numbers are integer representations and go up to 16384 states. An additional type would be where State Numbers are bit representations
The server side could still present the clients with state numbers, with the server handling whether the state number is from an integer representation or bit representation
example bit mask/flag attached. this example CAN be done with a normal digital set, bit it requires 1016 empty states, but its only a couple of bits away from exceeding the limit
Hi, you have nicely described a use case. Can you further comment on what your expectation would be on the client side? For example, let's say we were able to store these bit flags on the server side, the clients would need to interpret them. So in reality we would need to handle this both on the server and client sides. Thoughts?
Kenneth Barber commented
That makes sense! You get my vote!
@Kenneth, in a bit flagging methodology the interger representation will be something like 0=None, 1=Run, 2=RunFwd, 4=RunRev, 8=Starting, 16=Stopping, 32=No Power, 64=Error, 128=Interlocked. This set of values is going to be different for different devices . . . uses are not going to be able to tell/remember what 8 means . . . it needs to be in a digital set.
The digital set will unfortunately contain 128 items in it even though only 9 values are being used.
We have numerous examples where a 16 bit method is being used (my above comment about being limited to 14 bits) . . . 16 bit example would be something like
-one Status out of 27 possibles Integer=655560 Bit Flags- 1010 0000 0000 1100 1000
Again a user is not going to really know/remember what 655560 means compared to the other 26 options
Kenneth Barber commented
Why do you need to use a digital state set? Why not an integer type?