06-10-2020 02:09 PM - edited 06-10-2020 02:15 PM
So each field is 32bits. Leave out the FXP confusions because I think the scaling should be done in code. What are the definitions of the various scales?
LabVIEW has all the tools to do any desired bitlevel stuff. 🙂
Do you have a link to the full spec sheet? There has to be more to it.
06-10-2020 03:13 PM
Hi Altenbach,
No I don't have access to the full spec sheet. I will need to get more information on the scaling because I currently don't have that information.
Yes, it makes sense that most of the scaling will probably have to be done in code and I will have to discard the FXPs. Thanks
06-10-2020 05:12 PM - edited 06-10-2020 05:14 PM
I have to say, that's a pretty crappy bitmap of the message. I mean, data5 is described as an integer, yet has a range in fractional numbers. And most of the data types are what I would call even remotely "industry standard". Did they make them up? Hmmm...
Somebody fell asleep at the wheel.
06-11-2020 03:47 AM
"For your last value, you say it is a signed 32 bit integer, but a range of -0.5 to +0.5. That makes no sense. That would require a floating point value. Though it is possible that you can use and integer if you scale the value by 10 or 100 or something. So -0.5 would show up as -500. +0.42 would show up as +420. But that kind of scaling is something both ends need to agree upon."
That's what i would assume is the case. As to the scaling factor it should be easy enough to see if you get some real measurement. It's quite common to have instruments send data scaled by 100 or 1000 to avoid floating Point issues. Also, if the instrument only have 2 decimals precision it'd be fooling some people if it send 6 decimal values. 🙂
06-11-2020 05:47 AM - edited 06-11-2020 05:50 AM
@SolPS wrote:
Hi Altenbach,
Yes, the wireshark image is in the payload field. I was able to partially fix the problem and I could see the correct data in the first fixed point data field. I had to configure the fixed point control for 32 bit word length and 15bit integer length and then use the Fixed point to integer cast function to convert to unsigned integer before flattening to string. I repeated this process for the other fixed point data and configured the word length and integer lengths for the each specific fixed point control. The problem now is that the wireshark data does not match the input of the cluster for the other fixed point data except for the first one. I've attached a sample vi and the wireshark screenshot. Any suggestions are welcome. Thanks..
in your attached example flatten_cluster2.zip 11 KB, the first fixed pt data = 32767 was still configured to 32 Bit;17 Bit (not 32 Bit;15 Bit)
here how it looks with 32 Bit; 15 Bit:
it looks like you did the changes and saved for fixed pt data 3 and fixed pt data 2, but forgot to save the changed vi for fixed pt data
😉
as crossrulz pointed out in Message 6:
Looking at the hex values, only the first Fixed Point value is wrong.