ReadString() and "Time limit exceeded to complete operation."

[Tasogare]

Hello!

I'm having somewhat annoying problem with GPIB communications. I've already read the following threads...

http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Random-GPIB-timeout-error-in-NET-application/...
http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/ReadString-get-time-limit-exceed-to-complete-...

... and I've tried the suggested solutions with no luck.

The setting:

- Windows 7
- Visual Studio 2008
- Latest GPIB-drivers (15.0)

- USB-GPIB-HS

We're running a test software in our production system that has been programmed by using VB.net and C# (Visual Studio 2008).

When I try writing (_device.write("Q0;HV;RES?")) and reading (.device.readString()) as fast as possible on my work desk (laptop + USB-GPIB-HS + Finero Quanti safety tester) everything works just fine even without any delays in the code. I get approximately 17 replies in a second. I tried this 100 times in a row (for-loop). No problems, exceptions or anything.

The second I march out the door to the factory floor and try the same code in one of the testers I get "Time limit exceeded to complete operation." -error. And it's totally random and at the same time not so random. There are ~4-6 testers using the same code right now (with the exception of 50 ms delay between every write and read) and the next tester fails the first .readString()-command 90% of the time. All the testers are identical. The tester finished safety testing -sequence only ONCE out of six.

The only difference is that I'm using laptop and the test-PC's in the testers are new Advantech industrial PC's (also running Windows 7).

First I tried 50 ms delay between the write and read command. Then 250 ms. A second. Two seconds. NOT WORKING. Frustrating. I've been working on these new Quanti codes for a month now and I can't release them into the production if it's not 100% reliable.

Should I tweak GPIB settings? Delay is too short/long? EABO (6) means "I/O operation aborted." (what do you mean "aborted"? Why? It doesn't even try to read.)

Any ideas?


Ps. At some point I got the same error on my laptop but only once. The problem vanished on its own without no apparent reason.

Janne Yli-Arvo, Testing Engineer

Tel +358(0)40 8371 973

Vacon Plc, Runsorintie 7, 65380 Vaasa, Finland

Driven by Drives, www.vacon.com

[mattsnow]

Hello Janne, 

So the test software works correctly in a development environment (your laptop) but not when it's deployed on a tester? I would like to gather some more information to begin troubleshooting this issue:

Is the architecture 32 bit or 64 bit on both your laptop and the testers?

What versions of .NET do you have on both systems?

I have found some steps that you can look at to adjust settings in how LabVIEW handles .NET and also there are some key steps as to how Microsoft certifies programs to perform .NET calls. Please see the following articles:

http://digital.ni.com/public.nsf/allkb/7457727C38B7B7B386257CE5003461B5?OpenDocument

http://digital.ni.com/public.nsf/allkb/9A7E2F34EC9DDEDE86257A09002A9E14?OpenDocument

http://digital.ni.com/public.nsf/allkb/8D323E2921DDEBD3862574F8007F5377?OpenDocument

http://digital.ni.com/public.nsf/allkb/F1236C50E9F3D7E68625714F0065E756?OpenDocument

Let me know if these steps make any difference to your issue. I will continue looking for other solutions in the meantime. 

Kind regards, 
Matthew

[Tasogare]

Our Production Testing Application has nothing to do with LabView 😛 It's just using NationalInstruments.NI4882.dll 🙂

Both the laptop and the testing PC are using Windows 7 64bit although the testing program is 32bit.

.NET (Framework?)version is 3.5.

[mkossmann]

Is NI-MAX Installed on your test-PCs ? Can you reproduce the problem by sending the same command strings  with the "Communicate with Instrument" utility in NI-MAX ? Is there a difference if you use  Query for the second command string or a Write followed by a Read ?

Does the instrument provide a status register with something like a  "measurement finished" flag ? 

[Tasogare]

- Latest NI MAX installed
- Aaaand that would be no. Can't reproduce it.
- And I'm not sure about the last part... the last command (last write) in the picture is the "Here's the parameters and start the test" -command line. It should reply either "OK" or "ERR X" (Where X is something between 1 and 33). No such luck, I'm afraid.

FYI: We had an idea and changed USB-GPIB-HS to PCI-GPIB that we happened to have ... no problems so far (28 tests)

[mattsnow]

Apologies, I may have misunderstood the initial question!

---

FYI: We had an idea and changed USB-GPIB-HS to PCI-GPIB that we happened to have ... no problems so far (28 tests)

---

Have you got another USB-GPIB-HS that you could try? Obviously it would be good to get to the root of this, but would it be possible to use the PCI version on the production line? 

Have a good weekend. 

[Tasogare]

So I felt good about the PCI-GPIB -cards that we had (in a locker behind a locked door in the basement) and decided to release the new code to production testers (18 in total).

Four more testers decided to act up and be not-so-co-operative (for instance, they somehow "lost" the instrument (Quanti) permanently in the middle of testing) so I changed PCI-GPIB -cards to three of these testers (we happened to run out of GPIB-cables). Not a single problem since that. Except for the one that still has USB-GPIB-HS.

Are we just having faulty USB-GPIB-HS devices or is USB-GPIB-HS just inherently piece of junk? 😄

- Janne

[mattsnow]

Hey Janne, 

I have been looking into our systems for any record of a similar problem occurring with USB-GPIB-HS. However I have not been able to find any more reference to this. This makes me think that there must be some variable in your system that is incompatible with the USB-GPIB-HS and causing this problem (and hopefully not that the hardware is just junk!). 

I'm glad to hear that the problem is fixed by swapping to the PCI-GPIB cards. Obviously this does not solve the actual problem with the USB-GPIB-HS but since it is now working correctly are you able to use this option for the rest of the test machines? 

Kind regards, 

Matt

[Tasogare]

There was five testers (out of 20-ish) that were acting up and we changed PCI-GPIB -cards to every one of them. Today I heard another tester "broke" but there's nothing we can do about it until I get my shipment of PCI-GPIB -cards and cables (probably during this week).

This means there's another 15 test systems that are operating just fine with NI USB-GPIB-HS's (Is that correct? I don't know what the plural form is :D). As this is part of my job as a Test System Engineer I wish to understand and know why this problem even exists. So frustrating O_O

It'd be so easy to just live with an explanation that "yeah, these USB-GPIB-HS devices are broken" and move on but a) what could have broken them? b) these things seem to work just fine on my laptop -.- and I'm not going to lie to you: GPIB hardware is pretty expensive 😄 I'd expect it to work

[mattsnow]

Hey Janne, 

Of course when you have such a large number of this hardware it would be good to know what is actually causing the problem! I'm sure we can get to the bottom of this. 

That's interesting that the vast majority work without any issue. I'm going to have a think and consult some colleagues on how to go about further investigating this. 

Kind regards, 

Matt