I am using Component Works 2.0 in a Visual C++ application for data acquisition from a PCI6071 DAQ card, and frequently get "Blue Screens of Death", and/or a message something to the effect "The Instrument is not a National Instruments product..." when debugging the code.
The problem has increased recently, to what might be called a catastrophic level: almost 100% of the time the initialization process hangs: requiring a reboot.
Is there Visual C++ sample code which might show how to trap and handle these DAQ errors gracefully? I have not been sucessful in capturing error numbers/messages using the return value from
For error handling, I would recommend writing event handlers for the DAQError and DAQWarning messages which are generated by each of the ComponentWorks DAQ controls. The ErrorEventMask property defines which types of errors are handled by these events. The behavior of the remaining Error or Warning messages are handled through the ExceptionOnError property. ExceptionOnError is true by default. Set this property to False in order to check the return values of method calls such as Configure and Start to see if an error has occurred.
I believe that the error you are encountering is -10401, Unknown Device Error. A common reason for this error is an invalid device number. If you are using named channels and the device is NOT device 1, you would also recieve this error. This was a ComponentWorks bug. A workaround is to set the correct device number instead of selecting the "Use Named Channels" option in the property pages. This has been fixed in CW3. In most other cases, the error is being returned by the NI-DAQ driver. I would recommend upgrading to the latest version of the driver.
Denise
"Bill Garber" wrote: >>I am using Component Works 2.0 in a Visual C++ application for data acquisition>from a PCI6071 DAQ card, and frequently get "Blue Screens of Death", and/or>a message something to the effect "The Instrument is not a National Instruments>product..." when debugging the code.>>The problem has increased recently, to what might be called a catastrophic>level: almost 100% of the time the initialization process hangs: requiring>a reboot.>>Is there Visual C++ sample code which might show how to trap and handle these>DAQ errors gracefully? I have not been sucessful in capturing error numbers/messages>using the r eturn value from
As it turns out, when stopping the VC++ debugger without exiting normally (such as occurs when threads fail to initialize), the DAQ gets into an unknown state. Subsequent to this, I either get the aforementioned "unknown device" message, or the system will "blue screen".
The system will also blue screen if I attempt to open up either the DAQ test tools or the Configuration utility, after one of these events.
Is there a way to reset the DAQ if the debugger needs to be stopped pre-emptively, such that the DAQ will not create blue screen conditions?
As an aside, when the blue screens have occurred, over time, the *.rc (resource) file got corrupted. Ultimately, the size of the file went from a "pristine" 128kB to >380MB! The compile/load process took several minutes to perform (normally it took < 30 seconds). This has subsequently been corrected, but the blue screens continue and, I suspect, the file corruption will again rear its ugly head.
The error checking you addressed (from within the normal program operation) is a very good idea, and I have attempted (with limited success) to do this in the past.
The blue-screen condition is different, I believe, due to the abnormal termination of the debugging process. Do you know of a way to gracefully trap the "debug-exit" condition and restore the DAQ to a known state? I have tried using the "SetNextStatement" feature of the debugger to branch to "OnFileExit()" code, but this creates Assertion errors if the debugger is exited before there is a valid HWnd for the process. (Subsequent running of the debugger also creates blue-screens immediately upon attempting to rerun the program or invoke one of the DAQ programs).
Thanks, Bill
"denise" wrote: >>For error handling, I would recommend writing event handlers for the DAQError>and DAQWarning messages which are generated by each of the ComponentWorks>DAQ controls. >The ErrorEventMask property defines which types of errors are handled by>these events. The behavior of the remaining Error or Warning messages are>handled through the ExceptionOnError property. ExceptionOnError is true>by default. Set this property to False in order to check the return values>of method calls such as Configure and Start to see if an error has occurred.>>>I believe that the error you are encountering is -10401, Unknown Device Error.>A common reason for this error is an invalid device number. >If you are using named channels and the device is NOT device 1, you would>also recieve this error. This was a ComponentWorks bug. A workaround is>to set the correct device number instead of selecting the "Use Named Channels">option in the property pages. This has been fixed in CW3.>In most other cases, the error is being returned by the NI-DAQ driver. I>would recommend upgrading to the latest version of the driver.>>Denise>>"Bill Garber" wrote:>>>I am using Component Works 2.0 in a Visual C++ application for data acquisition>from>a PCI6071 DAQ card, and frequently get "Blue Screens of Death", and/or>a>message something to the effect "The Instrument is not a National Instruments>product...">when debugging the code.>>The problem has increased recently, to what might>be called a catastrophic>level: almost 100% of the time the initialization>process hangs: requiring>a reboot.>>Is there Visual C++ sample code which>might show how to trap and handle these>DAQ errors gracefully? I have not>been sucessful in capturing error numbers/messages>using the return value>from
I don't know of a way to nicely terminate the ongoing operation on the DAQ device within the debugger before stopping in the middle. However, you could use the DeviceReset method on the CWDAQTools control to reset the hardware. You can either add this call as the first call within you app, or create a separate exe that you run after quiting the debugger. After calling DeviceReset, you should be able to run the program, access the test panels, etc. without any further errors.
Regards, Denise
"Bill Garber" wrote: >>Thanks, Denise.>>As it turns out, when stopping the VC++ debugger without exiting normally>(such as occurs when threads fail to initialize), the DAQ gets into an unknown>state. Subsequent to this, I either get the aforementioned "unknown device">message, or the system will "blue screen".>>The system will also blue screen if I attempt to open up either the DAQ test>tools or the Configuration utility, after one of these events.>>Is there a way to reset the DAQ if the debugger needs to be stopped pre-emptively,>such that the DAQ will not create blue screen conditions?>>As an aside, when the blue screens have occurred, over time, the *.rc (resource)>file got corrupted. Ultimately, the size of the file went from a "pristine">128kB to >380MB! The compile/load process took several minutes to perform>(normally it took < 30 seconds). This has subsequently been corrected, but>the blue screens continue and, I suspect, the file corruption will again>rear its ugly head.>>The error checking you addressed (from within the normal program operation)>is a very good idea, and I have attempted (with limited success) to do this>in the past. >>The blue-screen condition is different, I believe, due to the abnormal termination>of the debugging process. Do you know of a way to gracefully trap the "debug-exit">condition and restore the DAQ to a known state? I have tried using the "SetNextStatement">feature of the debugger to branch to "OnFileExit()" code, but this creates>Assertion errors if the debugger is exited before there is a valid HWnd for>the process. (Subsequent running of the debugger also creates blue-screens>immediately upon attempting to rerun the program or invoke one of the DAQ>programs).>>Thanks, Bill>>"denise" wrote:>>>For error handling, I would recommend writing event handlers for the DAQError>and>DAQWarning messages which are generated by each of the ComponentWorks>DAQ>controls. >The ErrorEventMask property defines which types of errors are>handled by>these events. The behavior of the remaining Error or Warning>messages are>handled through the ExceptionOnError property. ExceptionOnError>is true>by default. Set this property to False in order to check the return>values>of method calls such as Configure and Start to see if an error has>occurred.>>>I believe that the error you are encountering is -10401, Unknown>Device Error.>A common reason for this error is an invalid device number.> >If you are using named channels and the device is NOT device 1, you would>also>recieve this error. This was a ComponentWorks bug. A workaround is>to set>the correct device number instead of selecting the "Use Named Channels">option>in the property pages. This has been fixed in CW3.>In most other cases,>the error is being returned by the NI-DAQ driver. I>would recommend upgrading>to the latest version of the driver.>>Denise>>"Bill Garber" >wrote:>>>I am using Component Works 2.0 in a Visual C++ application for data>acquisition>from>a PCI6071 DAQ card, and frequently get "Blue Screens of>Death", and/or>a>message something to the effect "The Instrument is not a>National Instruments>product...">when debugging the code.>>The problem has>increased recently, to what might>be called a catastrophic>level: almost>100% of the time the initialization>process hangs: requiring>a reboot.>>Is>there Visual C++ sample code which>might show how to trap and handle these>DAQ>errors gracefully? I have not>been sucessful in capturing error numbers/messages>using>the return value>from
I might try placing the reset code within a "#idef Debug"-type statement, or, os you suggested, making it the first call of the app, and/or generate a separate app.
Thanks.
Regards, Bill
"denise" wrote: >>Bill,>>I don't know of a way to nicely terminate the ongoing operation on the DAQ>device within the debugger before stopping in the middle. However, you could>use the DeviceReset method on the CWDAQTools control to reset the hardware.> You can either add this call as the first call within you app, or create>a separate exe that you run after quiting the debugger. After calling DeviceReset,>you should be able to run the program, access the test panels, etc. without>any further errors.>>Regards,>Denise>>"Bill Garber" wrote:>>>Thanks, Denise.>>As it turns out, when stopping the VC++ debugger without>exiting normally>(such as occurs when threads fail to initialize), the DAQ>gets into an unknown>state. Subsequent to this, I either get the aforementioned>"unknown device">message, or the system will "blue screen".>>The system will>also blue screen if I attempt to open up either the DAQ test>tools or the>Configuration utility, after one of these events.>>Is there a way to reset>the DAQ if the debugger needs to be stopped pre-emptively,>such that the>DAQ will not create blue screen conditions?>>As an aside, when the blue screens>have occurred, over time, the *.rc (resource)>file got corrupted. Ultimately,>the size of the file went from a "pristine">128kB to >380MB! The compile/load>process took several minutes to perform>(normally it took < 30 seconds).> This has subsequently been corrected, but>the blue screens continue and,>I suspect, the file corruption will again>rear its ugly head.>>The error>checking you addressed (from within the normal program operation)>is a very>good idea, and I have attempted (with limited success) to do this>in the>past. >>The blue-screen condition is different, I believe, due to the abnormal>termination>of the debugging process. Do you know of a way to gracefully>trap the "debug-exit">condition and restore the DAQ to a known state? I>have tried using the "SetNextStatement">feature of the debugger to branch>to "OnFileExit()" code, but this creates>Assertion errors if the debugger>is exited before there is a valid HWnd for>the process. (Subsequent running>of the debugger also creates blue-screens>immediately upon attempting to>rerun the program or invoke one of the DAQ>programs).>>Thanks, Bill>>"denise"> wrote:>>>For error handling, I would recommend>writing event handlers for the DAQError>and>DAQWarning messages which are>generated by each of the ComponentWorks>DAQ>controls. >The ErrorEventMask>property defines which types of errors are>handled by>these events. The>behavior of the remaining Error or Warning>messages are>handled through the>ExceptionOnError property. ExceptionOnError>is true>by default. Set this>property to False in order to check the return>values>of method calls such>as Configure and Start to see if an error has>occurred.>>>I believe that>the error you are encountering is -10401, Unknown>Device Error.>A common>reason for this error is an invalid device number.> >If you are using named>channels and the device is NOT device 1, you would>also>recieve this error.> This was a ComponentWorks bug. A workaround is>to set>the correct device>number instead of selecting the "Use Named Channels">option>in the property>pages. This has been fixed in CW3.>In most other cases,>the error is being>returned by the NI-DAQ driver. I>would recommend upgrading>to the latest>version of the driver.>>Denise>>"Bill Garber" >wrote:>>>I>am using Component Works 2.0 in a Visual C++ application for data>acquisition>from>a>PCI6071 DAQ card, and frequently get "Blue Screens of>Death", and/or>a>message>something to the effect "The Instrument is not a>National Instruments>product...">when>debugging the code.>>The problem has>increased recently, to what might>be>called a catastrophic>level: almost>100% of the time the initialization>process>hangs: requiring>a reboot.>>Is>there Visual C++ sample code which>might show>how to trap and handle these>DAQ>errors gracefully? I have not>been sucessful>in capturing error numbers/messages>using>the return value>from