Errors using NI435x from VB.NET

[Jonathan_Cutting]

Hi,

I am working on a VB.NET 2008 (.NET 2.0) application that makes P/Invoke calls to ni435x_32.dll.  Drivers are Traditional (Legacy) NI-DAQ 7.4 and NI435X 2.5.

Two scenarios are bugging me right now:

1) My application collects data just fine until I open MAX.  When I open MAX, MAX looks OK but my application stops collecting data and reports Error 0xFFFFD8EF: syntaxError: An error was detected in the input string; the arrangement or ordering of the characters in the string is not consistent with the expected ordering."  Is MAX supposed to have exclusive access to hardware devices?  I don't recall this happening when I was using LabVIEW as a development environment.

2) When debugging my application in Visual Studio, everything is good until I halt the application.  When I try to restart the application I cannot access the device again - I get an HRESULT of access denied - and there is no way to reset the driver without rebooting the PC. 

I have already tried all of the settings referenced in "Unusual Error Messages Loading, Executing, or Debugging an Application When Using NI-DAQ for Windows" (NI doc ID 2Q1HG8A6).  That document doesn't suggest rebasing ni435x_32.dll so maybe there is more that could be done there.  

Note that NI435x hardware is not supported by NI-DAQmx.

Thanks,

Jonathan

[Margaret F.]

Hello Jonathan,

Thank you for posting to the NI forums. You can reset the driver in Measurement and Automation Explorer (MAX) by right-clicking on Traditional DAQ under Devices and Interfaces and selecting "Reset driver for Traditional NI-DAQ." MAX does not take control of the hardware devices when you open it. Is it possible that you have a task running in MAX that could be interfering? Is the error that you described thrown in MAX or in your program? Thanks!

Message Edited by Margaret F. on 02-05-2009 04:40 PM

[Jonathan_Cutting]

Margaret,

Resetting the driver in MAX doesn't help.  I have no tasks running in MAX.  The error is thrown in my program.

After looking into the situation further I have two possible scenarios:

1) In Traditional NI-DAQ Function Reference Help the topic for Init_DA_Brds has the following: "Initializes the hardware and software states of a National nstruments DAQ device to its default state and returns a numeric device code that corresponds to the type of device initialized. Any operation that the device is performing is halted. Init_DA_Brds is called automatically when the Traditional NI-DAQ DLL (nidaq32.dll) is loaded and is not currently loaded in another process. It does not have to be explicitly called by your application. This function is useful for reinitializing the device hardware nd Traditional NI-DAQ software, and determining which device has been assigned to a particular slot number. Init_DA_Brds will clear ll configured messages for the device as if you called Config_DAQ_Event_Message with a mode of 0."  So, my hypothesis: The .NET framework is not keeping nidaq32.dll loaded as expected.  When MAX starts up and loads nidaq32.dll, it finds that it is not loaded in any other processes and Init_DA_Brds is automatically called, thus killing my session.  Possible workaround is to call LoadLibrary explicitly in .NET rather than letting DllImport/PInvoke handle that behind the scenes.

2) The low-level driver for NI435x is ni435xcm.  This driver uses the NI Configuration Manager API nicfq32 to get the current configuration and create a bunch of virtual channels, which are then used by the usual nidaq32 calls to interact with the hardware.  My hypothesis: When MAX starts, it reloads the current configuration from disk and somehow kills the configuration (along with its virtual channels) that ni435xcm had set up.

I don't know what it takes to get source code released but if you could provide any details (source files, PDB files, etc.) for the low-level ni435xcm driver that would help me to debug and possibly work around this problem.  We have been sourcing NI435X for almost 10 years as part of a laboratory instrument package that we sell to our customers.  This hardware package is legacy but I need to keep supporting it for the foreseeable future.  Upgrading to new hardware is planned but it will not solve the need to be compatible with old hardware.

Thanks,

Jonathan

[Margaret F.]

Hello Jonathan,

As far as the program throwing an error when you halt it to troubleshoot, this is probably happening because the program is being stopped before all references are closed. LabVIEW is prone to the same behavior which is why we use "close" vi's. Obviously you need a way to troubleshoot, so I would recommend working pauses into your program so that you are not aborting the program when a reference is open.

With regards to Measurement and Automation Explorer (MAX) halting your data acquisition, this may be a problem with the 435x driver. You mentioned that you are using versioin 2.5. Version 2.5.2 is the latest version of the driver. I would recommend upgrading to version 2.5.2 and seeing if upgrading fixes the MAX issue.

Driver update: http://joule.ni.com/nidu/cds/view/p/id/285/lang/en

Message Edited by Margaret F. on 02-10-2009 06:42 AM