USB Raw Error: -1073807298 -- I don't think there's an easy solution....

[MALathon]

Hello folks,

I'm currently working on implementing a temperature controller using a vendor distributed USB driver.  I've spent the last three weeks troubleshooting this error:

-----

Error -1073807298 occurred at VISA Write in W&R2.vi->GetState.vi->Main.vi

VISA:  (Hex 0xBFFF003E) Could not perform operation because of I/O error.

-----

It occurs intermittently, and not right away  From the perspective of a temperature controller, this appears to only occur when im setting the temperature and waiting for it to reach temperature.  Unfortunately the vendor doesn't focus their time on troubleshooting these things (they have their own stand alone application), and so I'm afraid I'm on my own.  

I've included an NI-trace where I set the temperature from 30 to 50 to increase at 10C/min.  The error occured at the very end:

https://www.dropbox.com/s/8quv8r78wpih987/NI_Trace_30-50C_10C-min.nitrace?dl=0

The trace shows 2 different devices -- the one in question is on address: USB0::0x03EB::0x201D::001::RAW

I am using Win 10 and Labview 2015.

Thanks for any/all help.

Edit:

I am not including the VI in question because it is not mine (commercial product).  However, I can tell you that it is very simple.  Write VISA followed by a Read VISA.

[JÞB]

Could you name the device? Maybe even supply a link to the manual or user's guide?

Seriously?

 "I'm currently working on implementing a temperature controller using a vendor distributed USB driver"  Does not help us help you.  We need to read the documents the unnamed vendor should have supplied!  

Or, you can read them youself and hope you can translate them into functional cocde (Oh. Yeah, functional code the Forums Speciality!)  What is that device?

[MALathon]

Sorry for not including much.  I didn't know where the problem stemmed from, so I incuded what I thought would help.

Here is the relevent information:

Company: Instec

Device: MK2000

I've PM'd you the functional VIs as a zip.  I do not want to include them in this forum, since they are not mine to share publically.  

Here is the user manual.  Notice that there isn't much in the way of specs for the USB communication. Also note, this is not the driver that is to be used (see next link).

https://www.dropbox.com/s/1naqs0olyg0viwd/mK1000%20LabVIEW%20Manual.doc?dl=0

I've also attached a link the driver, if that happens to be any help.

https://www.dropbox.com/s/gnsacmxx5rx44yo/mK1000-2000-Labview-USB-driver-win7-8.zip?dl=0

My first post describes the issue, but I'll re-iterate here:

I am receiving an error that occurs intermittently and happens after I perform a temperature ramp (set the final temperature and the rate to achieve said temperature).  The problem does not happen right away, but rather errors our sometime (randomly) while reaching final temperature.  Once the error occurs, I can no longer communicate with the device.  The only solution is to disable and re-enable the driver in the device manager.  

The methods I am using are as follows:

open device --> in the program while loop I perform "get state" followed by "get data", if "ramp" or "hold" is called then those values are set and then the state machine returns to "get state" followed by "get data" --> upon exit I call "close device"

The code I've written is monstrous and includes capturing data from multiple sources.  I can take screen shots of the individual places in my finite state machine where I call the temperature controller if needed. However, note that in the first link, the simple pprun program provided by the vendor also errors out (so I've ruled out my code).

Thanks!

[DanRen_IQA · Accepted solution]

I have suffered intermittent and seemingly random communication issues in USB instrument communications as well. In one particular case it was with an NI USB device. The problem actually turned out to be the USB cable going to the device. Someone had substituted the original NI cable with a less robust cable. The original NI cable had a ferrite bead at one end to help supress noise. The replacement cable did not. Once I changed back to the original NI cable, the intermittent problems went away. I don't know if this is your problem, but a good USB cable made all the difference in this application.

Good luck.

[MALathon]

Holy crap.  This solved my problem -- it wasn't the cable, but the USB hub.  What a piece of junk.  You're a life saver.  Thank you so much.

[DanRen_IQA]

A great Thank You would be to mark my suggestion as a solution.

Cheap USB hardware is rarely worth the so-called savings.

Glad things worked out. 

[rolfk]

Many noname manufacturere do little more than taking the reference design of the chip manufacturer and putting a more or less fancy housing around it. For the price they sell it you also can't really do anything more as the margin is minimal. Then they go to make more savings to get a few more pennies by buying chips on the spot market that often are cheap copycats of the original manufacturer with various bugs and limits.

Here too, you usually get what you pay for. Not a big problem for your home mouse or home automation hobby project as it simply increases the adventure of tinkering with hardware to make it finally work, but a real pitta in an industrial project with deadlines and a production line that costs thousends of dollars for every hour it is offline.

[labviewette]

Hello all,

I would like to share my experience on a similar problem as in this topic:

I developed a program to control 3 usb devices with my LabVIEW 2015 Developement System running on Windows 7. The aim was to create a stand alone application to run on a Win10 test system. After installing LabVIEW runtime engine, VISA and VISA runtime (15.0) on the test PC and running the application I got the error -1073807298. When debugging I followed the recommendations posted on the NI-sites including making sure that VISA Buffer was configured in a manner to keep VISA from executing the flush call. I also removed the usb-hub the devices were connected to since i/o problems are sometimes related to its use. The error prevailed. When comparing the test PC with the development PC i noticed that the VISA Version on my development system was an older one (14.0) than that of the latest release on the test system.

When installing VISA and VISA Runtime Version 14 on the test system my problem was solved. The error no longer showed up. I even could use the usb-hub without any effect on performance..