Repository navigation
Add fixed point support using variants #7
Description
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).
Activity
pollockm commentedon Mar 29, 2016
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 commentedon Jan 20, 2017
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 commentedon Jan 20, 2017
A simple test in LV 2015 with a network published shared variable (though not a UDV) works well:
fxp.zip
pollockm commentedon Jan 20, 2017
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 commentedon Jan 20, 2017
The shared variable works fine with LV 2016 as well.
srsmith99 commentedon Jan 24, 2017
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 commentedon Jan 24, 2017
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 commentedon Jan 24, 2017
fxp test.zip
pollockm commentedon Jan 24, 2017
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 commentedon Jan 24, 2017
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 commentedon Jan 24, 2017
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 commentedon Jan 24, 2017
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 commentedon Jan 24, 2017
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 commentedon Jan 24, 2017
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.
srsmith99 commentedon Jan 25, 2017
Several issues with dcaf fxp.zip.
FYI-UDV deployment was not the issue on my end, so something else is causing the integer UDV display in Distributed System Manager (type is correctly listed as fixed point).
DCAF-Builder commentedon Jan 25, 2017
dcaf fxp2.zip FPGA VI was in the wrong directory - my mistake. Regarding the config file, this is an error due to my test machine being on the pre-release version of DCAF that is in testing now.
DCAF-Builder commentedon Jan 25, 2017
I can see non-integer UDV values in system manager in 2016, but I don't have any sensors to pull actual data from.
With regard to the config file, that is an error that won't be corrected for a little while - I'd need to downgrade my system to the currently released one and build a new config file (the latest release introduces a change to the config file format such that old files will still work with the new release but new files won't work with the old release).
I'll spin up another test machine with the previous release and rebuild.
srsmith99 commentedon Jan 25, 2017
No problem and thanks. r.e. the integer UDV issue, it appears one of my controls had an improperly configured fxp type. I will recompile fpga and retest but hopefully that issue is solved.
pollockm commentedon Jan 25, 2017
Reproduced error 1108 on opening config from new version editor in old version runtime. Opened new issue to track that one. LabVIEW-DCAF/StandardEngine#59
srsmith99 commentedon Jan 25, 2017
Integer issue is solved. Butterworth filter in FPGA has a word length limit in multi-channel mode of 16. So 32,16 fxp was truncated to 16,16. As expected, not a DCAF issue.
srsmith99 commentedon Jan 30, 2017
I modified your dcaf fxp2 to eliminate the UI (we aren't planning to use one) and generated a new config file since I was unable to open the one you provided. I was able to demonstrate fxp data updates from the FPGA into the shared memory using the psp interface by running the cRIO Main.vi interactively. So it does appear to work; unfortunately, I have not been able to get it to run with everything fully deployed to the cRIO chassis but we are working on that.
srsmith99 commentedon Feb 1, 2017
Thank you for the help on this one but we are going to abandon this effort for now. In interactive mode the FXP ->DBL works fine. In deployed mode it does not work and continues to throw errors. Instead we are implementing the fixed-point bitwise representation and will pass the FXP as an integer where it can be recovered in our C App control logic running on the Linux RTOS.