The recorder API functions make it seem like a recorder would natively capture a 32-bit value. However, the API does have a way to return a (64-bit) double. Do recorders actually get all 64-bits of precision in a double, or do they just get a (32-bit) float and return it as a double?
Yes, the recorders record the full 64-bits of precision.
1 Like
So, is there a reason that it could not get a 64-bit integer (other than that there’s no API for it)?
You could get a 64-bit integer, but there aren’t many (any?) of those to be recorded in the firmware. If there was, it would be stored in a union with the double value so you could still use the existing API.
1 Like
Sweet! So I would only have to do some pointer magic, like
double d_value = controller->RecorderRecordDataDoubleGet(...);
int64_t = *(reinterpret_cast<int64_t*>(&d_value));
Full Disclosure: I don’t really need this, but I was nonplussed when attempting to make decisions based on the amount of storage space available and whether I really needed to keep track of ints and doubles separately.
No worries! I’d use a union to avoid pointer magic.
1 Like
I assume that every record associated with a data address will occupy 8 bytes in the firmware (in order to support the 64-bit type double and since there is no specification of data type when you set an address for a given recorder/index) Is that correct?
I need to accurately plan for quantities of data with real limits.
Yes, that is correct!