10-25-2011 07:20 PM - edited 10-25-2011 07:28 PM
Does anyone know what error code 88710 means?
I have a screen shot of the error message, but it does not say anything about the root cause.
My labview code had been running for two weeks before this error first came out. The first time it came, I restarted the program. And after two days, it came again.
Thanks
10-26-2011 12:17 PM
Hi haol,
Error code 88710 seems to be referring to a task being aborted in some unexpected manners. Could you provide some information about what device you are using? Also, when this error occurs, is there a loss or corruption in data collected aside from the program ending? I'm also seeing some things about the device being reset and that causing an issue. How is this device being powered?
I'd also like to verify that when you say that the code had been running for two weeks, do you mean running the vi for two weeks uninterrupted? Or that the development had been finished and the code was working?
Regards,
-Dave C
10-26-2011 05:45 PM
Dear Dave:
Thank you for your reply.
We are using two PCI 4472 8channel data cards. I'm sorry I don't know how exactly they are powered. I only know that they are plugged in the computer. I attached two photoes of how the boards are connected to the computer, hope it helps.
And regarding to data loss or corruption when this error occured, actually I don't know. We set theVI to collect 1-second data every 10 seconds just to display on the main panel. But we only save once every 20 mins. The saved data on our harddrive do no contain the data file collected exactly when the error occured.
I attached our VI. This VI has been running for two weeks with only several interuptions. I stopped it a few times to change parameters, but only for a few minutes each time. We are running a test on a continuously operating machine so we intend to run this VI to collect data every 20 mins without any interruption.
10-27-2011 12:14 PM
Hello,
What version of LabVIEW are you using that this is coming up? What I've found documented regarding this error says that an effective workaround is to catch and clear the error. So, in this instance, it may be worth inserting an architecture to catch the error out of the read.vi and clear the status of it, but maintain the error number and acquire a timestamp. Then check the data from that time to make sure nothing is out of the ordinary.
I should point out that it's also important to make sure that the section of code clearing the status needs to double check that it's clearing this specific error and still lets others through to shutdown the code.
Please let me know if there are any issues with this or if it won't/doesn't work.
Regards,
-Dave C
11-03-2011 04:05 AM
Dear Dave
I have a very similar problem although with different hardware. I'm running two cDAQ-Chassis (9174) simultaneously and would like to collect data from both with one VI. As one DAQ-Assistant can access only one chassis I also have to use two Assistants which I think is the root of the problem (see image). Every now and then I get that an 88710. After clicking it away I immediately get an 88709. Clicking that away gets the VI going again and working well till... Am I making any basic mistakes without knowing? Ist there a 'way to do' when using two chassis or is it a bad idea anyway? Im rather new to LabVIEW so any help is grately appreciated.
Kind regards
Markus
11-04-2011 12:05 PM
Hey Markus,
Without knowing your specific hardware setup, in general you can have to separate DAQ assistants in the same VI and in the same loop, however pay attention to the type of sampling (On Demand, or HW Timed, N samples). What cDAQ modules are you using in your two Chassis?
As far as the error codes that you are seeing, could you please tell me what version of LabVIEW you are using and what version of NI-DAQmx driver you have on your system. This will better allow everyone to assist you.
11-08-2011 05:05 AM
Hi Beau
Thank you for your answer. In the 'primary' chassis there are three RTD modules (9217) and a current module (9203) installed. In the 'extension' chassis there's a single thermocouple (9213). The whole thing is running on a Win7 box with LabVIEW 2011 and DAQmx 9.3.5.
Both assistants collect data continuously at a rate of one sample per second. I guess it would be better to have one of them acquiring data on demand. But how do I actually trigger it? I don't have any means of synchronising the chassis at hardware level. Timing is not critical anyway as I'm monitoring/recording a very slow process that is going on for a couple of days. In order to avoid access conflicts between the two assistants I have connected their error out- and inputs.
Hope that helps...
Best regards
Markus
11-09-2011 03:24 PM
Hi Markus,
Based on the modules you've identified, I'm curious to know how are you setting these up in Daq Assistant? I'd also be interested to know when the error is occurring. Has this happened while you've been watching the program, or while you are away? Is this occurring everytime the program is run? I think that is key in determining if this is a programmatic issue or a connectivity issue in the system.
Regards,
-Dave C
03-29-2012 03:11 PM
Hi there, I recently helped a customer that ran into this error and I wanted to publish the way I solved it for him.
While searching, I found that this appears randomly on windows computers. The error has been attributed to all sorts of problems, but is mainly caused by registry errors (corrupted or missing registry entries). Basically is a Runtime Error, caused by the way in which your computer is unable to read many settings that it needs from the registry, causing your system to run slower and with a lot of errors.
Surprisingly enough I could not find a Microsoft KB on this error but the way to solve it is by cleaning the registry. Several software might do the trick but I personally like CCleaner, which you can get for free
Good luck!
02-15-2013 02:57 AM
Hi there
After a long while of abcence I was again confronted with this problem and forced to solve it. What worked in my case is disabling all the (advanced) energy saving options that could be related to my USB cDAQ Chassis. The system has now been acquiring data for over a week without any trouble.
Regards an thanks for your inputs!
Markus