Writing to SD card on 9802 from FPGA vi

[TheSnark]

Hi All,

I am attempting to write to an SD card from my single-point timed loop FPGA vi. I currently have a Sandisk Ultra II 2GB SD card. I have spoken with some NI support engineers who told me I should get 2 MB/s write rate to a file on the SD card, while others have stated that third-party cards have a slower write rate. Does anyone have a definitive answer on this? If it is slower, what should I expect? I intend to write an array of 22 FXP data readings (channels) being sampled at 5 kHz. Also, are there any limitations/restrictions by using the "write" method as to file type, length, name? Thanks for the information. 

Gaussy 

[Bassett_Hound]

Hi Gaussy,

Let me give a little backgroun on the cards specification first before answering your more specific questions.  Currently you can access SD Cards in a NI 9802 module either from Mounting the Cards in RT or Directly from the FPGA.  You must do one or the other and can not access them from both RT and FPGA at the same time.  When its mounted from RT the ease of use is a trade off for performance as you will not get the 2 M B/sec typical throughput rate specified in the manual.  The 2 MB/sec throughput rate specified is only guaranteed if  your accessing an NI SD card from the FPGA. If you need the 2 MB/Sec you should use a DMA Output channel along with the FPGA API for reading and writing bytes to the card. 

While NI does not specifically guarantee the 2 MB/sec throughput for third party cards when accessed from the FPGA, I would expect that most commercial SD cards should get close to this rate.  The 2 MB/sec throughput specification is largely based on the implementation of a file IO driver for the NI 9802 card and not based totally on the on the SD card used although it does play a small side role.  Using a third party card is not without its risks, and I have personally used SD cards ( the free one out of my Digital camera) that were just slow and cheap ( and not industrial temp rated to boot).  This is one of the main reasons NI provides a recommended set of SD cards as there are many SD card vendors that have a risk of poor performance.  So, to answer you question more directly, while I believe most third party Cards should get close to the performance specified, we just can't say how good an SD card will be since we didn't test with  it and we will have to leave it up to the user to validate their SD card if they are not using an NI SD card.

Also, there are no restrictions on the type of files you can write to any of the cards.  If you mount it in RT, then you can access it like any other drive such as the internal disk, usb drive, etc..  and can use any of the File IO functions that are available in Real-Time.  FPGA is the same way, although now your a little more restricted and have to perform the byte writes yourself.  For example, you can create TDMS files from FPGA, but are required to write the header information your self byte by byte.  In fact we did this before in a demo. The file ID can be any unsigned integer value from 0 to 255 and appears as an 8-bit hexadecimal value in the filename. The name of the file is in the format CRIO-X##.BIN, where ## is the hexadecimal representation of the value you entered. The filename must be uppercase and must comply with the DOS 8.3 naming convention. If you look in the LabVIEW Help for the "NI 9802 (FPGA Interface) Help topic it will talk about the module in more detail regarding any restrictions on File Names when used in LabVIEW FPGA.

And, one more final note, is that the FPGA Write/Read methods do not natively support Fixed Point so you'll need to convert your Fixed Point values into Binary before writing the values to the SD card, and then the opposite after you read them out.  Let me know if you need help with this as I have a small VI to help with this.

Hope that helps.  Let me know if you have any additional questions.

Thanks,

Basset Hound

Message Edited by Bassett Hound on 12-06-2008 10:05 AM

Message Edited by Bassett Hound on 12-06-2008 10:07 AM

[TheSnark]

Hi Bassett Hound,

Thanks for the information. I am only sampling 22 channels on the FPGA (FXP) at 1kHz. On the real time, I want to write a DBL array with all the points into a BIN file to log all the data collected. My vi is attached. When I mount the SD card, I see the file, but nothing is in it. Is there something wrong with the way I am trying to write to it, or a throughput limitation. I assumed that at 1 kHz of a 20-array element DBL, I am looking at a 80 kB/s throughput. I am using a Sandisk Ultra II 2GB card, and I have a cRIO-9072 chassis. That seems achievable. I appreciate your help in trying to get my noggin' around this.

Thanks.

Gaussy

[TheSnark]

Hi Bassett Hound (again),

After considering my options, I think writing from the FPGA vi will be my most reliable way of logging all my data. Can you provide me an example of getting my 22 FXP point channels into a binary stream that will be supported by the Write I/O method. I am attaching my FPGA vi for your review. Any help would be approeciated. 

Best Regards,

Gaussy

[TheSnark]

Hi Bassett Hound,

After reading through the Help for the 9802 topic you suggested, it states that the 9802 SD write is not compatible with a single-cycle timed loop. Do you know why? That is how I was sampling all my analog inputs. 

Thanks.

Gaussy 

[TheSnark]

Hi All,

Well after spending the better part of the night analyzing why I cannot write to the SD card fast enough, I am hoping for some guidance from the gurus here. I now tried to write the 22 channel samples unto the SD card using a FIFO (see attached). I cannot comprehend how NI would sell a module with such limited performance for a device made for HIGH SPEED DAQ. I am truly frustrated with this problem. Unfortunately, due to time constraints, I may have to abandon the cRIO all together, and go back to using a compactFieldpoint unit. I just don't get it, 88 kB/s should be a breeze.

Anyways, thanks for any guidance, or just for reading my rant.

Gaussy

[Bassett_Hound]

Hi Gaussy,

So, I took a look at the VIs you posted and I have the following comments and some possible reasons for the performance your getting:

1.  I noticed in your latest VI your mounting the device from RT, which if your looking for 80+ kB/s seems like it should be fine, but I wanted to re-iterate what I said before.  When its mounted from RT the ease of use is a trade off for performance as you will not get the 2 M B/sec typical throughput rate specified in the manual.  The 2 MB/sec throughput rate specified is only guaranteed if  your accessing an NI SD card from the FPGA. If you need the 2 MB/Sec you should use a DMA Output channel along with the FPGA API for reading and writing bytes to the card.

2.  Refering directly to the 1.5FPGA.vi in the last post, the fastest this loop can generate data is every 280 ms as you have 4 reads from the NI 9211 Thermocouple module (each take 70 ms ) in the same IO node as your AI data.  So the loop itself is not going to be running at the 1 KHz rate your looking for just from looking at that alone.  This is most likely why you see a slow througput rate.  I did'nt run any math to see what amount of data you be getting in this loop but from your description of the loop rates its not giving you what you expect. You'll want to either read the thermocouple data in another loop or do some sort of padding from another loop if your trying to send packets of data to be logged on the host.

3.  Finally, all AI nodes are not supported in SCTL as well as the 9802 because they take longer than a single cycle to execute.  In general, only the 8 Channel DI/DO modules are supported in SCTL's.

You should be able to write an application to do what your lookig to doing.  When I get some free time this week I'll modify your last code to show how you might go about doing this so you can have a look at the code.

Hope that helps,

Basset Hound

[TheSnark]

Hi Bassett Hound,

1. I understand your point on the 2 MB/s being in FPGA mode, but an 80+ KB/s write time should be achievable from this mode, No?

2. I was told by two NI support engineers (I guess incorrectly) that if I continued to access a channel at a set rate faster than it could refresh, I would get a repeated value.  This is actually better for me, as I will be summing several channel values together (one from the 9215 and one from the 9219). So I would have to write TC values in a single continous loop, 9215 values at high data rate, and 9219 values at a 10 ms rate (high-speed) mode? I get chills just thinking on how to combine those data points to be able to write data for each channel every iteration. 

3. I assumed that the 9215s AI would be supported as they show up when you run FPGA wizard (actually, TC shows up too, so that theory is blown!).

I think I need to go back to basics to ensure the FPGA code is properly performing the functions as per hardware, and not count on what Labview's tools show as possible.

Any vis that you could provide would REALLY help get a handle on how to achieve my expected performance.  

Thank you again for your help  

PS

My setup is:

cRIO-9072 chassis with

1 9211 module (read 4 channels)

4 9215 modules (read 3 channels each)

2 9219 modules (read 3 channels each)

1 9802 module

[Bassett_Hound]

---

Gaussy wrote:

1. I understand your point on the 2 MB/s being in FPGA mode, but an 80+ KB/s write time should be achievable from this mode, No?

2. I was told by two NI support engineers (I guess incorrectly) that if I continued to access a channel at a set rate faster than it could refresh, I would get a repeated value.  This is actually better for me, as I will be summing several channel values together (one from the 9215 and one from the 9219). So I would have to write TC values in a single continous loop, 9215 values at high data rate, and 9219 values at a 10 ms rate (high-speed) mode? I get chills just thinking on how to combine those data points to be able to write data for each channel every iteration. 

3. I assumed that the 9215s AI would be supported as they show up when you run FPGA wizard (actually, TC shows up too, so that theory is blown!).

---

For question 1, yes, when mounted from RT, 80+ KB/s should be achievable.  From some of the benchmarks I've done you should be able to get upwards around 200 KB/sec on a cRIO-901x controller and close to this on a cRIO-9072.

For question 2, I'll have to assume that the NI Application Engineers where talking about Read/Write Control nodes used to read and write to front panel controls and indicators and not the IO Nodes themselves.  The IO nodes will behave as I have described above, and when you put them in data flow with your  DMA FIFO, they will need to finish execution before the data is placed into the FIFO.  Combining them into a single channel is relatively simple depending on the type of syncronization you need between all the channels.  If your okay with repeated values as you say then this should be fairly easy for you.  I've attached an image of what this would look like below.

For question 3, a Single Cycle Timed Loop is different from the Single Point Timing Engine that is used with the FPGA Wizard.  AI IO nodes are not supported in Single Cycle Timed Loops but they are supported in the FPGA Wizards implementation to generate codes.  There is some good help on both of these in the LabVIEW help if you would like additional information.  Let me know if you have troubles finding the topics as I can point a few out.

I'll post back again when I get free time to write a snippet of code for you using your code as a starter.

Bassett Hound

[TheSnark]

Hi Bassett Hound,

Thanks so much for the modified code. This explains why my attempt to write directly from the FPGA gave me such little data in the BIN file. So if I understand your example correctly, I should be able to write directly to  a BIN file by first converting the FXP to U32 and writing to the file in the for loop? This would provide me with the data I need to log. In order to convert the data back to FXP point is as simple as using a FXP conversion element on each U32 value? 

I can't thank you enough for clearing up some of the mud.

Gaussy