LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reconnect to DAQPad 6070E (fw) after powerloss

Solved!
Go to solution

I'm running Labview 8.2 with my DAQPad 6070E for continuous measurements.

This setup has to measure for about a year. At least once a month, all equipment

around it is tested with emergency power for a few minutes.

 

The laptop runs on it's battery, but after the short powerloss (when switching) the

DAQPad loses its (firewire) connection with the laptop.

 

In Windows XP, I can see that the hardware is detected again.

However, my VI does not reconnect with the hardware and starts to produce

empty measurements.

Simply quitting the VI and starting it again solves the problem, but this is not

a solution for a setup where sometimes I don't have access to for several weeks. 

 

How can I make my VI reconnect to my hardware after a powerloss?

 

0 Kudos
Message 1 of 8
(3,371 Views)

Are you using the error clusters?  I would imagine that LabVIEW throws an error when this occurs becuase it no longer can communicate with the card.  Depending on how you setup your card, you can do your reinit when an error occurs.

 

You could also invest in a cheap battery backup for the DAQPad, so when the power kicks out, it doesn't lose power.  You can get one for $40.

0 Kudos
Message 2 of 8
(3,345 Views)

Well I'm trying to use the error clusters, no luck so far. There's also the problem

that the VI crashes on my development machine when power to the DAQPad is lost,

while the compiled version continues to throw errors and just 'hangs' without an error.

 

I've made a counter for each time a measurement (every 10 seconds the 10-second

data is written to a TDMS file) fails, and this counter just rises really fast when the

power is lost. It continues to rise when power is restored, since the VI does not try

to reconnect to the DAQPad.

 

How do you suggest I use the error cluster? Wiring it to some sort of

'wait 10 seconds' period after which the VI restarts would be ideal.. Don't know

how to make it restart until now (I'm quite a beginner in labview).

 

0 Kudos
Message 3 of 8
(3,324 Views)

Without seeing some of your code, it is going to be hard to make absolute suggestions.  Whatever VI you are using to read data from the DAQPad is most likely generating an error.  Now, if you are using some high level VI, you may not have much luck, but if you are using the lower level VIs to create a task, you probably need to rerun those VIs to create a new task.  If you are using the high level VIs, you could try using a DAQ reset, but I do not know that it will fix your problem.  If you post example code, you can probably get better help.

 

I ran into an issue with NI's DNET drivers.  I was actually testing a DNET device, so the bus power was turned off between tests.  NI's driver couldn't handle that and no matter what re-init I did, it woudl continue to error until I restarted LabVIEW.  I figured that NI was doing some one-time initialization that I didn't have access to.  I eventually solved the problem by writing wrappers around NI's DNET drivers and calling them dynamically, so I could unload them from memory when I closed the DNET session and load them back into memory when I init the DNET session.  This forced NI to redo whatever init they did and I never got errors again.

 

Is it not possible to place the DAQPad on a battery backup?

0 Kudos
Message 4 of 8
(3,321 Views)

Your solution to your DNET driver problem sounds exactly like what I would need.

I've modified the VI so that it does not crash anymore in the uncompiled version,

but displays the errors (that made the difference between compiled / development version).

 

Now I get the same behaviour on my development machine. I'm attaching the VI, so you

can see what happens. I've put the DAQ Reset in there already but don't know how to

use it, since I use higher level DAQ functions without using the Device ID.

 

I hope my problem becomes somewhat less vague if you look at the VI 🙂

 

0 Kudos
Message 5 of 8
(3,314 Views)

Hi lennartvl,

 

You can just call the reset vi (in a case structure), it has a default device id 1, which is the same as the id you are using for you ai cont scan vi.

 

Regards,
Bas

0 Kudos
Message 6 of 8
(3,221 Views)

I've tried that, but it does not work. Tells me still the error 10401; occurred at AI Buffer Read.

 

Could this be because I'm using Traditional DAQ (Legacy) instead of DAQmx?

My hardware (DAQPad 6070e firewire) does not support DAQmx..

 

I've read this: http://digital.ni.com/public.nsf/allkb/AA7F6EDFE3E1302E86256FD500817568

 

Am I using the reset VI wrong or is it because I'm using Trad. DAQ?

0 Kudos
Message 7 of 8
(3,178 Views)
Solution
Accepted by topic author lennartvl

Solved it! No matter if I reset the VI or invoked it via a higher level 'invoke VI' block,

it all didn't work.

 

Now I've used the 'Quit LabVIEW' block, and I'm running the compiled application

from a batch file which outputs the time the quit occurred to a text file, and then

restarts the application from the command line.

 

The batch file runs indefinitely, this is what it looks like:

@echo off

:BEGIN
Compiled_Application.exe
echo %date% %time% >> powerlosslog.txt
ping -n 10 127.0.0.1 > NUL

GOTO BEGIN

 

Thanks for the help though!

0 Kudos
Message 8 of 8
(3,152 Views)