PCIe 6537 Digital Data Acquisition (External Clock) using MATLAB

[razor149]

Hi,

I am currently performing the following task using the PCIe 6537, using Signal Express. That has given me quite a bit of issues.

http://forums.ni.com/t5/Digital-I-O/Buffering-Working-of-NI-PCIe6537/m-p/2055570#M16171

Now I switched to MATLAB trying to connect the PCIe 6537 and perform the same tasks in that environment. I am using MATLAB 32 bit R2011b.

Reading MATLAB's Data Acqusition Toolbox user guide, and a lot of other sources I have realised that PCI3 6537 uses the Legacy Interface, which does not support Externally Clocked Acquisition! Session interface cannot be used because it does not support PCIe6537.

NI DAQmx Tools had been developed in 2007, and I am afraid that even those are of no help now.

I had the following questions to MATLAB and LabVIEW Engineers: Is there any way I can achieve what I am trying to do using the setup I currently have?

Is there any way I can make MATLAB call the functions of DAQmx, totally independent of the Data Acquisition Toolbox (Since its anyways of no use in Hardware clocking).

So basically, MATLAB will do just the displaying. NI DAQmx will do all the data acquisition at the command of MATLAB.

( These pages have not helped in my case, sadly: 

http://forums.ni.com/t5/Multifunction-DAQ/Use-M-Series-cards-with-DAQmx-in-Matlab/td-p/185232

http://www.ni.com/white-paper/3005/en

)

Please help.

Thank you.

[timtamslam]

Hey razor149,

I hope you're doing well today. To start, I'm confused by your statement regarding legacy interface and no external clock. In your previous post it looks like you are using the DAQmx 9.5.1 driver which does support external clocks.

http://zone.ni.com/reference/en-XX/help/371893D-01/6536and6537help/sample_clock/

I could be confusing your statement though. What you could mean is that the Data Acquisition Toolbox only supports the legacy commands for the PCIe 6537. Could you possibly point me to the documentation that you're referring to which explains this external clock limitation?

I'm not extremely familiar with the setup that you're using and how simple it is to implement through MATLAB ^® as most of the experience you'll find in these forums is specific to LabVIEW or SignalExpress. However, I would suspect that he highest level of support you will see from the DAQmx Tools is that latest 2007 version.

The big question in my mind is, why exactly are you interested in using MATLAB ^® software for your setup? I guess I am confused as to the benefit of using that environment to command your acquisition instead of SignalExpress.

I hope this information helps. Let me know if you have other questions!

[razor149]

Hi Tim,

I am sorry for the confusing post.

My setup with Signal Express is okay. No issues with the setup at all. It is a different thing that recorded results are a bit weird, but thats not the concern in this particular post. But that I will come to later, after this post is answered.

My question here is as follows:

http://www.mathworks.com/products/daq/supported/ni-daqmx.html#PCI-Express

Here it is said that the MATLAB DAQ Toolbox talks to the PCIe6537 using the Legacy Interface (L).

But, in the following link:  http://www.mathworks.com/help/pdf_doc/daq/daqug.pdf

Please refer to page 2-17.

You will find:

"Note Digital line values are usually not transferred at a specific rate.
Although some specialized boards support clocked I/O, Data Acquisition
Toolbox software does not support this functionality."

_______

So now this is the issue. In my current Signal Express  setup, I give a clock to PFI5, and data to one of the port pins on PCIe6537. This data is read by Signal Express, and this data-read event is triggered on the rising edge of the clock on PFI5.

I want to do the same thing with MATLAB. The hardware remains the same but I want MATLAB to display waveforms, and read data on the rising edge of the clock on PFI5.

Is this possible?

If not, is there any way I can use MATLAB 2011 to connect to DAQmx, and let DAQmx do the acquisition on rising edge, make a TDMS file, and read TDMS into MATLAB for post processing.

Although SignalExpress is acquiring data, the only reason I am replacing SigExpress with MATLAB is because thats one of the objectives of the project. (To try and achieve same functionality across different platforms.)

I hope the question is clear now. If not, please let me know.

Thanks.

[timtamslam]

Hey razor149,

Thanks for elaborating. Your problem is very clear to me now. Thank you for elaborating on those points of documentation, it was very helpful. The difficulty is that I'm not very familiar with functionality and interworkings of the DAQ Toolbox because it is not one of our software sets . The documentation you've turned up though seems to point that it would not be possible though. The tough part for me is that the most recent version of the NI DAQmx Tools we make are not guaranteed to work for that version of MATLAB®. You would have to use a version 2008b or earlier. 

In regards to your second point, DAQmx is only the driver so you would still have to rely on a Development Environment like LabVIEW or SignalExpress in combination with the driver to take measurements with the hardware. My overall recommendation would be to stick to using the SignalExpress or LabVIEW Software for data acquisition and creating a TDMS file.

I will look into this a bit more though and see if there is anything additional I can turn up. To be honest though, I think you might have more luck contacting The MathWorks, Inc. because the Data Acquisition Toolbox their product. I'll let you know if I turn up more information though!

[razor149]

Hi Tim,

Thanks for your reply! I do not mind using LabVIEW SignalExpress but there are a couple of issues I am facing, which is why I turned to MATLAB.

Issues:

1) I have a 10GB TDMS file. This gives me a stagerring 30GB ASCII file. I have to post process all of this data at once.

So breaking it up into small bits and pieces may not work, because multiple TDMS file creation at an external clock rate of 25MHz, may result in loss of data, am I right? I cannot lose even 1 bit of data.

2) I use PCIe 6537 which is rated to work at 50MHz(external clock). I set my "Samples to Read" to 50M. I give an external clock of 50MHz.  I run into an "Onboard device memory overflow" error 200361, instantaneously.

Now this is not supposed to happen, since technically I am still within specifications. The card runs fine at 48Mhz though.

3) When I sample at 50MHz on internal clock, I do not get an error as in (2) immediately. It does run for 4-5 seconds. But in this case,the square wave(data) does not appear. 50% is not observed. It looks more like a burst, and then string of zeros, then a 50% DC, then a string of zeros. The same acquisition for 30 seconds gives 200279.

I do not have a screenshot. I am trying to recreate it, but now I am getting 200279 all throughout. I have updated settings to Prepare data for viewing -> After Logging, as well as other recommendations given in the error description, but nothing helps. For the same settings and same files, lower frequencies run better.

These troubles are causing me to focus alternatively.

If you can help me with some solutions, it will be great! I know this post is long, but I will happily clarify if the post is confusing.

Thanks.

[Kyle_A.]

Hey Razor,

1) If you grab all the data off the board and save in different files, I don't see where you could run into lost data using LabVIEW.  You are pulling data off the board and saving it to a location that you can preprogram, and you can pull data off in chunks of whatever size you'd like to and work in a sequence, no problem.  While that is a large file, if you manage memory carefully then it should be allowable by LabVIEW's perspective.  

In LabVIEW SignalExpress, you are more rigid with less room for customization, and the steps are implemented in a way that using multiple steps could result in a loss of data, so in that case you are correct with your concerns. 

2) How many channels are you sampling at once? What HDD are you using to store data?  The PCIe-6537 is designed as a streaming board, where the main acquisition buffer is created in RAM based on your hardware configuration.  Typically, setting a sample rate of 50MHz will require 5MS Samples To Read per Read SW call.  This way, you call DAQmx Read, it takes 5MS of data from the RAM buffer, and then you call DAQmx Read subsequently for the next 5MS, and so on.  10 DAQmx Read calls a second is plenty of time for SW to keep up with the requests, and the DMA transfer is fast enough to keep up with the transfer of data.  

Also, there are other factors which could affect this maximum rate.  The motherboard could have a bandwidth limitation, there could be other PCI devices taking bandwidth from the PCIe port when transferring data, the preallocated RAM buffer could be too small and fill up before data is read from it, etc.  If you could post a minimized version of your code, where it just contains the setup of the 6537 and its continuous acquisition code, it may be helpful to take a look at the settings from that perspective.

The 6537 can achieve 50MHz on all 32 channels successfully, which ends up being 200MB/s across the backplane (no problem for express form factor).  There are caveats with generation, though it doesn't apply to your application, but if you do wish to generate with this board, the maximum output rate on all 32 channels is reduced to 44.75MHz on select systems, while others can achieve 50MHz.

3) If you use internal clock and you aren't using a reference clock from your DUT, chances are the data is not synchronous with the clock and you are crossing into the setup and hold times and seeing phase misalignment.  I assume the external clock you had coming from the DUT would be synchronous with the data, and that would be the best case scenario.  Feeding that clock into STROBE on the board will ensure source synchronous data transfer, and align your sampling window properly.  That is what I'm guessing happens with the use of internal clock.

So let's take the next action of receiving the minimized code and Tim and I will take a look at it.  I apologize for all the trouble you are having with the device, and hopefully we can understand the behavior after a little more troubleshooting so that we can recommend a working solution for your application.  Thank you. 

[razor149]

Awesome Awesome Awesome reply!

I am sorry for the delay, I will get back with all the answers, on Monday, for sure.

Have been busy with some breakthroughs in LabVIEW Eval.

I really want to know whats happening in (2) and (3). So I will definitely come back with all what you have asked for.

Thanks.

[razor149]

Hi Kyle,

Sorry for the delay, yet again.

(2) I am sampling only one channel in port 3.

HDD type: WD SATA 6 Gb/s

RAM: 4GB

There is only 1 PCIe card inside the cabinet, which is the 6537. Also, when I run LabVIEW SigExp, thats the only main program running. All others are the basic Windows background processes.

As for the code, since I am using LabVIEW Signal Express primarily, I have screenshots to provide. In addition, logic family selected in MAX is 2.5V, and input is 0 to 2.5V swing.

3) I am kind of confused. In (2), you can see that I am taking in a clock from PFI5. So that is okay.

But if I select Sample Clock Type as "Internal" instead of "External" then how will it understand that the internal clock has to be in phase with PFI5?

Also, just to let you know: Even if "Sample Clock Type" is Internal, the 50MHz clock is permanently connected to PFI5 anyway.

I am sorry if I misunderstood you, but I would like you to clarify a bit more on (3) if I got you wrong.

Thanks.

[Kyle_A.]

Hi Razor,

2) Can you try and use a different triggering source? Do you have another signal in phase with your clock, like a data active, that can be used? It may help your issue, it may not, but seeing that the clock and the trigger are the same is not something typically done, since the trigger only responds to one rising/falling edge for the entirety of the acquistion.

Can you set the buffer to 5M instead of 50M as well? Samples to Read in Continuous sampling mode only sets buffer size, nothing else.

3) Internal clock does not PLL with external clock with that SignalExpress step.  If you use internal clock, it ignores the clock you bring in on PFI5 completely.  If you use external clock, it only uses the clock connected to PFI5.  The internal clock's phase relationship to your data will be different from the external clock, since they are two different physical oscillators.  If you use internal clock, I would expect duty cycle to be mixed up and timing to be off.  Therefore, external clocking should be used to keep phase alignment with the data.

Do you have a timing diagram for your DUT interfacing to the PCIe-6537? This would show where the data transitions in relation to the clock, and any other signals that come from the DUT.  This would help.

Slower frequencies will work better because the sampling window is larger, and there is more room for phase to shift.  For instance, 50MHz is a 20ns period while 5MHz is a 200ns period.  It will take 10x as long for an error to show up in the 5MHz case as it does for the 50MHz.

[razor149]

2) If I have trigger=source, then data acquisition does work for 48Mhz. I haven't tried the case where the trigger is different. I cannot do that. And any way, since the trigger happens on the first edge, and thereafer the sampling should occur at 50Mhz, right? I am sure the trigger is then ignored, and sampling takes place.

5M gives a buffer overflow way too easily.

3) Understood. Thanks for the clarification.

And sorry, I do not have any Timing diagram.

Thank you.