LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Packet data appearing in wrong field after flattening cluster to string

Highlighted

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.


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 11 of 15
(118 Views)
Highlighted

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 

0 Kudos
Message 12 of 15
(104 Views)
Highlighted

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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 13 of 15
(85 Views)
Highlighted

"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. 🙂

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 14 of 15
(59 Views)
Highlighted

@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)

 

32-17.PNG

 

 

here how it looks with 32 Bit; 15 Bit:

32-15.PNG

 

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.

 
0 Kudos
Message 15 of 15
(54 Views)