9802 in FPGA Mode

[Ashish_Naik_NIUK]

Hi Dom,

Thanks for getting back to me. Well I'm glad our maths is right between the two of us!

That sounds like a good idea to do the processing on the FPGA, which will help decide about the datatypes and ranges to use.

Good luck with your application and thank you for using the NI Forums!

[DominicRoberton]

Is there an interim solution button?!

I have also changed the code I was using on the FPGA write so that I am not opening the file with every single iteration.

Hopefully that will solve part of my problem.

[Ashish_Naik_NIUK]

Hi Dom,

Unfortunately not! That is a good idea with regards to only opening the file once. This should help the amount of FPGA space being used

[DominicRoberton]

Hi Ash,

I have now settled on I16 as the data format, but I am still having huge problems getting the data to write to the card.

I have produced a test vi, write test.vi which wrote data at a speed of 0.17MB/S, (I ran it for 60 seconds adn produced a file ~10MB).  I have included the vi.  I have simplified the vi further by removing all of the Maths and the FPGA LED stuff and is merely writing 1's into the file.

I am just about to test this.

To show you how the data is written in the program I am trying to run, I have included the Datato Write FIFO.vi, which takes the queue and puts everything in it 104 IO Singles inputs at 800 samples per second, by my calculation this should be generating near 332,800 Bytes of data.  This is called every half second, I have since reduced the data to I16's but it is untested.  The file Data Write FIFO.vi shows how the data is written to the SD card using the FPGA method.

In it's current form it is not very successful, it hangs horrifically.  I will try the code using the I16 data format and see if that spees things up a bit and get back to you.

I am getting very close to looking at a different method for storing the data.

Thanks for your support so far though

Dom.

[Ashish_Naik_NIUK]

Hi Dominic,

I hope you are well. Apologies for the lack of response earlier, I have been Out of the Office. I understand that you are currently dealing with the UK AE's directly to help solve these issues.

If you would like to keep both channels of communication via the forum and Tech Support open then I am more than happy to do this.

Have you got any further with regards to changing the data format at all?

Kind regards,

[DominicRoberton]

Hi Ash,

I am yes, I am calling my save function less often and have increased the size of the FIFO, althoguh I am not 100% sure how FIFO's work, adn since I have started playing about with it the compilation seems to be taking longer....

Just trying to find some info on how FIFO size affects things.

I have decided that an I16 is the way forward for what i need to do.

Cheers for your help,

Dom

[DominicRoberton]

Right an update on the problem.

After Ash's help we are now working in I16 numbers, so 2 bytes per number.

There is also a chance that the FIFO I was using wasn't big enough to carry the data I was asking it too.  It was 1023 elements (from memmory) which is the default.  I am slightly confused as the FIFO which carries the data (56 channels, 800 times a second with the data begin pulled out once a second) from the FPGA up to the RT side seems to be absolutely fine.

I am not 100% sure how FIFO's work but I am increasing the size of the FIFO.  Initially I increased it to 10,560,000 elements which should have given me at least 120 seconds of buffer time at a memmory cost of 20MB (10560000/(800x110) = 120 and 10560000x2  = 211200000 Bytes).  Hiowever this did not compile.

I have reduced the FIFO size through several steps down to 2,640,000 elements a memmory cost of 5MB, none of which have yet compiled successfully (I am waiting on the 2,640,000 compilation though, an hour and a half and counting!!!)

Am I doing something fundamentally wrong with the FIFO's?