FIFO settings, cRIO, 9219

[JBGU]

Hi again,

I'm building up my time on LV (2009), completing a few tutorials but I've a deadline to hit how so I'm trying to get this nailed. I've followed the example I found online for FPGA datalogging:

http://zone.ni.com/devzone/cda/tut/p/id/11198

After I tried the scan mode version I decided it was too slow to catch one of my sensors, hadn't spotted the 1khz limit, and built up the FPGA example and tried to modify it to suit my needs. I noticed that in the original, the data in the log is transposed - this comes out in a very odd way in my TDMS file, with each channel containing a cyclic sample from all channels. I removed the transpose operation and the channels seem to log fine at the current point in time. I've got two modules feeding the array creator, one is a 9201 and one is a 9219 in thermocouple mode.

I've a few questions regarding the whole setup as I feel my lack of understanding isn't helping me create this very well.

The FIFO settings are not overly self explanatory, even with the help file. Even the example said "chosen by reading the help file" but didn't even begin to explain why it picked the numbers it did based on the data being transmitted, or how that would change if I changed to use thermocouples for example, instead of normal analogue ins. I'm looking at 4 channels of 0-10V and 2 channels of 9219 thermocouple output, all of which I'd like to have both logged on the RIO internal mem, and displayed (even if the display is only updated once a second, its just for keeping an eye on the process) on the host PC.

I know the 9219 won't keep up with khz sampling, but what will it do if I loop more rapidly than its limit - will it just return the same value until the next conversion is obtained?

I've attached my modified VIs in case it helps identify any mistakes - I don't expect anyone to re-write it for me, just some pointers as to the above problems so I can get it clearer in my head. It seems to be taking me a while to get my head around the terminology and concepts on LV as I'm more normally lost in realtime linux back-end code, switching between the two is causing me grief! It doesn't help matters that it takes 25 minutes to compile anything FPGA related, on this machine!

[jkurtw]

Hi JBGU,

The FIFO settings just need to match the data type of whatever you are pushing through it. In the example you referenced, the C Series module returns I/O with those fixed-point settings that match the FIFO. You can use the Context Help window and hover over a wire to get its datatype. 

If you had multiple datatypes, you would need to type cast them to a common type, push them through the FIFO, then cast them back to the correct type on the RT side. Make sense? You just have to keep track of which sample is from which channel by deciding on how you interleave them into the FIFO. Another option is to use two FIFOs if you can spare another one. You have three total on cRIO and scan mode uses up two of them, however, it sounds like you are not using scan mode.

If you oversample the 9219, yes it will return redundant data.

Does that help?

[JBGU]

Hi, thanks for the reply - sorry, I've been away so not got back to you.

The modules I'm using both output FXP, but one +-,32,1 and one +-,16,5. I do have spare FIFOs but if I can use one for simplicity it makes sense, so how do I move from the previous info about the data types to the FIFO settings? I'm using an FXP FIFO, signed, and 32bits word length to enclose up to the maximum module output length of 32 bits, but what is the "integer word length" value, in relation to the data I'm sending? In the example I've worked from it was 5, but I'm not sure how this was derived from the data being stored/passed.

Cheers!

[JBGU]

OK so I've identified, after running deeper into the help files, that I probably need 38 bit word length, 5 bit integer word length as this would allow the encompasing of both of the data types. However I'm still getting odd results (numbers in one channel and 0 in all others) and FIFO timeouts/overflows. The plot thickens!