6561 TClk Synchronization Problem

[bmann2000]

Hi,

Looks like we could be close to a solution.  I tweaked the 6 binary file method until it achieved Continuous Acquisition.  With 8192000 samples per Fetch an equilibrium was reached where the memory did not deplete, anything smaller on the fetch resulted in ever decreasing memory followed by windows crashing out.  I changed the fetch samples counting to tot up 1 card only as it soon became apparent that even with I64 we'd hit a limit. It now appears I'm only limited by the available harddisk space, reckon I can get about 25 minutes which should be enough.  I've more testing to do, I'll let you know how it goes.

[gt3000]

Hello bmann2000,

Thank you for the update, as it confirms we are both going in the right direction.  

1. Has the improvement been seen by running the latest coded directly as it was posted, or is it another project that was running?  
2. Is this still with the 2GB of RAM, or has the PXI-8106 already been upgraded to 4GB?
3. Is this with the /3GB Windows XP switch in place?
4. Is this with all 6 cards?
5. How well does the code work with just 4 cards in slots 3-6 only in the PXI-1045?  

I performed further calculations based on the numbers from previous posts.

There are 3600s in an hour, and each card requires 4MB/s.  Each card will require a 14.4GB file.  Over 6 cards, that equates to 86.4GBs total.  

Based on the design of the code, the hard drive will become fragmented.  When deleting files to repeat the test, consider Defragmenting the hard disk.

There are further parts to the code that could be added when initializing to make the application more robust as well as improvements in the PC hardware on board the PXI.  The following are suggestions, in no particular order or preference, for further implementation at a later stage, once it is confirmed that the application above is operating correctly.

1. Replace standard hard drive with a new 7200 RPM or greater from a component supplier, such as Seagate.  This reduces the hard drive Seek Time.
2. Replace the hard drive with one of a much greater size that can easily fit 100GB or greater of Acquired data.  This reduces the need for defragmenting.
3. Preallocate the File Size to approximately 15GB for each file using the 'Set File Size.vi' after the 'Open File.vi'. This reduces the amount time needed for seeking or jumping between harddrive locations.
4. Preallocate a contiguous chunk of RAM for the Queue by limiting its 'Max Queue Size' to a number of samples, filling it with junk data, and the flushing it before the Producer Loop begins its task.  This ensures that no RAM is trying to be allocated during the actual acquisition as more RAM is needed.
5. Ensure effective cooling for the entire PXI by cleaning fans and filters.  All hardware performs better in cooler operating temperatures. 

 I look forward to the responses to my questions above.

Best Regards, 

[bmann2000]

Hi George,

Attached is the tried and tested code.  I figure the answer to the optimum Fetch size question is 8192000 samples per Fetch.  8192000x2=16384000bytes=16MBytes.  In practice, if you set Fetch size to 4096000, the memory gradually fills up during the acquisition.  Then anything greater than 8192000 results in an overwrite error from the 6561 card, as you would expect.  It seems reasonable that by using all the available onboard memory, you minimise the loading on the PXI Controller memory.  The attached VI will Acquire Continuously at 2M without depleting the available RAM on the controller, so we're now only limited by hard disk space, but we have enough for now.  Stripping out the unwanted zeros post-processing takes 6.2 seconds for every second of data acquired, it might be possible to optimise this code, it'll be a bit of pain waiting x6 test length between tests to free the hard drive space.

To answer your questions.

1. Actual code attached, a few mods, same structure as the code you posted.

2. Now acquiring continuously using the same original 2GB of installed RAM, more RAM not required.  Available RAM throughout acquisition is 1.2G.

3. Not implemented as still with the original 2G of RAM. Setting the Fetch Size was key to making it work.

4. Yes, acquiring continuously from all six cards at 2M.

5. Not tried it, can't be better than present.  I've not experimented with increasing the sample rate, I only need 2M.

We could have arrived at a solution sooner if we had known to give up on the Match Pattern multi-record acquisition, the TClk documentation is not clear on what triggers are supported.  Also, I'd have jumped to the continuous acquisition method sooner if the documentaion had made it clear it was possible.  I'd like to see more shipped examples for multi-card set ups, with detail on the limits.  My next job is to code for Continuous Acquisition at 100kHz with nine 6123 cards, I'll start a new thread if hit probelms, should be straight forward enough.

Thanks again for your help.

Brian

[gt3000 · Accepted solution]

Hello Brian,

Thank you for the confirmation.  I am glad to hear that you are able to progress to the next part of the application.  The feedback regarding the documenation will be fed back to the R&D group, as more and more synchronized application examples are required.  

To summarize this solution's history:

1. The post was started in order to find an example of synchronizing multiple HSDIO cards that must be checked for Pattern Matches in order to log when they occur.
2. It was concluded that NI-TClk cannot trigger from an Advanced Reference Trigger.
3. It was concluded that a Pattern Match trigger cannot be used to synchronize the trigger of Acquisition through NI-TClk.
4. The application progressed when it was decided that the total amount of data must be acquired and stored to hard disk for post-processing.
5. The application made better use of the bandwidth on the PXI bus and RAM space through a Producer/Consumer Loop.
6. Using the Digital Waveform Datatype and the TDMS file were useful starting points, however it was concluded that  using the U16 datatype and Binary Files was most efficient. 
7. The Queue and RAM were more effectively used when the data was written to separate Binary Files for each card, in multiples of 512Byte chunks of data.  This was achieved by Fetching data in multiples of 512Byte chunks.
8. The optimum number of Samples per Fetch is 8192000. 

Following from this example, I wish you best luck in the remaining parts of the application, and I invite you to keep in touch with NI Support and the Field Team.

Please keep in mind that greater performance gains could possibly be seen with some of my suggestions from my penultimate post, or by migrating to a newer PXI, or PXI-express platform, without many further code changes. 

Best Regards, 

[bmann2000]

Hi,

Yes, that's a fair summary.  It's counterintuative that you'd want to capture all them zeros that you don't want.  The very existance of the Match Pattern shipped examples and Multi-Record shipped examples leads to you beleive that's the method required.  With NIScope VIs used with the digitiser cards, such as the 5154, Mutli-Record Continuous Acquisition is the intended method of use and it works, and that's at GHz sample rates.