PXI

cancel
Showing results for 
Search instead for 
Did you mean: 

Using Non-DaqMX module as master to 4472s

I'm trying to use a ZTEC ZT1000PXI Star Card as a timing and trigger source for my PXI-6120 and PXI-4472 modules. I am generating two periodic outputs from the ZTEC card, and am able to put them on any of the bus lines.  I set one of them to output on the PXI_Star line, and am trying to use it as the SampleClockTimebase for two 4472s in slots 7 and 8.  I am unable to acquire any data using this timebase.  I know the signal is getting out there, because I am able to use it as the SampleClock for the 6120s.  I am using DaqMX Vis and property nodes to set up the acquisition.  I also have the Star Card set up to issue a SyncPulse on PXI_Trig5.
 
Am I going to be able to do this (use the ZTEC as a master instead of one of the 4472s)?  It seems like I should be able to if I provide all of the required signals on the bus.  I am setting the DAQMx.Timing property nodes as follows in the order listed:
 
For the 4472 in slot 7:
 
SmpClk.Timebase.Src is set to /PXI1Slot7/PXI_Star
SampQuant.SampMode is set to Continuous Samples 
SyncPulse.Src is set to /PXI1Slot7/PXI_Trig5
SampTimingType is set to SampleClock
 
Prior to this I have set up a channel with AI Voltage, and after this I issue a Start Task and then go into a loop to read the data.  I never get any data.  Is there something specific about the Sync Pulse that I need to do?  I am causing the PXI_TRIG5 line to toggle by writing to the Star Card.  Does the Sync Pulse need to be issued every time a task starts, or will the acquisition work without a sync pulse?  It seems like the card need to be told they are slaves, but I don't see how to do that.
 
0 Kudos
Message 1 of 30
(5,736 Views)

Update - I got rid of the Sync Pulse output from the star card, and made PXI_Trig5 an input to the Star Card.  Now my acquisition works OK if I don't configure an external source for the SyncPulse. I have two 4472s running off the external Sample Clock Timebase on their respective PXI_Star lines.  Each card starts its acquisition off of a Start Trigger, which is output from PXI_Trig3 by the Star Card. I have two different tasks runnining in parallel, one for each board.  I would really like to have one data acquisition task allowing me to get channel data from multiple boards, but it seems the only way this is allowed in DaqMX is to have one of the boards in slot 2, acting as a Master.  This is not what I want - I need the Star Card in slot 2.  Is there no way in DaqMX to use the Star Card (not DaqMX-compatible) as a master clock and trigger source to multiple 4472s in the other slots?

Also, I don't understand the SyncPulse function - is this pulse issued more than once? I though I would only have to send a pulse a single time to sync the clock dividers on each board.

0 Kudos
Message 2 of 30
(5,716 Views)
Hello wired,
 
The synchronization pulse is generated once by the master device when it is synchronizing. Upon reception of the pulse, all of the count down dividers on the slave devices will reset. This ensures that they all start dividing at the same time. After the devices start, synchronization the pulse is no longer used.  
 
I think that even though you have your application working now it may not be completely synchronized since you are no longer using a sync pulse.  This sync pulse is needed to truly have the cards synchronized.  There is another good discussion forum that talks a little about why it is needed.  You can find this other forum post here.
As far as using a multidevice task I don't think you will be able to use it if you do not have a DAQmx device in slot 2.  This is because the DAQmx driver does a lot of work behind the scenes to route the required signals to the other boards.  This includes driving the Sample Clock Timebase.   More information about this can be found here.  So unfortunately since you are using a 3rd party device in your application you will probably need to have a separate task for each board.
 
I hope I helped answer your questions.  If you have any more questions please let me know.
 
Have a great day,
 
Brian P.
Applications Engineer
0 Kudos
Message 3 of 30
(5,703 Views)
Thanks for the reply, Brian.
 
I do realize that the SyncPulse is required to synchronize multiple devices.  I've tried to issue a pulse from the Star Card, but when I do, my acquisition hangs up.  I've the source of the Sync Pulse to PXI_Trig5, and I issue a 200ms pulse, then wait 600ms, then issue the Start Trigger.  The DAQ program acts like it didn't receive the Start Trigger.  Is there some peculiarities to the Sync Pulse, e.g. pulse length, timing with respect to other signals, etc.?
 
Also, I am trying to acquire data at the maximum rate from two 4472s.  I can keep up with one card, but when I add another task and data collection loop to my VI, I can no longer read the data fast enough.  I tried the method used in the Sync and Stream example, where the tasks are put into an array and fed into a loop for reading, but that can't keep up either.
 
Do you have any suggestions for data streaming approaches using multiple tasks?  Ultimately, I need to be able to get data from four 6120s and two 4472s and stream it all to a single file.
 
0 Kudos
Message 4 of 30
(5,701 Views)
Brian - Thanks for the manual link - I didn't find that one earlier.  My Sync problem is fixed now - I was going active-high instead of active-low.  My questions about streaming still stand, though.  I am replacing a CVI application that created dozens of threads to accomplish this task.  I'm hoping LabVIEW is up to the task, since I intend to use Warp Mode on the 6120s!
0 Kudos
Message 5 of 30
(5,700 Views)
I'm glad to hear your synchronization is now working.
 
As far as streaming data to the disk, I would recommend either using the binary format or the TDMS (Technical Data Management Streaming) format if you are using LabVIEW 8.20.  Both of these methods use binary files which is the fastest way to stream data to the disk since it doesn't need to be converted into a different file format.  The TDMS format has additional advantages of being able to store additional properties and header information with your binary data.  More detailed information about TDMS files can be found in this article.
 
Overall streaming your data to the disk will probably be limited by the speed of your hard drive and how quickly your software loop can run.  Therefore you will need to monitor your application to make sure that the Write VIs are not slowing your loops down too much and causing the data acquisition buffer to fill up.  There are many examples in LabVIEW that can be found by going to Help>>Find Examples that show how to use the write to binary file VIs.  One possible way to write your data would be to acquire data from all of your devices, build them all into an array and write that array to a binary file all in the same loop.  This way you are only accessing the disk one time per loop itteration.  If this is too slow then you could keep this data in memory and wait until the data reaches a certain size and then write it to file. 
 
Another method of doing this is to use parallel loops.  You could have your master loop quickly acquire the data and then send it to a slave loop (which might run at a slower speed) that would write that data in chunks to a file.  Again there are many examples that use parallel loops to perform slower more time consuming processes.
 
Hopefully this can help you get started.  Please let me know if you have any other questions.
 
Have a great day,
Brian P.
0 Kudos
Message 6 of 30
(5,696 Views)
I can't seem to stream to disk faster than about 15Ksps when acquiring 16 channels of data from 2 4472s.  I get error #-200361 (device memory overflow).  I'm wondering if the sample rate is being set correctly for the external timebase.  For instance, if I send the 4472s an 8MHz timebase, that would result in 31.250KHz for Fs/256 (less than the 51.2K limit for Fs/256), or it could also be 62.5KHz for Fs/128 (greater than the 51.2K limit for Fs/256).
 
If I set my timebase to an external source on PXI_Star, and provide an 8MHz clock, and I set my sample rate to 31250Hz, will the board automatically use the correct overclocking rate?  It seems like LabVIEW/DaqMX should easily be able to handle this data rate.  I'm using the same approach (Sync and Stream Example style) to create 4 tasks for 4 6120s, and I can stream at 800Ksps to disk.  What is the difference between the two?  Am I getting bitten by the small FIFO on the 4472?  Attached is my code that I'm trying to make work.
0 Kudos
Message 7 of 30
(5,683 Views)
Oops, Let's try that again with the VIs.
0 Kudos
Message 8 of 30
(5,684 Views)
I added some diagnostic indicators to the vi to find out if it was having backlog problems.  My first board's backlog was pretty consistently below 50 samples when sampling at 15625Hz.  My 2nd board's backlog was typically in the 400s, but on the last good sample before the failure it dropped to 133.  I was reading 2 seconds of data with each read, so I consistently got array sizes of 8x31250 for each board, but the time after board 2's backlog dropped, I got 8x192 from the first board, and no data from the 2nd board.  It seems like something must be interrupting the DaqMX driver and causing this delay, since everything was proceeding normally prior to that.  Any ideas on how to fix this? 
0 Kudos
Message 9 of 30
(5,677 Views)
 

Hello Wired,

It looks like you are on the right track to developing your application.  I noticed that you modified the PXI 4472 Synchronization example to build your code which is a good idea. 

As far as the buffer error you are receiving, that error usually occurs if you can't read the data from the device quickly enough.   Does this error occur after a set amount of time or does it occur randomly?  Part of the reason might be the size of the FIFO since the 4472's buffer is much smaller than the 6120's.  One thing that you might try is to close as many other programs that might be running on your PC.  This means disabling any automatic updates and scheduled processes.  What PXI controller or PC are you using?

I think you are on the right track because I checked your calculations and it seems like your sample rates should be correct.  The oversample clock should be taken care of behind the scenes since you are supplying a sample clock timebase so I don't think that should be a factor.  You mentioned that you can run this application with 4 6120s.  Is this in the same PXI chassis?  Are you clocking them using your Star Card? 

Please let me know a little more info and I will continue to check and see what might be causing this error to occur.

Happy Holidays,

Brian P.  -  Application Engineer

0 Kudos
Message 10 of 30
(5,659 Views)