Driver Support PCI 5102

[becktho]

Hi

I'm thinking about using DAQmx instead of the traditional drivers.

In most of the projects where I have to acquire data, we use the NI PCI-5102 digitizer.

If I look a this page to check if it works with DAQmx, I can't find the device.

Is there anyone who can tell me if it works?
And in addition - why is this device not on that list?

Thomas

[DFGray]

The 5102 is a high-speed digitizer, so the API of choice is NI-SCOPE. This will usually give you the best features and support and allow almost seamless transition to any other NI high-speed digitizer. The 5102 was the first NI high-speed digitizer, so, by a quirk of history, it is also programmable using traditional DAQ. It cannot be programmed using DAQmx.

[becktho]

Thanks for your answer.

So I'll have a try using NI Scope.

As it sometimes happens the data acquisition was designed by a former colleague using traditional DAQ. I never thought about changing the acquisition driver.

Could you point out the main advantages I have if I use Scope instead of DAQ?


Thomas

[DFGray]

DISCLAIMER - the following opinion is mine and not the official NI party line.

I think there are two main reasons for using NI-SCOPE. First, you get a seamless upgrade path to other high-speed digitizers. This is similar to the flexibility to change DAQ devices without changing the code. Second, and more importantly, you get access to the measurements capabilities. NI-SCOPE allows you to fetch things such as pulse parameters or FFTs of your signal. There are about 40 scalar measurements and 26 vector measurements. These can be averaged and you can fetch the statistics as well. One possible final reason for using NI-SCOPE is that NI-SCOPE is still under active development while traditional DAQ is in maintenance mode.

When I was programming it, some of the more advanced trigger modes were not supported under NI-SCOPE. This may have changed, since some of the newer high-speed digitizers also support these advanced modes. If you are doing normal triggering without any gating, this will not be an issue.

[becktho]

Hi DFGray

I'm looking at a vi I made months ago to acquire data with a NI-5102. I'd like to change it from traditional DAQ to SCOPE vis.

I'm wondering if there is a way to trigger a signal and start acquisition before the trigger occurs? This was possible using traditional DAQ (pretrigger scans was the key).

Is this possible and if it is - how do I have to do it? Are there any example vis?

Thanks in advance.

Thomas

[DFGray]

The default mode of NI-SCOPE devices is constantly running and acquiring data. However, this is only somewhat true for the 5102. It starts its acquisition clocks when you initiate an acquisition, since it is based on the older E-series DAQ architecture. Once you initiate an acquisition, the device starts filling a ring buffer until the trigger is received. At that point, it completes the acquisition and stops. So, to do what you want.

1. Set the reference position using either the niScope Configure Horizontal Timing.vi or the property directly. This will determine where in your data set the trigger occurs. You can set the number of sample points (record length) at the same time if you use the horizontal properties VI.


2. Initiate an acquisition using niScope Initiate Acquisition.vi. This will start the clocks running. You can probably do this with a hardware trigger, also, but it has been long enough since I tried anything like this that I don't want to speculate. Look in the synchronization properties for possibilities. Note that many of these properties are specific to particular NI-SCOPE models, so be sure you read the description of each before using it. Because of the model specificity, some of them are also overlap in functionality. Yes, it is somewhat confusing, which is another reason I didn't want to stick my foot in my mouth and give you a wrong answer. I could not find any examples of hardware initiation. NI-SCOPE examples can be found with the NI Example finder or in /examples/instr/niScope.


3. Once you have initiated the acquisition, you can either fetch or poll for status. The fetch will wait up to the timeout period for the acquisition to occur. Polling for status allows you to wait forever. Do a fetch with no timeout when status indicates the acquisition is done.

The examples I mentioned above will get you started using NI-SCOPE, if you need a jumpstart. If you have any further problems, let me know.

[becktho]

Hi

I just wanted to tell you that I got it working finally.

I just had one problem - I wanted to acquire about 700000 datapoints first. No trigger just simple acquisition. I used niScope Auto Setup.vi followed by niScope Read WDT.vi, where I wired the value 700000 to numSamples. After executing the operation I just got a waveform with 1500 datapoints.

To solve the problem I replaced niScope Auto Setup.vi with config vis vertical and horizontal timing, which resulted in a waveform with exact 700000 datapoints.

What was wrong with my first attempt?

Thomas

[DFGray]

The number of points acquired is set by configuration VIs (autosetup, property node, or configure horizontal). So, in your first example, the autosetup set the number of points to 1500 (autosetup will usually set somewhere between 500 and 2000, depending on your waveform). When you requested 700000, it gave you all it had - 1500. In your second example, you told the driver to acquire 700000 points, so when you fetched it, it was there.

numSamples on the fetch VIs is there so you can fetch less than you acquired or fetch a subset. Wiring a -1 into it returns all available samples.

One last point - be careful with that 700kByte wire. If you run into memory problems, let me know. There is a lot you can do to solve them.

[Paul0]

In the previous message, you suggested you might be able to help with memory issues. I think I may have a memory issue where the DMA feature of the PCI board appears to be not working. Here is the situation.

I recently upgraded to NiScope 3.4 previously I was on 1.51 from memory. After the upgrade and a work around for a problem in autosetup, the rest of the process appears to work, but it is extremely slow (many seconds to obrtain data.) In my process, after the autosetup which is used to find which channels are active and their vertical range, I apply a Bessel Filter, change the record length and number of samples to larger values and change the sample rate. Memory is allocated to the new waveforms via the C++ malloc function. In the old driver using niscope-32.lib, the samples were made in about 1 second. With the new driver using niscope.lib, it takes forever.

Can anyone help find a solution to get the new driver to perform as well as the old?

My setup is the following:

NI-5102 PCI board

Windows XP

2.53 Gb Pentium processor

500 M Ram

[jaced]

Hi,

I suggest trying to run an example program which can be found in the following location.

Another thing you can try is using the NI-Scope soft front panel. Performing both of these tests will give us more insight into exactly what is causing the decreased performance. An overview of exactly what you are attempting to do would also be helpful in troubleshooting this issue.

Message Edited by jaced on 02-04-2008 12:22 PM