nienet100 issue with some devices not communicating

[Steve_Steiner]

I have a system I am using the nienet100 to controll several instruments from a Linux system. About a year ago, the agilent 345a DMM in the system stopped responding to GPIB commands from the driver I wrote. All I get is random readings from the DMM buffer when I ask for the resonse. the driver is written in C and uses the gpibapi libraries, calling ibdev, ibwrt and ibrd. After investigating for a couple of days it started responding again. We changed the instrument, rebooted the computer, but nothing worked. i assumed i changed some gpib setting, but have no idea what fixed it. Yesterday it started ignoring the commands again. I investigated  for a while. Replaced the DMM, rebooted , cycled power. All no help. Today, we booted up a different OS on the same computer, and the driver was working. Then we went back to the original OS, and it was working. I am thinking there must be a setting that gets stored and retreived for the GPIB or the Enet100 during the OS boot, and the second OS had a different setting that got carried back to the first. Although, i would not know how. Can anyone tell me if this is a possibility, or if they have a potential solution to this very strange problem?

[kellis.wiseman]

Good afternoon Steve, 

This does seem like a frustrating situation! Unfortunately, since this issue is so inconsistent there is likely not much I can do to help you diagnose it. If you are able to get a Spy Capture of the behavior, please post it and I will see what I can do. It would also be interesting to know whether this issue occurs with any other GPIB interfaces on your network. If you think of any other relevant information, please let me know. Thanks!

~kgarrett

[Steve_Steiner]

No, all other instruments are fine. I know the agilent 3458a is an older instrument and may require different GPIB settings than the other instruments. When it was not working, I was able to get it to work when I changed the EOS setting from 0 to 0x4D, but it was only temporary, so I am not sure it was really a clue. I was just thinking that maybe the enet100 had settings stored somewhere in the Linux OS that get recalled at boot time or something.

[kellis.wiseman]

Hey Steve, 

You are right that it likely requires different settings. When you say the change in EOS was only temporary, what do you mean? Your driver could have trouble with its EOS, and that could be your trouble. It could also be a reminant in the Linux. Again, without more information on what specifically happens before the devices stops working, and how it exactly behaves when 'broken,' I won't be able to give you a definitive answer. Sorry I could not be of more help!

~kgarrett

[Steve_Steiner]

What I meant was changing the EOI only fixed it temporarily. Once I restarted my driver, the instrument started ignoring my commands again. As for more information, I wish I had it. We have code running that is performing tests using the 3458A and other instruments, suddenly during the test, the DMM stops recognizing the commands from the test code. It is like some other driver changed a lower level driver setting and did not put it back, and the DMM driver expects it to be in the other state. I know none of this helps really. I did find that if i replace the gpibapi calls with VISA calls, I was able to talk to the instrument without a problem. There must be something the VISA libraries automatically sets that the gpibapi libraries does not. This may be my solution for now. I am just woried because I have other drivers that still use the gpibapi libraries, and they may still experience this issue.

Thank you for your time.

Steve

[JtotheB]

Hey Steve,

Your initial idea was correct, in that certain hardware settings are held over in the BIOS regardless of the OS. A simple example (which I'm sure you have experienced as a Linux user) is the way that the system clock changes if you switch between Windows and Linux, since they interpret the BIOS system time differently. It wouldn't surprise me at all if the GPIB calls are very low level, since the bus itself is very low level. VISA is generally smarter about keeping itself within a particular OS, and remaining at a higher level than the GPIB calls. So, it would be my educated guess (with what little I know about your particular driver) that you will have fewer issues using VISA calls rather than sticking with the gpibapi calls. I would recommend replacing your GPIB calls with VISA calls if you are worried about running into problems. Hope that helps, and have a great day!