LabVIEW
Conversion from double precision float to hexadecimal string.
Hi Antje,
@antje668 wrote:
parts of the project is to convert different angle values to hexadecimal values when the values are sent as CAN frames.
The challenge I have is that the block "number to hexadecimal to string" only accepts integers. But my angle values will be in double format as I will sometimes input angle values with decimals, an example might be 36.42467.
I wonder if anyone has been in similar scenario and if so is there a solution?
Anybody working with CAN has exactly the same problem! (Also those using Modbus…)
CAN messages only handle integer data!
But you can apply a scaling to those integers to convert to/from float values: read your DBC file carefully using a DBC editor like CANdb++ from Vector.
So the solution to your problem is to apply the scaling as it is defined for your CAN signal in the according DBC file (or whatever file you use to define your CAN signals, messages, and network)!
Better CAN drivers for LabVIEW already handle that conversion. Does your CAN port device and it's driver already handle frame/message conversion to an array of signal values?
Hi Joly,
@Joly77 wrote:
Just convert from double precision float to hexadecimal string? You can try this way
No, you cannot use that way!
Converting a DBL float into an U8 array of just 4 elements is wrong. Plain wrong…
And your solution does not fit to the OP's problem: it's about scaling a range of float values into their respective integer representation in a CAN message…
@Joly77 wrote:
Hi GerdW,
1.I'm so sorry that I mistook DBL for SGL , if it is DBL,it should be divided into 8 U8. But as I think, the value like 32.42467 can be regarded as SGL
It can be, just about barely! If you add one more decimal digit at the end you get at the limits of what an SGL can correctly represent.
2.the OP's problem doesn't mean that His ultimate goal is to turn the float into the HEX string to write into his CAN message?I think my way can be useful
Well, it was pretty specifically written in the OP message. So debating now that the OP might have meant something else is a little bit a moot point. And if you really want a clean solution for your code there is a simple function that does all the byte extraction and stuffing into an array for you if you use the Flatten to String function followed by a String to Byte Array. You even can select the endianes that function should use, without having to rewire all those Split Number functions. And you don't even need that loop then. Just wire the entire array to the Flatten To String function and watch out for the boolean called Prepend Array or String Size. If you send an array you usually want to have some indication of the number of elements that follow in the data stream but if it is not an int32 that your protocol wants, you have to disable that boolean and stuff the right number in front of the array data yourself.
And it is not a hexadecimal string really but a binary byte stream. String implies a readable text. Hexadecimal, decimal or octal or binary doesn't even come into play when it is about sending data over a binary stream channel. It's simply bytes, words, longs or quads that you send. Those characteristics of hexadecimal and the likes only come into play once you convert those bytes into a string to display to a human observer. The bytes on the wire remain the same independent of any such display formatting.
