Convert to U64 to EXT back to U64

[NelsonUWP]

I'm trying to convert some CAN data to convert using a converter that also needs to output a decimal value.

For example

0xFF gets output as 255.0

0b1111 gets output as 15.0

and 1566.78 gets output as 1566.78

CAN data uses 64 bits so you'll have something like FF FF FF FF FF FF FF FF that needs to get converted.

I'm running into problems converting it for a comparison and then converting it back to hex for the log files. I think the 64 bits may be too much but I _need_ to be able to use it. Any help would be appreciated, thanks.

[JÞB]

---

@NelsonUWP wrote:

I'm trying to convert some CAN data to convert using a converter that also needs to output a decimal value.

For example

0xFF gets output as 255.0

0b1111 gets output as 15.0

and 1566.78 gets output as 1566.78

CAN data uses 64 bits so you'll have something like FF FF FF FF FF FF FF FF that needs to get converted.

I'm running into problems converting it for a comparison and then converting it back to hex for the log files. I think the 64 bits may be too much but I _need_ to be able to use it. Any help would be appreciated, thanks.

---

I sure bet you are!  The conversion from a 64 bit int to a ext float and vice versa are BOTH losey conversions.  that is not every number in either format has an exact representatio in the other.  Why not just write the original string read to the file? 

[smercurio_fc]

I'm not sure I understand what you mean by "also nees to output a decimal value".  CAN data should come as a sequence of bytes, but it seems your example is starting with a sequence of ASCII characters. This is not the same thing. For a sequence of bytes the correct function to use is Type Cast, not the string functions. That said, EXT is 128 bits, not 64. DBL is 64 bits. The sequence of FF FF FF FF FF FF FF FF is not a valid floating point representation, so I'm not sure what you're trying to show.

[NelsonUWP]

I'm reading an automated script from a text file. The text file has expected value and a mask. Hence the string

So I'm expecting: 0x00 00 00 00 00 01 F4 00

I'm masking:        0xFF FF FF FF FF FF 00

So when the actual value from the CAN comes from the hardware it has the value 0x 00 00 00 00 00 01 F4 F5

I need to convert it to mask the received value to compare it to the expected value. 

The reason I'm converting everything is for Tool Qualification purposes. The hardware should just give me data:

CAN card: 0xXX XX XX XX XX XX XX XX (an array of 8 bit integers actually)

Analog card: 15.67

Discrete card: 0/1

ARINC card: 19 bits of hex data

etc.

From those I need to standardize an output to go into my qualified conversion block to make pass/fail determinations. 

The inputs of my comparison block are all ext (for now).

[Jacob_K]

You should use Type Cast and I agree that what you are proposing is definitely not lossless.  Maybe you can check for your data to be within a small range to account for the fact that it is lossy.

[NelsonUWP]

I honestly don't think there is a good way to do this. Typcasting will still be lossy right? 

I think the best way to do this is to create separate classes for each type of data and converting and comparing based on type.

[NelsonUWP]

To actually accomplish what I'm trying to accomplish, what is the best way to pass data that can be of multiple types?

[GerdW]

Hi Nelson,

when dealing with CAN communication you usually have some message database describing all values ("signals") of the messages, with bit position/length, gain, and offset for each signal. You have to use all of those information to retrieve the needed values from the CAN 8 byte message.

Which CAN hardware do you use? The CAN API offers functions to do the conversion for you...

[Norbert_B]

Nelson,

i do not understand why you want to convert the whole CAN message at all. Just as Gerd wrote, most often, you are only interested in part of the message (aka "Channel"). This is what masking is usually used for. So each channel only uses a fraction of your CAN message. In addition, depending on the CAN driver, you could probably represent the whole message as U8 array instead of a single U64....

So if you really use only "fractions" of the U64, you can simply split down the numeric representation by using Split Numbers (U64 => 2xU32 => 4xU16 => 8xU8) and combine them again using Join Numbers.

@smercurio: I am sorry to correct this "That said, EXT is 128 bits, not 64". Extended is for most CPU/ALU architectures still 10 byte (80 bit), not 16 bytes... see here. Nevertheless, you are right that representing complete CAN messages as floating point numeric value makes no sense in most cases.

hope this helps,

Norbert

[NelsonUWP]

CAN itself isn't the problem, the problem is the data types. I need to have all my data be flexibile enough to use the same comparitor for each comparison type. 

So for an analog value I need something precise enough to compare decimals. For ARINC I need something to compare 19 bit integers. For CAN I need something to compare U64s or 8-8-bit arrays. So on and so fourth.

I'm debating on doing something in OOP, but that seems like overkill.