Add fixed point support using variants

[smithed]

You can set the type of the variable to "variant" and perform reads. Since variants automagically coerce data to the selected type, we can read fxp values and just autoconvert to dbl. Slow, yes, but better than not supporting them if we need them (which we don't right now).

[pollockm]

I did some testing on this, and reading/writing fixed point values (either shared variables or UDVs) works correctly if we tell the Read/Write Variable function that it is actually accessing a DBL (wire a DBL constant to the data type input). Looks like the function will already handle the conversion for us.

[srsmith99]

I have been attempting to make this change to our DCAF project. We have analog input modules on the cRIO-9030 going through the FPGA where we do some filtering. At the moment we are using the I16 data type for our UDV's but would like to switch to fixed point so we could use the calibrated voltages.

As a start I changed the analog input UDVs to fixed point and all related items in the DCAF configuration editor were set to doubles.

When I run the cRIO Main.vi I get a command error in the init.vi. The error occurs when the Open Variable Connection function tries to open the variable location thinking it is a double. This appears to be the first place where the Tag data and actual variable come together. Apparently the open variable connection function does not like the fixed point type. Any recommendations?

[pollockm]

A simple test in LV 2015 with a network published shared variable (though not a UDV) works well:

fxp.zip

[pollockm]

Next is to try the UDV case. This would be interesting, since typically UDV and regular shared variables share the same properties in terms of access. I had assumed that they would work the same in this case as well, but perhaps that was incorrect. Let's find out!

[srsmith99]

The shared variable works fine with LV 2016 as well.

[srsmith99]

I ran another test and the FXP to DBL is not working properly. cRIO 9030 in hybrid mode. I removed all FPGA processing, just analog inputs to FIFO and then wait for the scan engine and out to UDV. Everything to this point is FXP.

Using the DCAF Execution Service template for the project with the modified init.vi (Clear Errors.vi set for error -66212 following the Open Variable Connection.vi). Without the Clear Errors mod the shared memory won't even initialize due to a -66212 command fault. DCAF configuration set with Scan Engine channel set: ni.var.io://localhost/User-Defined Variables/M1_AI0 as a Double. Mapped to a Tag also set as a Double.

When I deploy and run this the UDVs are active (per Distributed System Manager). With a calibrated voltage input the voltages show up as an integer; tenths of a volt are rounded up or down but not displayed. The shared memory input/output files are initialized and the indexes update but the voltage values are not being written to the memory.

I took a few screen shots and put a bit more detail in a word doc that is attached.
Using FXP variables for AI modules testing 012317.docx

[pollockm]

I can reproduce good behavior on my side without DCAF - if accessing a FXP shared variable, the automatic data conversion works without error. If accessing a FXP UDV via the ni.var.io protocol, I get data type does not match error on opening the variable connection. If accessing the same FXP UDV via the ni.var.psp protocol (going through the network published shared variable interface), I do not get any errors and can see the value update.

Try modifying the URL to use ni.var.psp instead of ni.var.io and see if you can reproduce the good behavior.

Will post project shortly.

[pollockm]

fxp test.zip

[pollockm]

For the above workaround to work, you'll need to have the UDVs marked as 'Enable Network Publishing' in their properties dialogs. This is the default for UDVs.

[srsmith99]

Modified the URLs to use ni.var.psp, network publishing enabled. I've got the same integer result for the UDVs in the Distributed System Manager and shared memory input/output files are not initializing. I'll check out the fxp test.zip you sent.

[pollockm]

The working theory at this point is the psp interface has a data conversion layer in its stack, whereas the udv interface does not. The underlying data is the same, but one access method is permissive of different (but convertible) data type and the other is not. Note that these interfaces are not part of DCAF, they're part of LabVIEW itself. We won't be able to change the interfaces, just which one we use.

If you can reproduce good behavior without DCAF, then it's just a matter of finding if there are any tweaks to DCAF necessary to allow that logic flow. I'll see what I can find.

[DCAF-Builder]

Reproduced good behavior with DCAF. Project attached. You'll of course need to change the IP addresses for the UDP module to work right, and the usual FPGA stuff to get it compiling on a 9030.

dcaf fxp.zip

[srsmith99]

Tested the fxp test.zip. Modified for my 9030, downloaded the FPGA and ran the RT vi interactively. It works!

The integer issue I was seeing may be because I did not redeploy the UDVs when I was doing my previous testing. Could have made all the difference - I will retest that tomorrow. Just saw your post, that's good news!

[pollockm]

Let me know what you find. If it works tomorrow for you I'll consider the issue closed, since it would have been shown to work on my machine and yours.