PXI

cancel
Showing results for 
Search instead for 
Did you mean: 

Using Non-DaqMX module as master to 4472s

Wired,

One other thing that you might try is to test your system by removing your timing board in the 2nd slot and replacing it with one of your 4472s.  Then you will be sharing the sample clock timebase between the two 4472 cards.  This will remove one of the variables from your current issue and it will help us troubleshoot the problem.  You will not be able to use your current code but you could open up the 4472 synchronization example, mentioned in an earlier post, or you could perform a multidevice task. 

I know that you will probably not want to keep this configuration, but by doing this you can at least make sure that your code and sampling rates work with your setup.  If this does work then we know that streaming to the disk and the onboard FIFO isn't the problem.  We can then try to determine what might be causing the problem.  If you don't want to move your cards around you could also just try running both 4472s without synchronizing them and see if that works at high speeds on your system.

Please let me know how this works.  Happy holidays!

Brian P.  -  Application Engineer

0 Kudos
Message 11 of 30
(2,641 Views)

Brian - thanks for the tips.  I'm working on another part of the code right now, and will eventually get back to this issue, but for now I need to just demonstrate the streaming to a single disk file from multiple tasks.  Once I get that working, I'll need to work on improving the performance, and will try your suggestions.

What I am afraid of is that DaqMX works better on the 4472s when they are synchronized, because there is only one task created when doing the multi-device synchronized acquisition (when one of the 4472s is the master).  The small FIFOs are probably less of a factor in that case.  Unfortunately, I don't have the option to put the 4472 in slot 2.  It would really be cool if DaqMX was smart enough to know that my two 4472s were synchronized by an EXTERNAL timing source in slot 2, and still allow me to combine the channels from both devices into one task.  To me, it seems that the requirement that one of the 4472 devices be in slot two really cuts down on the types of hardware configurations that can be done.  For instance, what if I was using an NI timing and control board instead of the ZTEC?  If any board in slot 2 can produce the synchronization signals, DaqMX should, in my opinion, allow the multi-device task to be contructed.  I have identified all of the required signals as coming from the PXI bus, so I don't see a reason why DaqMX wouldn't be happy to let me use my 2 4472's as slaves.  Maybe you can ask the driver developers about this...

Have a great Christmas!

Kevin 

0 Kudos
Message 12 of 30
(2,640 Views)
The multidevice task feature was added to DAQmx 8.0.  I agree that it would make it easier to program in your situation if you could specify the timing source for a multidevice task.  Currently the multidevice task requires one of the boards in the task to route the necessary signals to the other boards.  If you were using a National Instruments Synchronization module such as the PXI-6653 you would still need to share your signals in the same manner that you are trying now.
 
I would suggest you submit a product suggestion at our Product Suggestion Center so that your idea can be more closely examined.  These product suggestion are viewed directly by our R&D developers and they are not just discarded.  Since this is not currently a feature you can at least add your input to why you think it would be a good idea.  I will also make an internal product suggestion just so that we have our bases covered.
 
Have a great holiday season!
 
Brian P.
Application Engineer
0 Kudos
Message 13 of 30
(2,634 Views)
Brian,
 
Tried a different example today:
 
C:\Program Files\National Instruments\LabVIEW 8.2\examples\DAQmx\Events\Events.llb\Acq&Graph Voltage-Int Clk-EveryN&DoneEvent.vi
 
Made it reentrant, and placed 6 copies of it in a VI.  I made the channel parameter an input, and for each board in my PXI chassis, I told the VI to scan all channels (the 4 6120s at 500KHz, and the two 4472s at 100KHZ).  I was actually able to get this to run, all six boards acquiring data simultaneously.  However, when I put a case structure around the 4 6120 VIs to comment them out, the 4472 VIs reported the hardware timeout.  This seems contrary to logic (less tasks = more time to do remaining tasks).  Any idea what could be going on?
 
 
 
 
0 Kudos
Message 14 of 30
(2,610 Views)
A little more info.  It does not ALWAYS work when I run all six subvis in parallel.  Sometimes one or more of the 4472 board tasks fails immediately.  It does seem, however, that if all tasks get started OK, they run to completion.  I do still have the problem of the 4472 tasks failing all the time if I do NOT run the 6120 tasks.  This is just not making sense to me. I have attached the VIs so you can see what I'm doing.
0 Kudos
Message 15 of 30
(2,604 Views)
 

Since posting the above two messages, I discovered a link to a set of VIs that use NI-SYNC and an NI-6653 to synchronize multiple 4472 devices in a single chassis. The example is here:

http://zone.ni.com/devzone/cda/epd/p/id/5128 

Since my GPS card can output the same signals as the 6653, I followed the example and am now able to create a single task to collect data from multiple 4472 cards using the ZTEC ZT1000PXI in slot 2 as the timing source for the three required signals (clock timebase, sync pulse, and start trigger).  However, I am still experiencing strange results - for example:

   I am able to acquire data at 100KHZ from all 8 channels of a single card.

   I am able to acquire data at 100KHz from a single channel of each of my two cards for a limited time period (then I get error -200361).

   I can never acquire data from four channels of each card.

I basically have the setup and configuration that I was looking for (all channels in a single task), but not the performance.  It seems like the DaqMX driver is having difficulty dealing with multiple 4472 boards when combined in the same task.  The odd thing is that I was able to do the simultaneous collection of data from six PXI boards at very high speeds as described in my earlier post.  It seems like DaqMX is capable of handling the data, but only sometimes.  Is there something I can do in LabVIEW to improve the performance?

0 Kudos
Message 16 of 30
(2,600 Views)
Brian, attached is the single-task multi-4472 VI that we discussed.
0 Kudos
Message 17 of 30
(2,590 Views)

Hey Brian,

FYI, I modified the 4472 VI I just posted to perform multi-device acquisition with the 6120.  All I did was remove the SyncPulse property, change the Sample Clock Timebase Property to SampleClock (and fed it a different external clock signal on PXI_TRIG2), and changed the buffer size to 4meg.  I was able to collect data from all channels of all of my 6120 boards (16 channels total), at 500KHz and stream to disk.  I collected 6GB of data without incident.  So, the approach I am using definitely works well, at least for the 6120.

Message Edited by wired on 01-03-2007 01:06 PM

0 Kudos
Message 18 of 30
(2,589 Views)

Brian,

Sorry I missed your call yesterday - had to leave early.

My problem with the 4472 is unchanged - I still have issues trying to acquire data from multiple boards at high rates, even if it is a smaller total number of channels than from a single board.  The point of my last post was that the 6120 does not seem to be plagued by this issue.

The previous CVI application that I mentioned is being run on the same chassis, however it is being rewritten because it does not perform reliably, and produces a number of run-time errors under various situations.  I have been unsuccessful at acquiring data at higher rates with the old program - I get clock configuration errors when starting up a data collection.  It has typically been used to collect data at the lowest sample rate (1KHz), and perhaps the program wasn't tested at higher rates.  I have no history with the legacy program, so I can't answer too many questions about it  - besides, I don't think it's relevant to the current issue.

0 Kudos
Message 19 of 30
(2,577 Views)

Hello Kevin,

 

The reason I wanted to know if your older CVI program was being used on the same HW, was just to see if you had been successful at streaming all of your data to the disk using your current hard drive and CPU.  Since you are using a PXI-8186 you should be able to stream approximately 17MB/s based on the hard drive.  So you might run into problems streaming data from all channels on 6 cards at the max rate.  Based on your code you are using your 6120's to write 16bit integers at 500kHz from 4 channels.  So you are streaming (16/8)*500k*4= 4MB/s.  So with 4 cards that is 16MB/s.  This alone should work and you did have success when streaming data from your 4 PXI-6120 cards.  However, the problem comes when we add 2 more 4472's.  Based on your program the 4472's will write 32bit integers at 100kHz on 8 channels.  So (32/8)*100k*8= 3.2MB/s.  All together you would need to stream approximately 22.4MB/s to the disk, which is more than the hard drive on the 8186 can take.

 

Before we can even test streaming to the disk we need to get the 4472's working with the 6120's.  I set up a test system and I was able to successfully run your Collect All Data.vi with 2 4472’s.  I was even able to use 3 4472’s with no problem by adding one more 4472 reentrant VI.  So I’m not sure why your system would not behave the same way.  Have you been able to have any success running both 4472’s at the same time using similar code?

 

I want to help you get all of this working but we should be aware that even if we do get all the cards to work together you probably will not be able to stream as much data as you want to.  Especially if you are considering using warp mode in the future.  So please let me know if I am correct in my assumptions about the data that you need streamed and what exact requirements you have for this application and hopefully we can find a solution for you.

 

Have a great day,

 

Brian P.

Applications Engineer

National Instruments

0 Kudos
Message 20 of 30
(2,563 Views)