programmatically get PXI-665x information

[wired]

OK, Chris, I guess I still haven't been clear enough about what the problem is.  I understand how to use VISA to open the session and pass it to the various VIs, and I've been doing that.  However, Connect Terminals VI and some other VIs used for routing require fully qualified DAQmx names for Source and Destination.  Also, other boards that might want to set up a route to the NI-Sync board need to know its DAQmx device name in order to set up the route. Session name is not the problem!

[wired]

One other question... All of my other PXI modules that I've used report PXI-XXXX (fill in the number) as the Model Name, but the 6682 reports it as NI PXI-6682.  Is there some reason for departing from the standard nomenclature?  Does someone else make a PXI-6682?

Message Edited by wired on 09-25-2008 02:20 PM

[Chris G in AE]

Kevin,

Can you specify exactly what VIs are preventing you from using the NI-Sync session?  You mentioned that one is the connect terminals VI, which sounds like it could be the DAQmx Connect Terminals.vi.  The reason I ask is that there are connect and disconnect VIs in the NI-Sync API that will take the VISA reference to the 6682.  I'm curious why you cannot use these instead of the DAQmx API.

It seems like I am missing something about the overall configuration and what you are trying to do.  If you can describe what you are trying to achieve, we could try to work out a brief example program using NI-Sync.  In general, the NI-Sync API should be used for all of the 6682 configurations.  If you are doing something differently, I would like to understand why.  

As far as your second comment, there are really no formal guidelines on how the device should appear, but I agree that consistency would be ideal.  I'll go ahead and submit a CAR about the naming convention so that our R&D group is notified of the behavior.  

[wired]

Sorry for the delay, Chris, I somehow missed your latest response.

I am using the NI-Sync API for everything I'm doing.  However, I recently discovered that I was making a mistaken assumption about the need for the DAQmx device name in my source and destination terminals of, for instance, the Connect Trigger Terminals VI.  When I created a constant by right-clicking on the source and destination terminal terminals, my list contained fully-qualified DAQmx device terminal names, e.g. PXI1Slot2/PXI_Trig0.  From this, I assumed that I needed the DAQmx device name in my terminal name.  However, when I wired a string constant containing only "PXI_Trig0" to the terminal, my VIs still worked properly. Thus far, I've been able to do everything I've needed to without having to know the DAQmx device name.

Oddly enough, when I created a new vi and just dropped a Connect Trigger Terminals vi on it and created a 'source terminal' constant, this time the values did not contain the DAQmx device name, i.e. the first item was simply PXI_Trig0.  Why the DAQmx name was prepended in my other program when I did this I do not know, but it caused me to believe that it was a required part of the terminal name.

[Chris G in AE]

Kevin,

I'm not sure why the DAQmx device constant appeared when you created it from the Connect Trigger Terminals VI, but it seems to have been solved by putting down the new Connect Trigger Terminals.  Am I correct in saying that your application is now working as expected?  Please post back with any future questions you might have, but it seems we've gotten everything worked out.  Thanks for the update!

[wired]

Thus far, I am able to do what I need to do.  Bear in mind that this does not solve the underlying problem of being unable to create fully qualified DAQmx names.  For instance, if a board in Slot 5 needed to route a signal to a trigger input only in slot 2, it would need the DAQmx device name for the device in slot 2.