Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Daqmx task freezes when running on PXI slot 2

Dear LV community,
I'm having some problems with my PXI chassis.  I have two PXI-6289's (as well as a few other cards) inside a 1042Q PXI chassis.  When I run code from the Labview examples (I'm using simultaneous AI/AO, but I don't think that the exact code matters) on the card in slot 3, everything works as usual.  When I run the code on the card in slot 2, the code works as usual, but the vi refuses to stop when I press the 'stop' button.  When I pause the code, it looks like it's getting hung on the 'stop task' vi after the program loop.
I have a few other chassis, but I haven't noticed this problem before.  When I switch the cards, the hang-up still occurs in the same slot, and the card in slot 3 works as normal.  Therefore, the cards seem not to be the problem.
I should mention that this is a newly recieved chassis.

I'm hoping that I'm just missing a configuration option in MAX.
Wolfgang
0 Kudos
Message 1 of 10
(4,854 Views)

Hi Wolfgang,

There shouldn't be any association between where your LabVIEW VI is hanging up and the slot number in your chassis and unfortunately this issue isn't just a missing configuration option in MAX.  The first question I have is about the "stop" button.  Be sure that you are pressing the stop button on the front panel of the example program and not the abort button which is located in the toolbar at the top of the window (next to the run and run continuously buttons).  It is good programming practice not to press the abort button.  The stop button will wait for everything to finish executing before halting the program whereas the abort button may stop mid process, like in the middle of a VI.

Also, I'm not sure what the exact example that you are using.  I opened up Multi-Function Synch AI-AO.vi from the example finder and there are Clear Task VIs instead of Stop Task VIs.  The clear task stops and clears the resource of the configuration. 

Finally, I know you said that you have tried this with other chassis although I'm not sure from your post whether or not you actually tried it in slot 2 in those chassis.  The only difference about slot 2 is that it can be used for timing and triggering if an appropriate module is placed in there.  Although it can also be used for regular DAQ so that shouldn't make a difference.  Hopefully this information will provide you with more troubleshooting techniques.

Regards,
Vanessa L.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 10
(4,831 Views)
Vanessa,
Thanks for your reply. 

Initially, the task froze on my own vi.  It's a rather complicated (but not necessarily well programmed) state machine with some digital outputs, and both analog inputs and outputs.  The only way to recover from this error is to pull the plug on the computer.  Even if I try to stop Labview through the task manager, it doesn't respond.

The program is now hanging up on the slot 2 6289 in my second PXI chassis.  It doesn't hang up on the 6289 in slot 3.  When I open and run your example 'Acq&graph Voltage-int clk.vi' (a vi without a while loop), Labview hangs only when I use the slot 2 6289.  When I press pause, after the vi has frozen, it looks like the program freezes on the 'clear task' sub-vi.  It almost seems like a task has been permanently frozen in my computer (or on the PXI chassis).

I have tried removing and replacing all of my cards in MAX and through the hardware.  Is it possible that task information is retained through computer/PXI restarts?  Or is it possible that some buffer cannot be emptied through restarts?  These may sound like naive comments, but I'm willing to throw any suggestions out at this point.
Thanks,
Wolfgang

0 Kudos
Message 3 of 10
(4,816 Views)
Vanessa,
I should mention that this condition now also shows up on my PXI-6289 in slot 6.  I have switched to a new PCI-8331 (the
PXI chassis controller), so I don't think that this is the problem.  Is there any eeprom on the PXI-6289 that freezes this
device somehow?  Or on the PXI?
Hmmm...
Wolfgang
0 Kudos
Message 4 of 10
(4,812 Views)

Hi Wolfgang,

At this point, I am not sure whether or not this error is associated with the DAQ driver, the hardware you are using or LabVIEW.  I have some other troubleshooting techniques that I would like you to try so we can narrow down the problem even more. 

First, go to Measurement and Automation Explorer and create a voltage task using the 6289 in slot 2 of the chassis.  To do this, right click on Data Neighborhood and Create New NI-DAQmx Task.  Then choose Acquire Signals>>Analog Input>> Voltage and choose one of the channels in the 6289.  Once this task has been created try running and stopping the task in MAX.  Also try running a test panel on your device and do a simple read from a channel while it is again in slot 2.  If this still hangs up your computer, then I think there is a problem with the DAQ driver.  The reason is because MAX uses the same low level VIs as the "start task" and "stop task" VIs that you would use in LabVIEW.  If you can run a task fine in MAX, then there might be an even bigger problem to consider.

If you decide there is a problem with your DAQ driver, try uninstalling the driver completely and reinstalling it.  You can reinstall from the driver CD if you still have it or follow this link to the drivers and updates website on ni.com to get the version of the DAQmx driver that you need. 

Finally, you didn't mention before what version of LabVIEW and DAQmx driver that you are using.  I think it would be helpful to know this as well.  My next plan is to try and reproduce your problem here but I have to find the exact hardware that you are using and this might take a little while.  If you could provide me with the versions of software, the exact hardware setup (1042Q, 6289, 8331, etc.) and the exact example programs that you have tried, that would be helpful.  Thanks again and I apologize for the inconvenience this is causing you!

Regards,
Vanessa L.
Applications Engineer
National Instruments
0 Kudos
Message 5 of 10
(4,787 Views)
Dear Vanessa,
We have two Labview licenses, one full and one basic.  My problem is occuring on the full version, which was recently upgraded to your 8.5 release.  I have not upgraded the basic version.  The daqmx is the latest (8.6, I believe).  I should mention that problems are now arising with a PXI-6533, not in slot 2, on the original computer.  It seems to me as if a task is somehow retained in the computer, and once a problem arises on one card, it remains.  The computer is new and fairly fast and new, and I haven't seen any other problems with it.

When I move the PXI chassis to the computer with 8.2, it does not freeze under any conditions (including with my more complicated software, which I have to 'save for previous version' to run on 8.2).

I will create a few tasks in MAX for hardware testing, and I will try to reinstall the DAQ driver.  Please hold off on simulating the condition until I've tried these two things.  This may take a few days. 

It did occur to me that I have two chassis, and that I did switch between them a few times.  I wonder if MAX gets confused when a new chassis shows up with similar cards in different slots (or different cards altogether).  Does it retain some sort of (unique) serial number for the cards?  I'd be surprised if it only accessed this information to stop a task, and not to start it.
Cheers,
Wolfgang


0 Kudos
Message 6 of 10
(4,775 Views)
Dear Vanessa,
I've finally gotten around to working with this chassis again.
I've reinstalled all drivers, MAX, daqmx.  I still get the same error (vi's, including your examples, lock on
'stop task' or 'clear task'.
When I test the 6289 in slot 2, I get the following error:
"The device self test has failed.  The error report from the device driver is as follows:
Error -89123 occurred at Self Test
Possible Reason(s):
Hardware necessary for this route is in use by another route or routes"

Any idea what could be going on?  I'm slowly converging on the conclusion that the PXI chassis has a
problem.  There should not be any use of non-internal clocking/triggering on your simple vi's
(analog input/internal clock).  How can there be a hardware conflict between devices, or between the
chassis and the device?

The system continues to freeze when I run the same vi on the PXI-6230 in slot 6.  I should mention that
I have two 7831's in the chassis, but taking them out changes nothing.

I've used the same computer, with all settings equal, on a different PXI chassis containing two 6289's, 2 6230's,
and a 6533, and I have no freezes at all.
Wolfgang

0 Kudos
Message 7 of 10
(4,710 Views)
Vanessa,
I should add that when I try to reset the device (6289 in slot 2), MAX freezes, and I have to yank
the power cord on my computer.
Wolfgang
0 Kudos
Message 8 of 10
(4,708 Views)

Hi Wolfgang,

It sounds like you have done all the troubleshooting that is necessary with this type of issue.  I agree with your inclination that there must be something wrong with the chassis.  I say this especially since you have tried the same setup with a different chassis and nothing freezes.  You are correct in saying there should not be any link between the example VIs that you are using and the hardware in your chassis. 

Therefore my next suggestion would be to do a Return Merchandise Authorization (RMA) by calling in and sending the chassis in for repair.  I'm assuming you have support so you would need to call into NI and get an RMA coordinator on the phone in order to process it.  In case they suggest for you to do more troubleshooting, I would reference this discussion forum post and let them know that you have already been working with an Applications Engineer.  If you visit http://www.ni.com/support and go to the Request Support link, you can create your own service request.  I'm sorry again for the inconvenience this has caused!

Regards,
Vanessa L.
Applications Engineer
National Instruments
0 Kudos
Message 9 of 10
(4,696 Views)
Vanessa,
Yes, we have support, so this route should not be a problem. 
Thanks for all of your help.  Sorry that this discussion didn't lead to a more interesting conclusion...
Wolfgang
0 Kudos
Message 10 of 10
(4,692 Views)