Some general question about data logger parameters

[RangerOne]

Hello!

I am trying to find some cheap data logger solution (cheap mean cheaper than we are using right now). I need these parameters: sampling frequency – 10kHz, measured signal – voltage from -10V to +10V, number of channels 64 differential or more, time of one log 2sec. I have to make measurement for all channels simultaneously. It is mean, for one measurement cycle, I have to save 2sec*10kHz=20k samples for each channel, and 64 channels * 20k samples = 1 280 000 samples from all system.  First idea was try to use M-series multifunctional PXI-DAQ (because I have some experience with multifunctional DAQ and this data logger will be used simultaneously with some other PXI system, with available chassis slots). For using multifunctional DAQ for data logging I need devise with memory enough for 20k samples for each channel. All multifunctional DAQ devices which I have looked have not enough memory (512-1024 samples). After I start reading some guides from NI site, and I have found that there are no any M-series multifunctional DAQ based data loggers. After, I decide that good solution for me it is Embedded Data Logging System based on cRIO platform (between proposed options: Low-Cost Portable Data Loggers, Programmable Data Loggers, Wireless Data Loggers, Embedded Data Logging System  only last provide a lot of channels).

My first question is it adequate chooses for this data logger, or PXI platform can provide the same logging?

I have used cRIO advisor for made my own configuration of Data logger system. I have tried to use the cheapest components:  Real-Time Controller - NI cRIO-9012, CompactRIO Reconfigurable Chassis - cRIO-9111, and four Analog Input Modules - NI 9205. Is it all necessary for data logger or I need some another modules? (Like external memory or another)

I am really like this solution because it is more than two times cheaper than we have right now, but because I have not any experience with cRIO systems, I have some general questions about how it is work. Main question: where I can save data? Is it the DRAM memory of Real-Time Controller? If yes, what is limitation of memory? For save data from 16 bit ADC and 16x4=64 channels, I heed 16bit*1280000samples = 20480000 bit = 2560000 byte = 2500kbyte= 2.4 Mbyte of memory. Controller cRIO-9012 has 64 MB DRAM, it is more than enough, but can I use all of it, or I have some limitation? The another question – for simultaneous sampling I have to send 64 samples simultaneously, it is mean, that I have to send 64 * 16 bit = 1024 bit = 128 byte from Analog Input Modules to Controller. It is not a lot, but what is the limit for sending data from Analog Input Modules to Controller? Is it possible that with using 8-slots chassis and high resolution ADC I will get a problem with sending data Analog Input Modules to Controller?

Thank You.

Message Edited by RangerOne on 02-03-2010 06:56 PM

[ManLongAtNI]

Hello RangerOne,

From the mentioned specifications either of the M Series/X Series DAQ will satisfy your requirements.  Due to the high channel count you are requesting, my recommendation would be to go with two PXI/PCI-6255 devices. I'm not sure what you mean by simultaneous sampling, in which if you need true simultaneous sampling, each channel requiring its own ADC you may need to consider S-Series. I'm unsure of the memory (512-1024 samples) reference you made in the above post but it's likely specifying the Input FIFO size. Keep in mind that the samples retrieved do not stay in that memory location, so your memory storage concerns shouldn't be a factor. In a buffered acquisition, data is moved from the DAQ device's onboard FIFO memory to a PC buffer using DMA or interrupts before it is transferred to application memory. 

With that in mind, it sounds like you only need a pure data logging system. You probably wouldn't have to consider the mentioned cRIO system. But to address your memory concerns, the DRAM like  the RAM on any PC and is reserved for the  processes. In any case, your memory concerns in this aspect also shouldn't be a factor but keep in mind that programming this would take some RT and/or FPGA knowledge. If you have taken an interest in the 9205 (also not simultaneous), but do not wish to pursue FPGA & RT programming you can use a 9178 with multiple 9205s. 

[RangerOne]

Glen, 

Thank you for answer and advice.

About simultaneous sampling, each channel must measure at the same time, and it is possible to use Simultaneous Sample and Hold or Multi-ADC devices (http://zone.ni.com/devzone/cda/tut/p/id/4105). After my searching, I have got, that best devise (number of channels/cost) is PXI-6123 S-Device.  As some alternative I am thinking about PXI-6143 (only one thing not good voltage ~5V).
About “memory (512-1024 samples)” you are right – I meant FIFO buffer. More interesting, that PXI-6123 has a 32Msamples FIFO.  And I have a couple questions:

1. Is this buffer one for all channels (each channel has 32Msampl/8=4Msampl) or each channels has 32Msampl. Buffer?

2. What is the sequence of data acquired in FIFO? Is it first channel will be first, second channel will be second… or some other? Is it possible to control this sequence with LabView?

In the PXI-6123 specification it is said: Data transfers: DMA, Interrupts, programmed I/O and about “using DMA or interrupts before it is transferred to application memory”:

3. What is the mechanism in LabView to control type of Data transfer? Is it possible to choose it (DMA, Interrupts, programmed I/O)? Or all it hided inside LabView and I do not need to worry about this?

4. Am I need Real Time software to use DMA Data transfer and FIFO or LabView full development system will be enough?

From the beginning I have wrote about 64 channels, but it is some kind first step. And in nearest future I will need up to 256 channels – typical configuration (and after up to 512 channels – maximum configuration). And more important thing, which I have not written: all system must work from external digital triggering. Exactly: during normal condition system must get data and show it on screen, or save of Disc (this data are not very important), but after external signal – system must write 2 sec of samples with 10kHz sampling frequency from all channels.

So I have some questions about DAQ system.

First of all – all modules (6123 and 6143) has 8 channels, it is mean, that I need 32 modules for typical configuration and 64 for maximum.  I still have not any final decision, but my plans: take 2 (4 for maximum conf.)  PXI 18-slots chassis and make daisy – chain configuration. “Master” chassis will have PXI controller, 16 ADC devices, and NI PXI-8331 MXI-4 module for chassis expansion. Al other “Slave” chassis will have MXI-4 module in the first slot and again NI PXI-8331 MXI-4 module for chassis expansion (expect last chassis). My questions:

5. Am I need for this data logging and for opportunity of DMA data transfer and using FIFO the PXI Embedded Real-Time Controllers (like -  http://sine.ni.com/nips/cds/view/p/lang/en/nid/11154, for example NI PXI-8110 RT ), or it will be enough PXI Embedded Controllers (like - http://sine.ni.com/nips/cds/view/p/lang/en/nid/10485 for example NI PXI-8110?

6. After external triggering the data sampling will be synchronized automatically? (synchronized I mean that all channel from all chassis will take data at the same moment, like first sample at 0 sec, second sample after 100usec (10kHz~100usec), third after next 100sec (or 200 from 0sec moment) ets.) Or I have to make some additional things for this synchronization?

Because I am planning to increase the number of devise, I have to make estimation of used throughput of bus. For the max configuration system must write 512*16bit*20000= 16384000bit= 20480000byte= 20000kbyte~ 19,5Mbyte. And I need bandwidth 19,5Mbyte/2sec=9,77Mbyte/sec – for all data. Because the  theoretical maximum bandwidth of PCI bus is 132 MB/s that translates to 110 MBytes/s of sustainable practical throughput (http://zone.ni.com/devzone/cda/tut/p/id/7700) but, because I have a MXI-4  modules I cannot transmit data faster than 78Mbyte/sec. It is looks like using this configuration good for me, and, theoretically, I can increase the number of channels, and the limit is 512*((78Mbyte/sec)/(9,7778Mbyte/sec))~4000 channels.

7. Is this estimation correct, or there are some factors which not allow me to get 512 channels?

P/S/ I started this topic in Real-Time Measurement and Control, but right now my questions about Dynamic Signal Acquisition. Am I needed to ask the questions at Dynamic Signal Acquisition (to close the topic and create the new)?

[ManLongAtNI · Accepted solution]

Hello RangerOne,

1. Yes, the buffer is shared across all ADCs.
2. The sequence is totally random and enters the buffer whenever available.
3. The DAQmx driver typically handles the type of data transfer but you can use the AI Data Transfer Mechanism Property to configure the type of transfer.
4. You do not need real-time software to utilize DMA transfer, this is a function sourced from the DAQmx driver level.
5. Your application doesn't appear to need deterministic control so a RT system is probably not necessary. The testing parameter stated in the first post suggest the hardware timing in the DAQ devices should be suitable for your application.
6. The DAQmx driver will synchronize the sampling clock through the backplane of the chassis

Due to type of question this post has translated itself to, you may get better visibility by posting to the appropriate forum.

[RangerOne]

Thank You, Glenn.

I have not any questions.

Message Edited by RangerOne on 02-09-2010 07:05 PM

[reddog]

A little more elaboration on some of your questions:

2.  The sequence that data is acquired is configurable through the driver.  It's determined by the order you add channels to the acquistion task.

3.  This is controlled by the driver, but you shouldn't have to worry about it.  By default the driver will use DMA to transfer the data.

Concerning your overall architecture:

I don't believe there is a difference in the controllers you provided links for.  Choosing one vs. the other simply dictates what OS gets installed before shipping (Windows vs. real time) and what licenses you're granted.  Since the cards you're currently looking at are PXI cards (not PXIe), you'll want to make sure you purchase a PXI backplane with a compatible PXI controller (again not a PXIe controller).  Since you're looking at an 18 slot chassis, the PXI-1045 looks most appropriate since all 18 slots are compatible with PXI cards.  If you choose one of the other 18 slot chassis, you won't be able to fill the entire chassis with PXI-6123 cards since some of the slots can only accomodate PXIe cards.  

Other factors when choosing your controller are whether you want to go with an embedded controller or  remote/rack mounted controller.  Embedded controllers are housed directly in the chassis while remote controller are generally linked to the chassis through a MXI card.  You can then connect to a rack mounted controller such as the NI 8353 or a desktop PC.  Embedded controllers generally have a smaller footprint but can have more limited capabilities (processor speed, streaming to disk rates, etc.) compared to the latest desktops.  They also eliminate the need for a MXI link which can be a limiting factor when pushing the upper bounds of the transfer rates across the bus.  Remote controllers will usually give you a performance boost compared to what you can achieve with an embedded controller, but the additional MXI link can become a limiting factor depending on your system architecture.

In terms of synchronization, the driver will automatically take care of synchronizing all S Series class devices within a single chassis.  Since the PXI trigger bus runs across the entire backplane, the driver will automatically phase lock the devices to a common reference clock on the backplane and route the appropriate trigger signals and clocks to all of the devices.  However, this trigger bus only spans a single chassis so you'll need some more hardware and will have to do a little more programming if you want to have things perfectly synchronized across all chassis.  From your post, it sounds like you basically want to wait for a trigger signal, acquire up to 2 seconds of data, possibly log the data, and repeat.  If this is the case, you might decide you can live without perfect synchronization.  If you route the trigger signal to each chassis, they should all start at the same time (perhaps 50 - 100 ns of error).  Once triggered, each chassis will gradually start to drift from each other since they are running off of different clocks with different oscillators.  However, the accumulated error over 2 seconds should be relatively small (around 50 microseconds if I did my math right).  You can look at the specs for the 10 MHz clock on the PXI-1045 chassis if you want more information on this.

If you want synchronization better than this or if you think you might want to someday acquire continuously or for longer periods of time, you'll need to look at purchasing a timing and synchronization card for each chassis so you can share and distribute common clocks and triggers to all of your chassis.  You'll want to look at either PXI-6651, 6652, or 6653 depending on the precision you need and the number of chassis you want to synchronize.  Of course, this will eat up one of the slots in your chassis and may require you to recalculate the number of chassis needed to support your maximum configuration.  I would recommend you look at the following article for an overview of a system architecture for accomplishing this.  The article references our DSA devices instead of S Series, but the general principles should still apply.  At the bottom of the article, there are links showing system architectures that can accomodate 570, 3300, or 13000 channel systems.

Your general bandwidth calculations look correct.  Unfortunately, things may not be quite that simple.   If all you care about is repeatedly peforming finite acquisitions (not continuous) and you don't have any hard requirements for how long it takes before rearming for the next acquisition, things are relatively straight forward.  In this case, PCI bandwidth isn't a factor as long as your sample size for all channels fits within the onboard device FIFO.  The device will simply backlog the data in the FIFO until it has an opportunity to transfer the data across the bus.  Once your sampling size becomes larger than the onboard FIFO, you get into a continuous sustained streaming scenario where the sustainable bandwidth is system dependent (you're automatically in this scenario with the 6143 since it has a much smaller FIFO ~8 kS). 

If you need sustainable streaming, things can get a little tricky.  Published numbers for PCI bandwidth generally assume a single device transferring data as fast as possible and don't take into consideration things like arbitration when multiple devices are requesting to use the bus at the same time.  Under heavy contention, total bus bandwidth can drop to as low as 30 MB/s or less.  Much of this depends on the topology of the PCI bus created when putting together your system.  From a PCI level, the PXI-1045 consists of 3 PCI bus segments daisy chained together.  Since devices in bus segments 2 and 3 are further away from the contoller, they generally have lower sustainable throughput than devices plugged into bus segment 1 since their data has to travel through more bus segments.  If you end up daisy chaining your chassis together, make sure you place the MXI cards in bus segment 1 of your chassis to form as much of a "star" topology as possible.  If you daisy chain all your chassis together by putting the MXI card inside the third bus segment, things can start to deteriorate pretty fast since the number of bus segments between the card and controller could be as high as twelve for a four chassis system.

With all of that said, what you're trying to do can definitely be done.  We've had customers build similar systems with up to 4,000 channels with architectures like those referenced in the article.  It's simply a matter of what tradeoffs you're willing to make to hit your price vs. performance requirements.  Regardless, I would definitely contact your field sales representative before making any final decisions so they can walk you through the finer points and make sure their aren't any surprises.  Good luck!