FXP user variable data corruption

[jgcode]

Windows 7 Professional

LabVIEW 2009 SP1, RT

I ran into this nasty issue yesterday and am looking for some help (please).  

I used the Scan Engine along with User Variables to push filtered data from FPGA C Series modules to the RTOS.

When the Fixed Point data from the User Variables was read in the RTOS it was converted using the To Double Precision Float primitive.

The result was that positive numbers were output correct but negative numbers became corrupted.

Further testing revealed the following:

• This only occurred on the RT target, the PC target worked (the User Variables tested and converted were Network Published) 
• This only occurred for User Variables (the app have 3 different FXP representations and this affected all of them) as the data source
• If the data source was a FXP constant then the conversion to a DBL worked correctly on the RT target
• If the data source was probed or output to an FXP control, then the data was displayed correctly, it was only after the DBL conversion that the corruption occurred
• Accessing the Variables as a DBL using the Shared Variable API via Read Variable did not corrupt the data for Network Published User Variables when read from the RT target
• Accessing the Variables as FXP then converting to DBL using the Shared Variable API via Scanned Read did corrupt the data when read from the RT Target 
• This was also the case for the To Single Precision Float primitive

The only work-around I have found was to use Fixed-Point to Integer Cast then Integer to Fixed-Point Cast.

This hack worked in producing the correct value when then converted to a DBL.

I am not sure of the performance overhead for this, due to extra converting on the RT.

Below is a block diagram of the methods I tried:

 

The Front Panel containing the results is below.

As you can see the negative Fixed Points are always converting incorrectly to a DBL.

However, the hack I did produces the correct results 

 

Has anyone seen this before?

Is this a known issue?

Can it be replicated?

We have tried this on two systems thus far, and it was replicated in both cases

As a note, I did a similar project in LabVIEW 2009 (not SP1) and I did not have this issue (although I did have this one) 

Cheers

-JG  

[Ben_S]

jg-code,

Thanks for the detailed explanation of your issue and the tests you've done! I apologize that you are encountering this issue, but luckily, it is a known issue.

You've found CAR (Corrective Action Request) #178392, "If someone uses the user defined variable with his I/O channel on FPGA in a different configuration from default fixed point data type which is signed 64 bit word length and 32 bit integer, the value converts to a wrong double value on RT whenever the fixed point value becomes negative."

The workarounds are:

1. Set the User Defined Variable to default 64 bit configuration.
2. Convert Fixed Point » Integer then  Integer » Fixed Point (Which you've already figured out!)

However, the CAR does indicate that the issue was fixed in NI-RIO Version 3.2.1. Which version of the RIO driver are you using? You could upgrade to the latest version for LabVIEW 2009 SP1, NI-RIO 3.4.

[jgcode]

Thanks for the info Ben.

I like the idea of using the default 64 bit workaround, as the FXP-Int-FXP conversion seems to be a little expensive on the RT

Unfortunately I am using NI-RIO 3.4 (with LV2009 SP1)

[As a side note - I did not see this issue with NI-RIO 3.2.1 (with LV2009)]

Also is there an RSS to subscribe to, for CARs?

Cheers

-JG 

 

[Ben_S]

jg-code,

I'm sorry to hear you are still having that issue in NI-RIO 3.4! There is no CAR RSS feed, but you can check the known issues list for various products as they are updated to reflect new information.

For Example: Known Issues and Bug Fixes for LabVIEW 2009 Real-Time Module

[jgcode]

Thanks,

Have/Will you file a CAR for this or should I do? 

Cheers

-JG 

[Ben_S · Accepted solution]

jg-code,

The CAR has allready been filed for this issue. What I will do is verify that I can replicate the issue with RIO 3.4 and update the CAR to reflect the current situation.

[jgcode]

Ok, I figured if the old CAR was closed, so you would need to open another.

Anyways, please let me know what you find.

Thanks for all your help

-JG 

[MarkCG]

Necroing this thread--- looks like the bug popped backup again. NI RIO 12.1, CRIO 9074

[fromm8]

MarkCG

Does the workaround mentioned above work for this case?

Frank R.

[MarkCG]

Hi Frank, didn't try it, I just ended up coercing the FXP number to be greater than 0, since I don't need the negative values anyways.