10-12-2012 11:56 AM
Oh, oh ... Problem solved after "Saving" the RT Vi ... Sorry, for the unnecessary post ...
Luke
10-17-2012 11:58 AM
Hi experts!
I am still struggling using / understanding the library.
1) I do not understand the scaling. In the ref. application the original measurement data are scaled by 1! This means, that the analog output of the NI9215 is given in Volts and the factory calibration is used without additional (programming) effort, right? Or should the factory calibration be explicitly red (as shown in the cRIO Waveform-Template (LV2012) in order to get exact analog measurements?
2) Where should be the transformation to different scales and offsets be placed (like: F[N] = 3[N/V] x U[V] + 0.2N ) ? On the FPGA or on the RT-System? And how would it be implemented best, without changing the library? Because naturally I would place it in a Channel Scaling Info cluster...
Many thanks in advance,
Luke
10-17-2012 12:25 PM
Hi Luke,
Yes by default the scaling is 1. This is purely a software scale and has nothing to do with the calibration of the device. If you look at the FPGA the IO Node is returning FXP data that has all HW coefficients already applied (as opposed to the old days when the IO nodes returned "counts" and you had to apply cal coefficients).
So if you leave it the way it is the library will return a factory calibrated voltage value that is being reported by the 9215. Now the library allows you to apply a simple first order scale to the data if you wish. This is very helpful for applications that are using microphones and accelerometers because those sensors have a simple one term sensitivity value.
If your scaling equation has multiple terms then you will need to add that to either the FPGA or the RT side. Adding it to the RT side is the simplest and quickest. Adding it to the FPGA side takes more effort but frees up your RT CPU. I'd recommend starting with the RT side and moving it down if you need to optimize.
Regards,
Jeff Tipps - Systems Engineer
10-17-2012 02:28 PM
Thank you very much, Jeff, for the fast response. That was all I needed to know. I found a couple of different scaling procedures and was quite confused.
Luke
02-02-2013 04:20 PM
I tried to be agreed this 3 * 9020 and 9225. But I did not save the modules and the channel numbers permanently. Each time the VI opened the original settings.
I lost my original CreateChan.vi ChannelConfig.ctl, how the program may be re-installed? criowfm_401_installer.zip
02-04-2013 09:14 AM
The toolkit may be uninstalled from "Programs and Features"
Regards,
Jeff Tipps - Systems Engineer
02-21-2013 02:02 AM
Hi,
i used until now a crio 9012, in the Module rwfm ConfiTiming as in the picture you can see a 40M. could someone explain why we have to use this 40M? does this mean 40M = 40Mhz?
now when i use a crio 9024 which has 800Mhz what do i write 80M or 800M or always 40M?
thank you for ur help
J.
02-21-2013 09:27 AM
The 40 MHz has to do with the FPGA clock not the CPU processor speed. That little piece of math is converting your sample rate to FPGA ticks and does not need to be changed for different cRIO controllers.
Regards,
Jeff Tipps
S&V Systems Engineer
03-21-2013 02:00 PM
Hi Jeff,
I think that I may have discovered a cRIO firmware bug that relates to this reference application. I apologize if this is the wrong place to post this. Please move as appropriate.
Further back in this thread you may recall that I built up a multi-channel cRIO recording system that streams data to an external USB disk using the following:
(1) NI cRIO-9022 running August 2011 NI-RIO 4.0 firmware.
(1) NI 9215 AI Module
(1) Intel 320 Series SSD in USB enclosure (Crucial m4 drives proved unreliable)
Quick Note: HDDs are unreliable in oceanography due to the rough handling of the equipment. This should address an obvious question that will come up later in this post.
This system proved to be very reliable. We deployed these systems at sea for weeks at a time without a single dropped sample, missing file etc. while writing to a Intel 320 series SSD via the cRIO USB port.
I installed the latest developers suite (2012) and upgraded the firmware on all (3) cRIO systems with identical configurations.
After the firmware update all (3) recorders would stop recording after ~100GB. A look at the data files revealed that there were drop outs in the data stream where there would be long streams of zeros.
Since I had had problems with the cRIO and Crucial SSD drives in the past I performed and experiment. I swapped the SSD drives out and used HDDs instead. The recorders worked until disks were full. I repeated these tests several times with similar results where SSDs would fail and HDDs would record in full.
I backed the firmware down to NI-RIO 4.0 August 2011 again on all units and retested with SSD drives. All (3) recorders would record to the end of the disk without issue. I have repeated this multiple times over the past couple weeks.
I suspect that there is a low level USB driver bug in the 2012 firmware release.
What needs to happen to get someone to look into this? I only discovered this when I loaded up a new machine with the 2012 developers suite and was forced to upgrade the firmware on the cRIO units. Running the 2011 developers suite and the older firmware is fine for now but at some point I will need to upgrade both the suite and the firmware. I need to make sure this bug gets address such that this hardware does not become unreliable in the field.
Please contact me directly if necessary.
Thanks,
Keenan Ball
Engineer
03-21-2013 02:32 PM
Hey Keenan -
I'd recommend posting this info to the LabVIEW RT discussion forum as this doesn't sound like an issue unique to the cRIO Waveform Reference Design.
-Jack