USB 1208LS Strange Error Message

[JBROCKNHT]

Hello all,

I have spent the last 6 months developing a fairly complex LabVIEW application to control an automated test fixture.

Everything is working fine apart from an error message that seems to happen randomly.

I am using a Meaurement Computing 1208LS and the ULx LabVIEW Library.

I keep getting the error:

Ulx Write (Digital Bool 1Line 1Point).vi<ERR>

Digital device is not responding - Is base address correct?

According to the documentation for an earlier set of drivers, the 'Digital device is not responding - Is base address correct?' error is a result of a defective board or an installation problem.

I have reinstalled the board several times and tried multiple boards but keep getting the same problem.

I am connecting the USB 1208LS thru a usb hub but the documentation advises this is ok.

I had the same problem with another test fixture and removing the hub and running the USB1208ls straight to the pc solved the problem.

However removing the hub on the current fixture is not an option as the DAQ must be powered up as soon as the fixture is powered on.

I would really appreciate any thoughts anyone may have on this.

Thanks a lot

Jamie

[gaving]

I'm not sure too many people on these forums are as familiar with the 1208 and its driver.  While you wait for a response here I would submit a request to MCC too. Measurement Computing Support Form

...just a suggestion...

[JBROCKNHT]

Hi gaving,

Ive now spoken to Measurement Computing they are trying to help also.

Thanks for the advice

[Alex.T]

Hi Jamie,

Do you have any updates on this issue? Given that this problem occurs sporadically, I'd be more inclined to think that the interaction task fails due to the USB Device losing power or being relocated to a different address on the bus; this is usually a problem when extension hubs are in use because of the way that they handle data payloads. They're great for distribution of power, but it's recommended that they're avoided in DAQ applications.

Just to check, does this issue only happen when it comes to the Ulx Write (Digital Bool 1Line 1Point) task, or is it the only function you're using in this application?

Can you expand a little on why you can't remove the hub? Is the USB not powered immediately in your hardware configuration?

It could be possible that your development machine is entering a sleep state and discontinuing the power source to the USB after a set timeout period. Have you checked the power settings of your machine to ensure that the USB's power isn't shut off after a set amount of time? 

Kind Regards,

[JBROCKNHT]

Hi Alex

Yes Im hoping to hear back from Measurement Computing today or tomorrow with their thoughts on the issue.

The error does only occur at the Ulx Write (Digital Bool 1Line 1Point) operation. I am also using:

ULx Read (Analog DBL 1Chan 1Samp).vi 

The reason I cant remove the hub is due to problems with the Interface board it is driving.

The interface board is powered from the test fixture whilst the DAQ unit is powered with USB 5V from the test PC

If the test fixture is powered on before the PC then the digital output coming from the DAQ to the interface board loads the input and stops the interface board from initialising properly.

By connecting the DAQ to a powered usb hub which is powered from the test fixture, All of the control circuitry including the DAQ unit turns on at the same time.

It is far from an ideal setup, it all stems from having to add modifications to my interface board as I was having problems with it powering up in an unknown state each time.

Hope that makes sense.

I will check on the possibility of the pc cutting power off to the usb as it goes into sleep mode, but I dont think this is whats happening as the pc is running a large labview app constantly talking to the DAQ unit. 

Many thanks for your suggestions.

Jamie

[Alex.T]

Hi Jamie,

Have you received any further information from Measurement Computing that might be able to help us out?

Based on your circuit configuration, we could try working around this power up issue by implementing a Solid State Switch to the power line of your circuit. This way we could still connect the USB device directly to the USB line and have the test fixture power up the connection circuitry on request.

[dpklaus]

Hi Jamie,

     In case it helps, I am currently getting the same error from one of the Measurement Computing subVIs, though the symptoms are slighlty different, and may illuminate your case.   I'm using an MC Minilab-1008 DAQ to control pneumatic cylinders used in an endurance testing apparatus.  The LabVIEW program turns two solenoid valves on and off in sequence, over and over.  The TTL signals from the DAQ are sent to a relay board, where the signals are amplified and used to turn AC relays on and off, which switch the solenoid valves on and off. 

     This system worked correctly for the first few days of its operation.  However, recently the system began to operate in the following way: Everything would work fine for a second or two, then the system would freeze and the board would output an error for a second or so: "Digital device is not responding - Is base address correct?", then briefly display another error for a half second or so: "Invalid Board Number" and then go back to functioning normally (digital outputs resume their desired values) for a few seconds, before repeating the same two errors again, etc. etc.  This seems similar to your own error.  At first it was also happening randomly, but now it seems to be happening more and more consistently.

     We suspect there may be a fault in the relay board, as this pattern of error disappears when we disconnect the AC input/outputs from the relays on the board.  This seems to suggest that the AC line, when plugged in to the board, is interfacing with the minilab-1008 in a way that causes it to reset.  We have ordered a different relay board and are also diagnosing our current board.  It sounds like this may relate to your problem, as it might be an issue of an unwanted interference or power signal (perhaps from your USB hub, perhaps from some other source) feeding back and doing something which trips some protection circuit in the hardware and generates the error message you see.

     Anyway, I have also contacted Measurement Computing to troubleshoot this problem.  Please keep me posted if you find anything useful out that helps you diagnose and solve what you're dealing with.

Best,

David

[JBROCKNHT]

Hi David

Thanks a lot for the info, nice to know Im not alone with this problem..

Lily at Adept Scientific has been very helpful in trying to solve this issue, she has had the developers of the LabVIEW drivers looking at the problem but unfortunately they have come back with no answers really.

Their only suggestions were:

-Remove USB Hub

-Is it an electrical problem, i.e. ground loop

-Is it interference from a large motor or inductive load

-Is it through trying to run concurrent operations on the DAQ device

Now that you are having the same issue though, it does make me wonder about an inductive load kickback issue, as we are both driving relays...

Although I had the exact same issue in another test fixture which did not use relays, removing the USB hub from the path between the PC and the DAQ unit solved the problem in that case.

My current solution is to search for the 'digital device...' error string when an error occurs and simply clear the error. (using labview 'clear errors.vi')

I have found that clearing the error is enough to make the DAQ work.

It is not a solution im happy with but I need the rig working and it seems to do the trick.

Ill keep you posted with any developments, I would really appreciate it if you do the same

Jamie

[Process_Systems]

Good afternoon gents:

I have been using the 1608 in a product I produce for years, and I long ago found out that using a USB hub between my PC and the 1608 was not reliable. It seemed to depend a lot on the quality of the hub, as I tried several different hubs, both powered and passive, with mixed success. One thing I did notice, if I plugged/unplugged a different device into one of the other ports on the hub, it would somtimes generate an error in the daq process. I traced it back to the fact that the instacal driver software was sensing that the 1608 had been momentarily unplugged and re-connected, and attempting to assign a different device number to the 1608. This didn't always happen, but I was able to find this on several occasions. I am seriously considering changing daq hardware on projects going forward because of this. My two cents, for what it's worth.

Good luck,

Dave

[JBROCKNHT]

Hi Dave

Thanks a lot for your input.

Thats making me think actually... The device I am testing is connected to the test PC via USB and a virtual comm port.

At various points in the test I need to cycle the power to the device which I am doing by using a digital output from the daq to a FET in the USB power line.

So when the device repowers and is redetected by the PC this could be what is causing the daq to momentarily lose power, which is what generates the 'digital device error' I am getting.

Food for thought, 

Thanks

Jamie