You may have better luck posting this question in the Real-Time Measurement and Control board for answers specific to acquisition with a cRIO controller. I would make a new post in that board to ensure possible solutions are related to your hardware. I included some documentation below for synchronizing on a cRIO controller. cRIO Scan Mode only goes up to 1 kHz so you will need to use the FPGA interface in the article below.
As I mentioned previously, I would create a new post in the Real-Time board if you have any additional questions about information in the above article.
Chris D. | Applications Engineer | National Instruments
Are you doing any processing as well?
I would suggest it is risky though I've not got any benchmarks for these controllers. The question is what you need to do with it? If you can use some triggering on the FPGA that would obviously make things much easier on RT
As luck would have it I have a 9064 in the office so I did a quick benchmark.
I don't have the modules so I have a for loop generating 32 samples at 100kHz. Acquire through the FIFO and write to an array (not graph) display and run that interactively.
It is using around 52% on both CPUs on the controller doing that so it is high if you need to do a load more processing - if the processing is simple you may get away with it.
Attached the project for reference.
Thanks, James. Yes, there is some processing.
First, not 100 kS/s is used but slightly lower value sampling frequency, e.g. 98987.7 S/s. At that frequency, all 32 signals are sampled and passed through a zero-phase high-pass filter of a given order, such as 8, having the limit frequency between 1, 2 or 3 kHz. The filtered signal is squared. The resulting signal is decimated with averaging by a high decimation factor, e.g 41. Optimally, all this should run continuously.
Simultaneously, in all 32 channels, segments of 2000 values are cut out (in a way not to loose any point) and are fed into the averaging loop. The resulting averages in the 32 channels are the result which is sent from 9064 to a controller.
If this does not function, the number of channels would be lowered, e.g to 24, or even to 16 when only one 9220 would be used. If that would be too much, only 12 of one card might be used.
What might be your comment?
Thanks in advance.
I couldn't guarantee anything but I think you could do quite a bit of processing in the FPGA which makes me think it could work.
The sum part of the averaging could happen on the FPGA, no need to transfer all the data to the host. You would need a local FIFO for the history so would potentially need 32ch*20bit fxp*2000 sample BRAM - check the FPGA specs on this.
The filtering and decimation will help a huge amount! The filters can use quite a bit of resource but I have used the digital filter design toolkit to implement filters and it has a few options for minimising usage. Worst case you can expect to use 32*8 order DSP (if you can keep the numbers small enough). This may be too many but if you can reuse resources between channels it might fit. Again check the specs and see how that looks.
It won't be simple but it may be possible. The question is why the 9064? If it is cost you might be better off making it easy on yourself if it is a one off development.
The entire system consists of 3-12 pieces of 9064 with 9220, each 9064 wls coupled with a 9063 (which serve only one 9215 and one wireless module). I wish to minimize the total cost by effectively using all the resources. That is why I think of the two smallest cRIOs - 9063 and 9064. While 32 channels is a wish, I may limit this number if necessary.
I imagined filtering, squaring and decimation done in the FPGA but I thought that averaging must be done in the RT. You suggest everything to be done in the FPGA. That would be perfect. As to the rate of the output data from the FPGA, it would be lower than 70 kSamples/s without averaging (number of averages =1 as a wished lower limit) or 0,7 kSamples/s with typical averaging over 100 packages.
Please comment on this.
Yes FPGA for the filtering and decimation would be the biggest help.
The averaging is not the FPGA's strongest talent but it can help in the right circumstances, the problem is typically the storage and actually I think you may not have enough in this case having looked at the specs after that message. Assuming perfect storage and if we drop the samples to 16 bit then you are looking at 32x16x2000 bits or about 1Mbits. The cRIO 9064 only has 4480 kBits so actually this will not work on the FPGA for 32 channels - sorry to get your hopes up!
For the filters I mention the DSPs. You have 220 on the cRIO so at 32 channels you would need the filters to fit to 6(.8) DSP blocks per channel which should be achievable with the digital filter design toolkit implementations at least so that bit could work. You would also need DSP for the squaring but if you do this after decimation you could loop all channels through one to minimise the impact.
My benchmark was getting data from the FPGA at 100kS/s so with this decimation my benchmark numbers may drop significantly so it seems like you would have room. Again there is often more complex effects to consider than just these simple numbers so I couldn't guarantee it but it seems like 32 channels of filtering and decimation would be possible on the FPGA and the RT handling the averaging -with some good FPGA programming techniques.
One thing I would say if you are building a few units is start with one in case a) you cannot fit it all or b) You may be able to get the 9064 to perform both functions and save a chassis?
The decimation (with averaging) comes after filtering and squaring, thus we must square all the data.
How would DSP be used for the filters? Can you access the achievable order of the high-pass filters?
As to two units - you mean those 9063 and 9064? -, they cannot be reduced to one: 9063 is installed on the rotating shaft and is connected to 9064 in the non-rotating space wireless.
Ah I'm guessing you are squaring in order to average AC waveforms so that makes sense then.
Normally with a filter on FPGA you need one multiplier block per order. Each DSP can multiple 25bitx18bit so I think your input will be 20bit FXP so as long as you keep your filter coefficients to 18bit or less then you normally need 1x DSP per order. However, DSPs can run much faster than 100kHz so the algorithm can be built to reuse multipliers between channels or for multiple orders.
There are tools in LabVIEW digital filter design toolkit to have it build the FPGA filter for you. It's not the most user-friendly workflow but you can. When you generate the FPGA code you can select different implementations which will trade off speed for DSP blocks so hopefully you should be able to implement a higher order filter but with far fewer DSP blocks used which would make what you need feasible. I would suggest looking at this anyway because I believe you needed a zero delay filter which requires an FIR structure but the standard FPGA filters in LabVIEW are IIR and will distort the phase relationships.
That makes more sense about the two units then!