This thread is dedicated to discussion and feedback around the tutorial Getting Started with CompactRIO - Logging Data to Disk.
Please post any questions or comments here.
At step 6, IIRC, it suggests setting to "syncronise with scan engine" - however this is greyed out on my system. Is this due to the presence of some non-realtime modules in the crio (9022 controller, modules such as CAN, RS232 and SD datalogging are not compatible IIRC) or am I missing something? The chassis is configured (right click>properties) as Scan Interface, not FPGA.
CAN, Serial, and SD datalogging modules are not compatible with Scan Mode on the cRIO. This is why the option is grayed out for you.
It is true that those modules are not compatible with the scan engine, but that should not gray out the option.
Are you sure your VI is under the real-time controller and not the FPGA or your My Computer target?
I've a 9114 chassis with a 9022 controller, as yet blank as this is my first attempt at using it. I've tried removing the non-compatible modules (not required at the moment anyway) and run through this tutorial again. During the target detection stage I chose as per the instructions in the tutorial but what pops up into the project explorer is:
NI-cRIO9022-serialnum (192.168.1.100, Real-time features not available).
At no point do I get to choose programming model, but...
Right clicking on the chassis "cRIO9114" > properties brings up Chassis Configuration, with Programming mode "Scan Interface" selected.
I'm clearly doing something wrong but I've not quite figured out what yet!
OK, solved the initial issues - it seems that there was some sort of version conflict, some serious software removal/registry hacking/reinstallation solved that! Now I have another question!
In point 14 you take the "Build array" output and feed it into the buffer. The tutorials buffer has an orange arrow on the left side to accept data. Mine doesn't, it only has an error input on the left and a data and error output on the right. I can't connect the append array output to the variable/RT FIFO. Likewise, I've no idea what function is used for the timeout on the while loop copy of the buffer - there's no timeout function available in the functions pallet - I presume it's one of the other timing functions but which one?
I'm having a little trouble manipulating the FPGA version of this to suit my needs, is there any chance of a hand from the more experienced?
I've modified the FIFO to signed 38 bit with 5 bit integer word length so that I can pass values from two fixed point sources (a +-,32,-1 and a +-,16,5 datatypes). I've extended to number of elements of the FIFO as I've 6 channels to log at once.
I've found that the results come out in a somewhat confusing fashion. The numbers look, considering the test bench is not powered on so sensors are returning "0's", approximately right - i.e. I've two very close very-low-value numbers from two cold thermocouples (channels 1 and 2) and the rest look just like standard noise on the second module. The only problem being that they are not ordered in rows in the TDMS viewer:
<chan 1><chan 2>......
They're ordered as columns, with columns 2-6 null.
<chan 1> 0 0 0 0 0
I'd assumed this was the transpose matrix block and removed it, but the results are identical?
Secondly, with my required values the system only runs until the number of elements specified in the reshape array function is met, then it stops plotting them and times out and I'm struggling to identify the cause. I've tried adjusting the size of timeouts and the number of items read from the FIFO but with little help.
My current situation is attached. As a note - what I'd like to achieve is 5-10khz sample rate of all 6 channels, logged for later viewing but with the results displayed at least at 1hz on the host computer.
Any help spotting where my simple mistake is would be greatly appreciated, I'm starting to go round the bend.
I took a quick look at your code, and the first thing I notice is that you are pulling 2000 elements off the FIFO, and then trying to put it into a 6x2500 = 15000 point array. I would recommend pulling 2100 elements from the FIFO and putting it into a 6x350 = 2100 point array.
The other problem I think may be with the example. Since six points of data from the FPGA are going into one FIFO, the data coming out of the FIFO is ordered like so: ch0|ch1|ch3|ch4|ch5|ch0|ch1|ch3|ch4|ch5|ch0|ch1|ch3|ch4|ch5, etc. The way that the example has it, the first 250 samples are read as being from ch0, the next 250 as from ch1, etc. This is incorrect and why you see your TDMS file the way you do. You will either want to decimate the array and rebuild it, or set the TDMS file to interleave. See the figures below for example block diagrams.
Decimate and rebuild
Reshape and interleave
This should help with the first two issues you are facing. As for the timing of the VI, you currently have the RT VI's loop going at 1kHz, so you may want to slow it down a little, although not enough for the FIFO to overflow.
National Instruments | Applications Engineer | www.ni.com/support
Thanks for the help with structuring the data - it's fine and sorted now, and makes much more sense!
My timings are really confusing me. At 500uS loop timing on the FPGA sampling 6 channels I should be seeing 12,000 samples a second entering the FIFO, which has a size just over 8000 elements. Assuming I loop the logging loop at 150ms and read 2100 elements per loop I should have a read capability of approx 14,000 (2100*(1/.15)) so the fifo should never overflow, and a timing of 150ms is fairly long/slow so it should not time out. What seems to happen is that the FIFO overflows immediately (obviously, because the recording VI isn't running yet), but as soon as I fire up the recording (RT.VI) it runs for one FIFO.read timeout period, returns all of the 2100 elements but times out.
Does the FIFO.read wait for it's timeout or does it return once it has filled? If it returns once it's full I don't see why it's allowing overflows or timeouts as there should be more than sufficient data to have a full 2100 element return for at least the first 3 cycles. I do find this graphical environment less intuitive than C!