-10013 software error - DAQ VI error codes, NI driver (2349) and (2301)

[J_Owens]

Hello,

We are getting the -10013 software error code, reported by driver NI (2349) and (2301).  The error code help states it is a DAQ VI error code for bad error code error stating the driver returned an unrecognized or unlisted error code.

We have tried restarting the machine and PC numerous times with no luck.  The alarm is intermittent and occurs multiple times per day.  To clear the alarm, we can stop the machine, instead of just resetting the alarm, and then re-initialize the machine and restart.  It can also be cleared by going to the DAQ device Test panel and starting and resetting the 2 active counters.

We started looking at the DAQ counter device based on the error codes.  It is a Traditional NI-DAQ (Legacy) Device PCI-6602.  The driver is working, tried disabling and then re-enabling in Windows, no change.  Also tried Test Resources in the Device properties, device passed.

Attached are the system information and NI support files, along with shots of the alarms and Test Panel window.

Any ideas on how to correct these alarms, or auto-reset and restart when they occur?  The developer of the application mentioned they were unable to solve this, even with NI support and changing cycle time in C++ program.

Thanks for your help,

James

[gabe2327]

Hi,

If you search "error code 10013 counter/timer national instruments" in google you will find an NI discussion forum entry of someone with a similar problem.

Hope this helps.

[JÞB]

What you have is an executable running on a Win XP SP2 with LVRTE 8.0 and Traditional DAQ 7.4.1f4

Why, I have no idea! DAQmx supported that device then and still does.

Did this ever work? when did it start reporting the error? Which Developer? What C++ ode? and NI Support SHOULD have sent you HERE   I know, Just busting your chops NI Support.  That error should not have needed to be researched in the last decade since a perfectly good work-around exists: Upgrade to DAQmx!

So, after figuring out if a recent change occurred in the system (Don't forget to scan for new memory errors) Go through the steps in the link.

[J_Owens]

Thank you for the replies.

The first Google search link did not help.  In response to the next reply from Jeff, I have a few answers and further questions.

The application we are running does work, and has for years.  The error started about 4 months ago, with random reoccurrences and no changes known of.  The developer was a machine builder - KBH, who apparently spent considerable time with NI support to solve this.  KBH responded about the cycle time adjustments in C++.  I'm not aware of how they did this.

We only have is a single application file that we launch to start the program and run the machine.  I have not found, or been able to identify, the source code.  I am new to Labview, so please bear with me as I am learning about this system.

I began to look at the steps from your post.

1. Shut down all applications that are using NI-DAQ (examples include MAX, LabVIEW, Measurement Studio, Visual Studio). Now try loading your applications in a different order - in particular, try loading the application that gave you the error first.
   
   1. Not sure how to do this, since we only launch a single application to start the program.
2. Update to the latest version of Traditional NI-DAQ (Legacy) 7.4.4.
   
   1. Is this as simple as just installing this version from NI with the existing hardware and application, without making changes?  We have v.7.4.1f4. It seems that upgrading to DAQmx would require program changes.
3. Update to the latest versions of all other National Instruments drivers used by the target system.
   1. Again, not sure about doing this if there are program changes to make.
4. Scan for memory errors?
1. In Windows Event Viewer?  I didn't see anything significant that would correspond to the recent errors.

Again, thanks for your help.

James

[JensG69]

Perhaps it's a sign of the electronic hardware aging of your system? Perhaps the main board and/or the counter card start to have have hardware problems?!

Regards, Jens

[JÞB]

---

@J_Owens wrote:

Thank you for the replies.

•   In response to the next reply from Jeff, I have a few answers and further questions.  I Will inline my response in Blue
• The application we are running does work, and has for years. Got it
•  The error started about 4 months ago, with random reoccurrences and no changes known of.  Something changed- we will need to figure out what
• The developer was a machine builder - KBH, who apparently spent considerable time with NI support to solve this.  KBH responded about the cycle time adjustments in C++.  I'm not aware of how they did this. This is information that should be investigated.  Any clarification from the developer may be a clue.  (We are getting into consulting here but if a simple solution arises you get the freebie for an endorsement)

We only have is a single application file that we launch to start the program and run the machine.  I have not found, or been able to identify, the source code. Not great - but manageable

I am new to Labview, so please bear with me as I am learning about this system. That's what the forums are for  If I get ahead of you ask for clairification.

I began to look at the steps from your post.

1. Shut down all applications that are using NI-DAQ (examples include MAX, LabVIEW, Measurement Studio, Visual Studio). Now try loading your applications in a different order - in particular, try loading the application that gave you the error first.
   
   1. Not sure how to do this, since we only launch a single application to start the program. You are also using MAX and that might have left some bits laying around in a bad way.  Worse, something may have changed a parameter that LabVIEW is expecting to be different.  I'm just old enough to have lost some of the grey matter that used to be fluent in Legacy NI DAQ and oldie MAX "Stuff" but if you bare with me I can help investigate.  I may need some screen-shots or even "Jing's" (Video) of some steps to stimulate the memory banks.
2. Update to the latest version of Traditional NI-DAQ (Legacy) 7.4.4.
   
   1. Is this as simple as just installing this version from NI with the existing hardware and application, without making changes?  We have v.7.4.1f4. It seems that upgrading to DAQmx would require program changes.That is that easy and should not require a software change.  All you would be doing is replacing the driver that the app calls with a compatable one. However, lets not do this now! It used to work. it should still be able to work if we find the cause
3. Update to the latest versions of all other National Instruments drivers used by the target system.
   1. Again, not sure about doing this if there are program changes to make. Ditto the above except for Latest versions will have no support for your OS or LabVIEW 8.0 (Read that as a we won't go there) 
4.  Scan for memory errors?
1. In Windows Event Viewer?  I didn't see anything significant that would correspond to the recent errors.  Using the system tools to test the memory.  If some RAM died (Hey RAM gets old too and looses some cells) that would be a potential change that requires hardware fixes.  Then, you might as well do what you should have done years ago and schedule your systems for obsolecence review and modernization  Yes, that is a pet peeve of mine and a very common oversight by end users.  Although, I  can charge more for modernizing a system that is already dead!

Again, thanks for your help.

James

---

So, next steps.

• work with the developer to find source code and hopefully the "As Installed" MAX Hardware configuration.  If the god of good fortune smiles on you there wil be a *.nce file somewhere.  If not SPEC the HW config file as a deliverable next time.
• Use your IT resources to look for system trouble (Memory scan)
• Work to understand how C++ components are integrated into the executable.
• Post Back

And thank you for responding honestly 

-J 

[JÞB]

---

@jg69 wrote:

Perhaps it's a sign of the electronic hardware aging of your system? Perhaps the main board and/or the counter card start to have have hardware problems?!

Regards, Jens

---

The self test should have caught anything abnormal on the 6602 HOWEVER, It could be sent in to a calibration lab  and that is not a bad idea.

Send the card in for cal 

[JensG69 · Accepted solution]

When I put together the facts a deterioration of some of the hardware components IMHO is the most plausible cause.

We have a system with

• Win XP SP2 (so it hasn't seen any software updates for a very long time)
• LabVIEW runtime 8.0 (that's from 2005 - so it's valid to assume that the system is about 12 years old)
• System has run stable for many years, hence it's very unlikely that the software and/or the drivers are the cause of the current errors.
• Errors occur randomly and unpredicably.

Since the software has been working for many years and has not been changed there has to be another reason, and that's IMHO the hardware, and looking at an electronic system that's probably 12 years old, it's not surprising that it experiences some hardware malfunctions.

Regards, Jens

[J_Owens]

Jeff,

To clarify, the developer has seen this same issue with other machines they have built, with no solution to offer.  I can look into the steps you mention, thanks.  We are in the process of upgrading these machines, but I was hoping to find a solution to this nuisance alarm in the meantime.

Jens,

We have another 6602 card that I could try swapping with this one, to potentially eliminate hardware as an issue.  I know the PC mother board was replaced about a year ago, but these issues did not show up immediately, but about 6 months later.

Thanks for the suggestions,

James

[J_Owens]

Problem solved.

We found another complete PC and Hard Drive that we used from an identical machine and the problem has gone away.

I believe Jens was correct in that it is some type of Hardware failure. 

Thank you for all of your help and suggestions,

James