Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

daqpad 1200 doesn't work quite right with xp and 6.9.3 traditional ni-daq

We are using a daqpad 1200 as a kind of switch to turn on equipment at a relatively precise time. We have been using old software that ran under DOS to control the DaqPad. I updated this software to run in XP using visual C++ and the NI-DAQ 6.9.3 software. When the new version is run the equipment turns on when it's supposed to but then when this new version finishes running the equipment turns off. With the old version the equipment would stay on after the program completes running which is the behaivior we want. The NI-DAQ functions we are using are Get_DAQ_Device_Info, DIG_Prt_Config, and DIG_Out_Port.  Does anybody know what is going on and how to fix this problem? Thanks
0 Kudos
Message 1 of 16
(4,431 Views)
Hi Greg,

I'm not sure why the digital line is turning your equipment off after the program finishes running.  What type of logic does it require to turn the equipment on and off?  Is is possible that at the end of the program it is sending the command to turn the equipment off?  When a digital output line is set (the state is changed) it will remain at the state until you manual change the state again.  Basically, once you set a line high it will stay high till you set it low.  Are you pulsing the digital output line by changing it high then quickly changing it low again?  Is the code for the old version the same as the new version? 

In addition, you might try taking a look at some of the digital output examples.  Here is a great article that should help you find examples.

I hope this helps,
Paul C.
0 Kudos
Message 2 of 16
(4,407 Views)
 The last NI-DAq function called is this: status = DIG_Out_Port(deviceNumber, portA, 0xFF); which turns the equipement on. The program then calls Sleep() for 8 seconds before quitting. The code for the new version is pretty much the same as the old version except for the calls to get the system time which uses a slightly different data structure, and the include files to the NIDAQ stuff are different, plus I followed the instructions in the readme.htm files for compiling and linking visual C++ programs. I'll take a look at the link you gave me. Thanks for the help. 
0 Kudos
Message 3 of 16
(4,401 Views)
Hi Greg,

Do the devices turn off if you stop sending a high?  Is it possible the Daqpad 1200 is losing power or being turned off after the program is executed?  I don't see any other reason that the equipment would turn off other than something else causing them to do so.  Is it possible that something else might be turning the equipment off?  Take a look at the link I gave you and possibly some of the examples and see if you can reproduce the same behavior.  It would also help if you could put a probe on the lines and check their states when the equipment is turning off.  This would help us clarify if the lines are actually changing or something else is causing the problem.

Thanks,
Paul C.
0 Kudos
Message 4 of 16
(4,366 Views)
Still having problems.
 
One of our engineers rigged up a plug for the Daq analog output that has a LED hooked up to the lines we are interested in so I can test the software, and we still have the same problem. I noticed that calling exit(0) causes the LED to go out. When I run the old DOS based program that was compiled with Borland Turbo-C everything works ok, the LED stays on after the program exits.
Could this have something to do with the visual C++ console application or NIDAQ 6.9.3?
0 Kudos
Message 5 of 16
(4,320 Views)
I also found that if I run the old version of our software to set the line high, when I run the new version the line goes low as soon as the program start running. The old version the line would stay high the whole time.
0 Kudos
Message 6 of 16
(4,316 Views)
Hi Greg,

I'm not sure why the digital output line would be going low after you call exit(0).  This is not the behavior that I would expect.  What version of the driver does the old DOS code use?  In addition, I'm curious how you are doing your test.  How are you able to run the old version (which requires Dos) to set the line high and then run the new version?  Are you doing this all within Windows XP?  I would also like to add that performing a device reset will set the lines back to a low power up state.  Are you doing anything in between running the old program and the new that might be resetting the device? 

Thanks,
Paul C.
0 Kudos
Message 7 of 16
(4,301 Views)

I'm not sure why the digital output line would be going low after you call exit(0).  This is not the behavior that I would expect.  What version of the driver does the old DOS code use?  In addition, I'm curious how you are doing your test.  How are you able to run the old version (which requires Dos) to set the line high and then run the new version?  Are you doing this all within Windows XP?  I would also like to add that performing a device reset will set the lines back to a low power up state.  Are you doing anything in between running the old program and the new that might be resetting the device? 

According to the comments in Nidaq.h, the old version is using di-daq DOS 4.8.0.

I run the old version by opening a DOS window in XP and running the old .exe file. The DAQPAD stays on even after closing the DOS window. I then run the XP console application immediately afterwards

I tried the example, DoOnePort and got the same behavior: the LED would turn on when DIG_Port_Config is called and go off when the program quit. 

Also, when I commented out all the function calls in DoOnePort and ran it after turning on the DAQPAD with the old version of my software the DAQPAD would remain on but when I uncommented the very first function call (DIG_Prt_Config) and ran it, as soon as the program started running, before DIG_Prt_Config was even called the DAQPad output would go low. This is similar to the behavior of my new application and really doesn't make any sense to me. 

 

 

 

0 Kudos
Message 8 of 16
(4,292 Views)

Also, I was informed by our technician and our Electrical engineer that unplugging the DAQPad from the parallel port before the program quits is a bad idea, that something could get damaged. Is this true?

Thanks,

 

Greg

0 Kudos
Message 9 of 16
(4,289 Views)
Hi Greg,

I have set up a computer running Windows XP, Visual Studio 2005, and NI DAQ 6.9.3.  I setup a very basic example using the digital out port A line 0 of the DAQpad 1200.  I tested a few things.  Running my application with the following code below set the digital output lines high and leaves them high after closing the application. 

// test2.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "nidaq.h"
#include "nidaqex.h"

int _tmain(int argc, _TCHAR* argv[])
{
    /*
     * Local Variable Declarations:
     */

    i16 iStatus = 0;
    i16 iDevice = 1;
    i16 iPort = 0;
   
    iStatus = DIG_Out_Port(iDevice, iPort, 0xFF);
       
    return 0;
}

In addition, I tested the example that contained the iStatus = DIG_Prt_Config(iDevice, iPort, iMode, iDir).  I verified with a break point that this does set the digital output lines low.  I suggest removing this section of code as seen above if you want to avoid this behavior. 

In regards to your question: "Also, I was informed by our technician and our Electrical engineer that unplugging the DAQPad from the parallel port before the program quits is a bad idea, that something could get damaged. Is this true?"

I don't see any documentation on doing this and how it may affect the DAQpad 1200.  However, I would recommend, as a precaution, to not remove the parallel cable while an application is accessing the DAQpad 1200.

I hope this helps,
Paul C.


0 Kudos
Message 10 of 16
(4,271 Views)