Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx - Signal Routing Problems and Questions - PXI

Hi,

First of all, this is a repost of my original post on LabVIEW General, which got no reply at all maybe because of the wrong category. So I'm reposting this same post in the hardware category.

I'm using a PXI-1042 chassis with PXI-8176 controller. I tried to synchronize two PXI-6031E multifunction I/O cards in LabVIEW 7.1 with the LabVIEW example "Multi-Device Synch-Shared Timebase-Cont Acquisition" but received the following error:

==================================================

Error -89125 occurred at DAQmx Start Task.vi

Possible reason(s):

No registered trigger lines could be found between the devices in the route.

If you have a PXI chassis, identify the chassis correctly in MAX, and make sure it has been configured properly. If you are using PCI devices, make sure they are connected with a RTSI cable and that the RTSI cable is registered in MAX. Otherwise, make sure there is an available trigger line on the trigger bus shared between the devices.

Source Device: PXI1Slot4
Destination Device: PXI1Slot7

Task Name: _unnamedTask<3>

==================================================

I already specified my chassis and controller type under MAX, and noticed that when I clicked on the "Chassis 1 (PXI-1042)", the information window list all PXI slot as "UNKNOWN/EMPTY" (a screen shot is attached). Maybe that's why LabVIEW cannot find a route between the cards? Also attached is the PXISYS.INI file on the PXI.

I also tried to route the link manually using the DAQmx Connect Terminals VI but got the same error when I tried to route the PXI_Trig0 between two cards.

Also some questions regarding DAQmx:
1. With the DAQmx Connect Terminals VI, is it true that we can no longer make routings to RTSI lines "manually" as in traditional DAQ Signal Routing VI?
2. Is it possible to route, say, a constant low or high to a RTSI line like we could with the old traditional DAQ VI?

Software info:
MAX version 3.1.0.3021
LabVIEW version 7.1
NI-DAQ 7.1 (later upgraded to 7.2 and got the same results)

P.S. Using traditional DAQ VIs is no longer feasible because I just added some cards that supports only DAQmx.

Any reply is appreciated.

Thanks,
Dan
Download All
0 Kudos
Message 1 of 6
(3,494 Views)
Hi Dan,

I think that you are right in that the source of the routing problem has to do with the devices not showing up in the chassis window. Assuming that you have identified your controller and chassis correctly, the only possiblity that I can currently think of is that the PXI provider isn't working correctly. I would recommend uninstalling MAX and NI-DAQ and then reinstalling with the newest version of NI-DAQ in order to get a fresh install of the most current version of the PXI provider on your system.

Regarding routing signals in DAQmx - there isn't anything that I know of that could be done in traditional DAQ that can't be done in DAQmx. DAQmx simply does it differently than in traditional DAQ and gives you the ability to do either high-level or lo
w-level routes. To answer your other question, I don't think that routing high or low to a RTSI line was ever a valid route in traditional DAQ.

Logan Kunitz
National Instruments
Message 2 of 6
(3,493 Views)
Hi Logan,

Thanks for your reply.

I reinstalled MAX and NI-DAQ 7.2 three times and the problem remains. During my last try I also delete the MAX directory under National Instruments directory. My other PXIs (some with the same controller but different chassis) don't have this problem.

I also disabled legacy USB support as suggested here. On this PXI I'm running Windows 2000 as well.

Another thing I tried is to run the PXI Provider.msi included in NI-DAQ 7.2 to repair the pxi provider, after a complete installation is done.

As for routing low or high to RTSI, actually I've done it before and it seemed to work
fine. I created a pulse (low-high-low) on RTSI line and used it as a start trigger for all the counters on a 6602. That's not the purpose of the RTSI line but I think it's still feasible to do.

Thanks,
Dan
0 Kudos
Message 3 of 6
(3,493 Views)
Dan,

It appears that the pxisys.ini file that you're using is an older format (version 1.0 of the PXI Specification; the current version is 2.1). When you configure your PXI system in MAX by identifying your controller and chassis, MAX will create a new pxisys.ini file that adheres to the current version of the PXI Software Specification. Since MAX does not appear to be doing this, there are a few things to look for:

1. Is the pxisys.ini file read-only? If so, clear the read-only attribute, and try again.
2. Are you grabbing a pxisys.ini file from another source, after identifying PXI system components in MAX? If so, you do not need to do this, because MAX will create and manage the file for you.
3. Are there multiple pxisys.ini files in your search p
ath? The pxisys.ini file should be located in your folder (for example, c:\windows). If there are multiple pxisys.ini files, remove those that do not reside in the folder.

Try these things and let us know what you find.

Thanks,
Eric Gardiner
Senior Software Engineer
National Instruments
Message 4 of 6
(3,493 Views)
Hi Eric,

You've made my day!

The pxisys.ini file on the PXI was indeed read-only. After changing the attribute and re-specifying the controller and chassis, now I have the correct chassis information in MAX.

It'd be nice if MAX can return an error upon failure to update pxisys.ini.

Thank you very very much!
Dan
0 Kudos
Message 5 of 6
(3,493 Views)
Dan,

I'm glad that the read-only suggestion worked for you. You are right, MAX should return some feedback in this case. We are working on improvements to the PXI components in MAX to alleviate this problem.

Thanks,
Eric Gardiner
Senior Software Engineer
National Instruments
0 Kudos
Message 6 of 6
(3,493 Views)