HLAfloat64LE encoding

[leondorfman]

Use VoltageSupply attribute of PowerDistIfFOM.xml to demonstrate this problem.
VoltageSupply attribute has HLAfloat64LE data type.

PowerDistIfFOM.xml:30
PowerDistIfFOM_datatypes.xml:35

This is a code sample to demonstrate the problem.
rti::AttributeHandle handleAttribute;
rti::AttributeHandleValueMap attributeMap;
float hlaFloatTest = 89.12f;
rti::HLAfloat64LE hlaFloatEncoder;
hlaFloatEncoder.set(static_castrti::HLAfloat64LE(hlaFloatTest)); // note: this line has both "less than" and "more than" symbols
....
handleAttribute = Attribute.getHandleFOMAttribute();
attributeMap[handleAttribute] = hlaFloatEncoder.encode();
_rtiAmbassador->updateAttributeValues(ObjectClassInstanceHandle, attributeMap, rti::VariableLengthData());

TrickHLA Sim Control console reports a blocking error

|L 0|2025/01/14,10:45:22|localhost.localdomain| |T 0|0.00000000| Attribute::extract_data():792 WARNING: For Attribute 'VoltageSupply'
with Trick name 'halo_subsystems.eps.elect.pri.PPE.PpeA1If.mInData.IbcVoltageSetpoint', the received FOM data size (8 bytes) !=
Expected Trick simulation variable memory size (4 bytes). Make sure your simulation variable is the same size and type as what is defined
in the FOM. If you are using Lag Compensation one possible cause of this problem is that your lag compensation variables are
not the correct size or type.

[leondorfman]

../../SIM_Gateway/S_main_Linux_8.5_x86_64.exe trick_version
19.8.0-beta

[dandexter]

Can you verify the simulation variable 'halo_subsystems.eps.elect.pri.PPE.PpeA1If.mInData.IbcVoltageSetpoint' is of type double? I'm assuming this is your simulation and you have access to the source and input files, but if not please convey the information in this post to the responsible team that developed the simulation.

TrickHLA will automatically encode data for the user and there is an inherent trust the user has configured the HLA Attribute to point to the Trick simulation variable of the correct type as specified in the FOM (i.e. double, float, etc) and it does not parse the FOM to verify this. The only thing you have control over for the encoding of primitives is the Endianness of the encoded primitive.

The error message is saying 8 bytes of data were received but the destination Trick simulation variable is only 4 bytes. The default TrickHLA behavior is to print a warning message and then drop the data for that variable.

Also, you may want to change your "float hlaFloatTest = 89.12f;" variable to also be a double to avoid the possibility of overflowing from receiving a large number since the base exchange type and encoding is for a 64-bit floating point number.

[leondorfman]

IbcVoltageSetpoint is HLAfloat64LE in the source released to Maxar
However log_halo_Subsystem_Data.header indicates float variable type
(Please use the comment's raw source to see xml file tags.)

SIM_Gateway/FOMs/PpeHaloPowerFOM.xml:30

IbcVoltageSetpoint
Voltage
NA
NA
NoTransfer
PublishSubscribe
HLAreliable
TimeStamp
IBC output voltage control setpoint.

SIM_Gateway/FOMs/HaloEpsDistIfFOM_datatypes.xml:35


Voltage
HLAfloat64LE
Volts
NA
NA
A value of electrical potential.

SIM_Gateway/RUN_Maxar-PPE/log_halo_Subsystem_Data.header:3:
log_halo_Subsystem_Data float V halo_subsystems.eps.elect.pri.PPE.PpeA1If.mInData.IbcVoltageSetpoint

[dandexter]

Closing the issue since I have reached out to the responsible team that developed the simulation that has the issue and they are now aware.