myDAQ powers OFF and ON after an year of good work

[joro11]

   I have successfully used myDAQ for over an year programing it in Labview 2016 (32 bit) in a Windows 8.1 (64 bit) environment. I am collecting 1 channel analogue input and under Labview control a pretty complex and expensive self-made lab instrument. Recently after a couple of hours of continuous 1 channel Analog input the board started to power OFF and immediately ON which gave a spike in my voltage readings. This was happening with increasing pace. Until today it started directly constantly to power OFF and ON in a rapid pace as seen from the blue light. I have changed the USB cables and the USB ports with no change.

   I have tested the board with another (Win 7) computer. The board is constantly ON as it should be. In the Device Manager everything looks good. It is recognized in the NI MAX but in a strange way: NI myDAQ "c0000c96" or some other combination of letters. The Self-Test button is not available. The board serial number is displayed with no buttons displayed on the top except for Refresh button. Trying to program the board in Labview the DAQ Assistant starts to read system configuration with no success.

   I believe this is a hardware problem?  And considering its price I should throw the board and buy a new one? Can someone suggest some solution? Are these boards reliable for many years of use in a laboratory environment?

   Thanks in advance!

[oscarfonseca]

Joro11,

I see three different thigs that are happening in this case, and I recommend you troubleshoot them separately:

1. For your original computer (the one that powers on and off the hardware): it might be related to a Windows update or the ports of the machine itself (not being able to supply the correct power to the beard after some time). I suggest you check: USB Device Disconnects and Reconnects Periodically on Windows PC
2. For the computer with Windows 7 that shows the device with the "weird combination of numbers and letters", it looks like a problem with Windows not assigning the driver correctly: My NI USB Device Shows as a USB-RAW Device in NI-MAX on a Windows Machine
3. Finally, if you consider this is a hardware issue, you can call support and ask for an RMA quote. You can compare it with the price of a new device and decide the best course of action.

All the best,

[joro11]

Dear Oscar,

Thanks for the advice. After some experimenting I found the right USB port and cable which works OK. Now I ran into another problem. After some 5400 seconds into the experiment the software reads a value, which might be a 0 volts. Then after some 40 minute again 0, after some 30 min - again 0 at increasing pace (see the picture). Initially I thought it is a hardware problem. But in 3 subsequent experiement the first 0 appeared after: 5400 seconds; 5822 seconds; 5860 seconds - highly repetitive. So it might be a software bug. But what bug it is that shows after an hour and a half?! In my software I cycle 10 times/second and continually read 1 analog voltage (500 readings/sec) and heavily filter it; control through serial RS232 1 stepper motor and read its position, display this and save it to file. I would be very thankfull if you can advise me. Regards. George

[oscarfonseca]

Hello George,

You describe an interesting behavior, which I have not seen before with the myDAQ. I think it would be worth creating a simple loopback test (wiring an Analog Out to an Analog In) and checking if the error persists when running it for big periods of time (this would discard any "extra hardware" in your application). You can simplify this more if instead of the Analog Out you use one of the continuous voltage sources you have available in the myDAQ. If the problem is in the device or its software, I would expect to see this zeroes hop from time to time during a continuous voltage test.

All the best,

[joro11]

Hello Oscar,

Following your advice I attached a battery to the analogue input and ran the software as it is. As expected the first 0 appeared 5898 seconds after the start of the experiment, almost exact timing as the previous experiments. So obviously something is wrong and I believe it is the software. But I have no idea how to debug an error that appears almost 2 hours later. I will test a simplified version of the software of only analogue read and write to file with same timings to see if there will be any changes. Any other ideas?

Regards, George

[oscarfonseca]

Hello George,

It does sound strange. Especially because it takes so much time. I agree with your test just using a simple Analog Input. You can get a working example from Help > Find Examples.. > Hardware Input and Output > DAQmx > Voltage Input.

If you want to completely discard the Application Development Environment (LabVIEW), you can also use an NI MAX Test Panel or Task, and check it it happens there, too.

Regards,

[joro11]

Dear Oscar,

I performed a test with simplified Labview program. Within the 8 hours of measurement everything was OK. The software uses the same analogue voltage measurement, timing, filtering, visulaization and file saving. The difference is that there are not included the 2 event loops which wait for interaction to controll the 2 stepper motors over the RS232 by sending ASCII commands to the controller and position of the stepper motors is not read. Actually during measurement I just start the motor with very slow velocity and do not interact with it except for reading and displaying the position from the number of microsteps. I can not imagine how these loops can produce fake 0 volts in the analog input. I do not know how to the debug the software? Maybe I should add the features one at a time and see when the problem occurs. Though I should wait for almost 2 hours and actually the problem can occur later. Can you advise me please?

Regards,

George 

[oscarfonseca]

Hello George,

I presume this "fake data" happens right when it comes out of the DAQmx Read.vi? If you are using some lossy mechanism to transfer the data from this function to another process (for example: using a Local Variable or a Dequeue with Timeout zero) I would expect these zeroes to happen.

All the best,

[joro11]

Dear Oscar,

I have tested the software. It came out that my readout of the stepper motor position creates this strange 0 volt reading bug in my anlog input. This part of the software was developed by the stepper motor manufacturing company so I believe it is OK. But I decreased the cycle time from once a second to 10 times per second. And also a delay time after sendind the ASCII command from 1 second to 0.05 seconds. I can not imagine how the serial communcation can provoke a 0 volt reading in myDAQ?! After and hour and half of perfect operation. And it is indeed something like 0 volts and not just 1 number as I can see it smoothed in the data file. I have no idea how to work this around as I indeed need faster reading. Is there a way I can send you the software so you can have a look? The software is simple and I stick to the Express vi programs.

Thanks in advance,

George 

[oscarfonseca]

George,

It is always more difficult to debug code when it is all in the same main VI. My recommendation would be for you to find the modular pieces of code (think of them as functions in other programming languages), with which you can test individual functionality and make sure work as expected.

I can see the frustration when it comes to a program that fails just after hours of operations, and honestly it sounds difficult to debug. Therefore, my advice would be to take some time "cleaning" the code (making subVIs, and understanding in which step is that you see the problem happen, so it is easier to move forward.

All the best,