Showing results for 
Search instead for 
Did you mean: 

error code -10401 device recognized by max but does not communicate with software

I have an old labview program that I inherited. I have connected a NI PCI-MIO-16E-4 daq to my computer. MAX is able to recognize and run successfully a test. However, when I use it in a labview program (v8.5) it doesn't seem to work and I get the error -10401 in AI Clock config. I have the current DAQmx (v9.5) driver. Any help with this problem would be greatly appreciated.

0 Kudos
Message 1 of 12

@deepakve wrote:

Any help with this problem would be greatly appreciated.

The best help would be to attach the VI that contains the function that throws the error.  For best results, right-click the folder that contains all of the VIs in this Project, Send To, Compressed Folder, attach the resulting .ZIP file, then tell us the name of the Top Level VI and the name of the VI that contains the function throwing the Error.  The more you provide to us, the more likely we can make useful suggestions.


Bob Schor

0 Kudos
Message 2 of 12

Hi Bob!


Thanks for the prompt reply. I have attached the labview files in a zip file as requested. The vi file that shows error is the "". The top level vi is named "simple scan".

Allow me to explain the whole story behind my question. These set of vi's have been written by a past grad student in our lab (~ 2004) which I am trying to use now, after a long time, for my experiments. I am not sure in which version of the labview was this code written/used earlier, but the pc where I am trying to get it working has labview 8.5. At first, I transferred these files to this pc and I found run code errors in the main vi. The code was asking for missing set of AI (analog input) subvi's such as AI clock config, AI buffer config, AI trigger config and a few more. I sought the easiest solution of obtaining these missing subvi's from a different pc (with Labview 2010) by converting them to a lower version. This other pc also has a very similar set of vi files which work fine.


After doing this, the run code error is gone but the communication between the DAQ device and the software is still not achieved. I can see the device (PCI-MIO-16-E4, SCB 68) on MAX and I am able to obtain signals for the assigned tasks (3 channels). Initially, when I run, its runs fine with no errors, but "AI read" gives a (#0x3) result, i.e. no data. In successive runs, I get errors -10401 and sometimes -10609. These errors, as I think, are originated in "AI start" and "AI read" in  


I apologize for a descriptive writing but I thought I had to put forth every detail pertaining to this problem to you. Kindly let me know if you need any more information that I can help you with.


Thanks in advance.


0 Kudos
Message 3 of 12

I wrote "... attach the resulting .ZIP file, then tell us the name of the Top Level VI and the name of the VI that contains the function throwing the Error".  Too bad you want me to guess what you are doing ...


Bob Schor

0 Kudos
Message 4 of 12

Hi Bob,


The vi that is showing error is “” with a subvi named “scope”.



0 Kudos
Message 5 of 12

OK, I have Good News and Bad News.  I opened one of the Multy_Scan_Script VIs, guessing these were at or near the Top Level.  I noticed that you had a lot of .LLB files that looked like you might have thought you could pull in Driver and other Support Files (instead of loading them when installing a version of LabVIEW with its Drivers) -- my hope was that if your code was really in LabVIEW 8.5, that might be "close enough" to current versions of LabVIEW that I might be able to at least partly open it on my PC.


Instead, I got a series of messages saying that LabVIEW was searching for legacy DAQ routines in the LabVIEW 7.0 folder.  Oops, NI DAQmx replaced Legacy DAQ in 2003!


I can see two possibilities for resurrecting this old code and re-establishing its functionality.  One way would be to re-create the original Development Environment, which I will assume is LabVIEW 8.5 (which still can support Legacy DAQ, though NI, and I, strongly recommend migrating to DAQmx).  To do this, I suggest the following steps:

  1. Obtain an older computer, manufactured no later than 2010, earlier if possible.
  2. Install Windows XP (32-bit).
  3. Install LabVIEW 8.5.  Reboot.
  4. Install any additional Toolboxes or Modules you will need (the fewer, the better).  Reboot.
  5. Install Legacy DAQ, MAX, and any Drivers you will need (the fewer, the better).  Reboot.

Note that this machine should not be connected to a network, as it lacks security from attacks and updates are no longer possible.


With this replication of the original Development machine, but with a clean installation of LabVIEW, you should be able to open the code that you have and get most of the VIs to load.  You will (probably) not need (and not want) the numerous mis-placed DLLs that are present in your ZIP file, which belong in the National Instruments "Program Files" Folder where the Driver files are stored.


A much better alternative, especially if you want to many any changes or improvements to this legacy code, is to build a "modern" LabVIEW Development System and "re-Develop" the application.  This may seem like a much more difficult task, but having done this myself several times, the result was a huge improvement over the original code, running faster, with fewer errors, and being much easier to develop, debug, and maintain.


If you choose this route, here are the steps I'd suggest:

  • Start with a modern (no older than 2 years) PC, running Windows 10 Pro, 64-bit.
  • Install Full or Professional LabVIEW 2016 or 2018, 32-bit.  Install the minimum set of Toolkits and Modules that you will need.  Reboot and install the minimum set of Drivers that you will need.  Of course, install DAQmx. 

Now you need to design your Project.  I definitely recommend putting your "project" inside a LabVIEW Project to help you keep track of the various pieces of code that your project requires.  Here are some things that you should strive to attain:

  • The Top Level VI should utilize a State Machine, Queued Message Handler, or some other Design Pattern suited to providing Control and Information to the Operator of the Task at hand.
  • All VIs should adhere to the following principles:
    • Every Sub-VI should "Do One Thing, Thoroughly and Well".  A corollary of this is that every Block Diagram should fit on a single Laptop Screen (if this seems impossible, then you are doing "too much" inside the sub-VI -- hand sub-tasks off to sub-VIs inside the sub-VI, as a sub-VI takes only 32x32 pixel on the Block Diagram).
    • Every Sub-VI should use the 4-2-2-4 Connector Pattern, with Error In and Error Out at the lower outside connectors.
    • Every Sub-VI should have an Icon, if only a Square with 3 short lines of text, for identification.
    • Every Sub-VI should have a Description, at least identifying its Inputs and Outputs.
  • Coding works best with a team, even if its only one person doing the LabVIEW coding, and another person who understands the Task being accomplished.  The team should write the Description of the Program (what it is supposed to do, what hardware it needs to use, what inputs and outputs are required, etc.) and as development continues, the Team should revise the document as needed.  If only one person on the Team knows LabVIEW (or C++, or whatever you are using to write the code), then that person needs to at least "walk through" the code, explaining what is happening, and making sure the rest of the team sees the point.  Note that if you have adhered to the "one-screen Block Diagram" by utilizing sub-VIs that do "one thing", you have effectively "buried the details" and can concentrate on the Big Picture.
  • An advantage of having nested sub-VIs that "do one thing" is it becomes much easier to test that they actually work.  Example:  Write data to a binary file having a file name of <Year>-<Month>-<Day>-<Hour>-<Minute>-<Subject>.bin (an example would be 2018-07-28-14-03-Bob.bin).  You definitely want a sub-VI, "Make File Name", that takes a string, "Subject", and returns a Filename, "Filename".  Your sub-VI, of course, also has Error In and Error Out.  Code it.  Test it.  It should be easy to tell if it works.  Now use it wherever you need to make file names.  [Note -- please do not use such awful file names -- I just included this pattern here as it is an easy example of "hiding the details"].

Bob Schor

0 Kudos
Message 6 of 12

@deepakve wrote:

The vi that is showing error is “” with a subvi named “scope”. calls AI Start, AI Config, or AI Read, which call the obsolete (and absent on my PC) Legacy DAQ routines instead of the DAQmx routines that have been used for the past decade-and-a-half.  "Scope setting" appears to be a Global -- it is definitely not a called sub-VI.


I just sent you a detailed answer to how you should move forward with this Project.  However, I now suspect that this may be much too ambitious for you, and may require contracting the Project out to a group that does LabVIEW Development.


Bob Schor

0 Kudos
Message 7 of 12

Hi Bob!


Thank you so much for the detailed answer. As I am not so good with Labview, I will opt for the first solution of yours and hope that it works. I only have two pc's (older than 2005) with both XP installed in them. The pc I want these programs to work has a lot of other softwares and dat that havent been backed up, so I am reluctant to reboot the windows. Do you think, uninstalling labview 8.5 on my pc and re-installing it would work? As for installing legacy DAQ and any drivers, where do you suggest I can get it downloaded from? The device I use is PCI-6040E.


Unfortunately, I dont know of any group here that does LabVIEW development. Perhaps you can suggest someone that I can contact in/near Downtown Los Angeles.



0 Kudos
Message 8 of 12

@deepakve wrote:

Perhaps you can suggest someone that I can contact in/near Downtown Los Angeles.



You could try advertising the job

0 Kudos
Message 9 of 12

Hi Bob!


Do you think installing labview 7 instead of 8.5 would work?



0 Kudos
Message 10 of 12