I have a case that was closed in 2017, where someone provided a workaround executable for the Interface that fixed the issue. I am assuming they were able to detect a bit container field if the MASK was set for the pitag, but unsure. However after updates the changes were lost and I was able to get GE to admit an issue with their API and implement some changes, unfortunately in order to fix the bug it also requires changes in the client code(GE HabConnect). The BUG effects any customer using this interface but is hard to detect as the only thing that shows an issue is happening is the PITag does not update with the correct value and keeps the old value when the bug appears.
The cases are documented well (00473266) (01057502).
Below is a synopsis of what is going on and what it should take to fix this BUG.
The bit containers are defined as bytes*n where n is the number of bytes you want to define for the database field. If the bit container field uses every bit in the BYTE and the most significant bit is set to True and the rest is set to False the habconnect sampler returns a NULL with the value. However since Sampler API had no data type for bit container, and it was lumped together with the HC_INT macro type the data is usually casted back to a signed int, char, or short, and returns a NULL. The interface is currently handling this by not sending an updated value to the pi-tag snapshot and hence data is lost!
Because of this issue I submitted a defect to GE and they have added a new MACRO defining a new type if the field being requested is a HC_BIT(Bit container). The interface needs to implement code changes to define an unsigned char, unsigned short, or unsigned int based on the size of the data of 1 byte, 2 bytes or 4 bytes for the field.
Currently any field that is defined as a bit container and uses all of the bits in the bit container field has the possibility of running into this bug.
