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

[vandenberg greg]

Hi Paul,

The way we have the DAQpad set up is we have a one pulse per sec coming from a GPS device going into PC6 (pin 36) and Exttrg (pin 38), and we use pc7 (pin 37) as output. I tried your code and it didn't work until I put in iStatus = DIG_Prt_Config(iDevice, iPort, 1, 1), but it still would set the output low when the program would exit. Could the problem have something to do with using pc6 and exttrg? Also, although we are using Port C pins 6 and 7, the software would only work if set to port A (iPort = 0). This doesn't make sense.

Thanks,

Greg

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.

 

Applications Engineer
National Instruments

[Paul_C.]

Hi Greg,

I verified through testing that using the DIG_Prt_Config command resets the device and sets the digital output lines low.  I'm having difficulty reproducing the behavior you are seeing.  Could you provide modifications that you made to the example to cause the lines to go low when you exit the program?  Are you changing the port from a digital input to an output through your application?  I'm assuming the reason you need the iStatus = DIG_Prt_Config(iDevice, iPort, 1, 1) is due to the fact that you have the port set as an input for reading the pulse from PC6 and you change it to an output for PC7 output.  Since the port can only  be defined as either an output or and input, is it possible that is what is causing the conflict? 

In regards to your question about pc6 and exttrg, I don't see why these would be causing the problem.  If you have the other ports available, it might be best to try this using two different ports.  This would allow you to configure one port as an input and the other as an output to avoid conflicts. 

I'm also not sure what you mean when you say it only works when you set it to port A (iPort = 0).  I'm able to configure and write to port C by using iPort = 2.  Have you tried this?  Are you getting any errors?

Regards,
Paul C.

[vandenberg greg]

Paul,

 Here's the code:

// test.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;
 i16 iMode = 1;
 i16 iDir  = 1;

//    iStatus = DIG_Prt_Config(iDevice, iPort, iMode, iDir);  If this line is commented out nothing happens. If is not then the LED lights up when this line is executed, then it flashes off, then back on again when the next line is read.

   
    iStatus = DIG_Out_Port(iDevice, iPort, 0xFF);
 Sleep(9000);
       
    return 0;
}   When I reach this line In the debug mode, stepping further gets me to C:\Program Files\Microsoft Visual Studio\VC98\CRT\SRC\CRT0.C, line 210 which is:

             exit(mainret);

When this line executes the LED turn off

Also, although we have the output hooked up to line 37 which according to the documentation is Port C, line7. The above code only works if the port is set to 0, which correspnds to port A, it doesn't work with the port set to 2, which corresponds to port C. I haven't tried any other ports yet.

[Paul_C.]

Hi Greg,

I believe I know what is causing the problem.  The problem is that you are setting the mode to handshaking.  Which reserves port C to be used for handshaking lines on port A.  This is why you get an error when you try to write to the entire port C.  Port C has been reserved by the config line to be used as a handshaking port.  Do you require handshaking mode or Mode 1?  If not then you can solve this by using the config command to set Port A to mode 0 (Please refer to code below).  Then you will have access to all the lines on Port C.  I do realize from the table on page 35 of the manual that lines PC6 and PC7 should be available for I/O when in mode 1 Input (when you configure Port A to Mode 1 Direction 0).  However, I'm not sure if the Traditional DAQ driver allows you to set just one line to an output on a port like that.  These commands are typically used on cards that support setting individual I/O lines.  I believe your older DOS application might have been using registry level programming to set these lines individually. 

Here is the code I used to set Port A back to mode 0.  This allows you to set all the lines on port C (or port 2) high.  I would also like to add that I'm still not able to reproduce the behavior of the lines going back low after the exit command.  I've attached a picture of test panels showing the line maintaining high after I stepped through the exit.

Here is the code:

#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 iMode = 0;
    i16 iPort = 0;
    i16 iPort2 = 2;
    i16 iDir  = 0;
    i16 iDir2  = 1;
    i16 iIgnoreWarning = 0;
    i16 iRetVal = 0;

    // Set Port 0 for Non Handshaking Mode - This frees up all of Port C
    iStatus = DIG_Prt_Config(iDevice, iPort, iMode, iDir);
   
    // Configure Port C for Output
    iStatus = DIG_Prt_Config(iDevice, iPort2, iMode, iDir2);
   
    // Error Checking
    iRetVal = NIDAQErrorHandler(iStatus, "DIG_Prt_Config", iIgnoreWarning);

    // Set the entire Port C High
    iStatus = DIG_Out_Prt(iDevice, iPort2, 0xFF);

    Sleep(9000);
       
    return 0;
   
} 

Here is the Picture:


I hope this helps,
Paul C.

Message Edited by Paul C. on 12-04-2007 01:07 PM

[vandenberg greg]

Paul

  Thanks for the response. I tried setting the mode to 0 and the port to 2 and then the LED connected to PC7 would light up.

However, we need to use handshaking if I understand things correctly because we need to turn on our equipment precisely on the

1 pulse per second signal we receive from our gps device. I was just curious to see if other ports would be affected by the

program exiting. In the case of setting mode to 0 and port to 2 the same behavior still occurs. The LED goes out when the program

exits.

Also, if I run the Test panel in MAX, select Digital I/O and then select port 2, line 7, when I click on the WriteOutput button the LED we

put on the PC7 line turns on. If I click on Close the light stays on, but if I exit MAX altogether the light turns off after a few seconds. Does your

system do the same thing, or does PC7 stay on after you exit MAX?

Would it be possible to email me your executable version of Test2? If you do you need to change the extension to something other than exe

to pass our filters.

I'm starting to think that maybe the problem is somewhere else in the configuration of the parallel port, or the DAQPAD-1200, or XP.

Would you know what is going on?

Thanks,

Greg

[Paul_C.]

Hi Greg,

I'm not sure if handshaking is necessary for your application.  I would recommend taking a look at the manual, found here, and determine if you require it for timing concerns.  These diagrams can be found on pages 3-16 through 3-19 (PDF pages 35-38).  In addition, I have been able to verify that closing MAX and reopening MAX sets the digital output lines low.  I have also finally been able to verify and reproduce the problem you are seeing with the digital output lines going low.  I have been able to verify that when MAX isn't open the digital output lines aren't retaining their previously set states.  I had MAX open during all of my tests because I was using a test panel (analog input) to read the digital output.  When you don't have Measurement and Automation Explorer (MAX version 2.2) the digital output lines go low immediately after the program executes.  With this new information, I see two possible solutions.  My first solution would be to keep MAX open during the execution of your application.  This would effectively allow you to set those digital output lines high and keep them high as long as you don't close out MAX.  The other solution would be to continue using your DOS application (assuming it uses registry level programming) or write a new application that uses registry level programming (Note: I haven't verified that this will solve all of these issues, but it is more likely to have the functionality to do so).  Registry level programming questions are supported through our driver development kit (DDK) forum found here.  In addition, this is the only way that I can see you being able to use lines 6 and 7 of Port C as inputs and outputs while the card is set to mode 1 (handshaking).  I have gone ahead and attached a release version of my application if you want to use it for testing.

I hope this helps,
Paul C.