GPIB errors while running from runtime but OK when using full development

[tylers32]

I have a system setup where a GPIB ENET/100 is controlling two WT230's.  While running my software (an exe) on a computer that has Labview 8.0 full development, the system operates. (although NI Spy does show there are some errors, <EADR, ENOL> these pass through without any hang ups)

However, when I run the same exe file on my customer's computer (using labview 8.0 runtime as well as NI-MAX, NI-VISA, NI-4882, etc...)  it will run from anywhere from 5 minutes to over an hour before the GPIB stops communicating.  When I run the NI Spy, it shows the repeated error:

iberr: EDVR (0)

ibcntl: 0xE1060077

Once this happens, i can close my software and re-start it (without initializing the WT's) and it will work OK for another 5minutes+. 

I looked up this error code on the website and it does not appear anywhere.  I thought it may be a driver issue so I verified that all the runtimes installed on the customer computer have the same version as on the developer computer...and they match. 

Any thoughts?

Thanks

Tyler

[Robert M]

The description for error 0xE1060077 indicates a "socket I/O failure" or a "winsock error."  This description points to some sort of network issue.  I assume these instruments are connected through a network and not through a crossover cable?  After a failure can you ping the ENET/100 from the PC?  Can you post a copy of the .spy files for both PCs?  What versions of NI-488.2 and NI-VISA do you have installed on both machines?

[tylers32]

Thank you for your help Robert,

I am running:

NI-VISA (3.4), NI-488.2 (2.43), Trad NI-DAQ (1.0.2), NI-PAL (1.10.0f0), NI-Spy (2.3.0.49152), NI-MAX (4.0.0.3010), and the labview runtimes for 7.1 and 8.0  on both machines.  The only different software is CVI RT (7.1.1.350 on the "working" machine and 7.1.0.307 on the failing machine.)

The failing computer has 2 network cards in it...I have updated the drivers both, and switched to the other card...but the GPIB still failed.  I have not tried pinging the GPIB after it fails - but closing the software and reopening it (skipping the WT init) will allow them to resume operation for a bit. 

The connection is through a network which has a small hub which connects to a few MX100's, a few OPTO-22 controllers for input/output, and the single GPIB-ENET/100.  I have not used the same network cable on both computers though.

Attached are 3 spy files, the one is from when the unit fails and the other 2 are "normal" operation from both computers.

Do you think that if I attached directly to the GPIB (bypassing all network) i will get a response to the "*IDN?" query?  When both computers connect through the hub to the GPIB, neither gets a response to that query (EABO  error).  Also, do you think that EOI/EOS settings could be causing some problems?

Thanks again,

Tyler

[Robert M]

It looks like whenever you try to send data to a device at an address different that 1 or 2 you get errors, but 1 and 2 work.  I assume your two instruments are addressed 1 and 2, so why are you using other addresses?  Do you mind if I take a look at your code?

If your instruments support *IDN? then they should respond whether you are connected to the hub or directly to GPIB.  It shouldn't make a difference.

[tylers32]

I fixed the problem mentioned above where the GPIB was trying to communicate with non-existant devices...now when I run NI Spy, I get no errors. 

I also replaced the RAM in the machine (as I have read that may cause the EDVR error) and upgraded it to 1gb where it was only 512mb before. I switched DIMM slots for the memory as well.  I replaced the hub on the network and put new ends on the cable for the computer as well as the cable to the GPIB.

Just now, I installed an evaluation version of labview 8 on the computer and ran my exe.  I still get the EDVR error.  It appears to be random as it occured this last time around 15 minutes after turning on the program; other times it will be up to 2 hours.  Not only the sporadic nature of problem, but also the fact that it does not seem to affect the 3 MX100's nor the 2 Opto22 brains on the same network. 

Is it possible that there is a hardware problem with the GPIB or possibly the WT230's that would be causing this?  According to the manual, the WT230's should accept the *IDN? command, but they do not.

Tyler

[Robert M]

You may want to try connecting the WT230's directly to the PC over GPIB and testing out *IDN? (you may need a termination character, usually codes display \n) to make sure the WT230's are functioning properly.  If the other devices are working fine over the network the issue probably lies with the WT230's.  Do you have a busy network?  Is it possible that packets occasionally take a longer time to get to the WT230's and they timeout?