Scan for instruments fails

[ndiamond]

Computer 0: System controller, primary address 0, PCI-GPIB.
Computer 1: Non-controller, primary address 1, GPIB-USB-B.
Both: Windows 98, driver version 2.0 after upgrading from original 1.7, otherwise defaults (no secondary address, timeout at 10 seconds, EOI on last byte but no EOS, bus timing 500 ns, no HS488, automatic serial polling is on). Each machine's MAX observes its own interface GPIB0 with no problems and local tests are passed.

Both: When using MAX to scan for instruments, scan cannot be done because each machine thinks that the other one is powered off or there is a cable problem or whatever. So it looks like a cable problem, but I don't think it is.

The blue box of the GPIB-USB-B can be plugged directly into the con
nector of the PCI-GPIB. It doesn't matter if I put a cable in between or not. Neither machine can detect the other. So I don't quit e believe it's a cable problem.

On the non-controller I turned off automatic serial polling (not sure if it means anything on a non-controller) but it made no difference.

On the non-controller, when trying to scan for instruments, the "activity" light flashes a bit. I wonder why non-controllers are allowed to try this operation, but fortunately this capability yielded this observation. When the controller tries to scan, the non-controller's activity light doesn't visibly flash. So I don't think the USB cable is damaged either.

The two computers example also fails, they can't detect each other on the bus.

Any ideas?

[NI-488.2 master]

The boards really aren't designed to detect each other with the MAX Scan for Instruments. Scan for Instruments really requires that a few more things happen at a higher level. The first problem is that the non-controller may not be online. If you haven't explicitly opened a GPIB session for the non-controller, then it's not going to participate with anything happening on GPIB. You actually need to program it to respond to the query. You may look at what is happening during a scan for instruments by launching NI-Spy.

If you bring the non-controller online with the interactive control utility, the scan won't completely fail. The scan will detect that there is a device on GPIB, but that it didn't respond to the *idn? query. Do the following in ibic
for the non-controller:

ibfind gpib0
gpib0:ibrsc 0
gpib0:ibpad 1

After doing this, you should see that the scan has detected "Instrument0" at PAD 1.

Hope that this helps to clarify things a bit.

[ndiamond]

Sorry to say, the answer seems to be quite different.

The machines were powered off overnight. In the morning, the machine with the GPIB-USB-B decided that it detected a new GPIB-USB-B, Windows 98 rebuilt its driver database, and everything looked the same as it did yesterday. But things behaved better afterwards. It seems that after the initial installation, when the installer offers to reboot, a reboot isn't sufficient. Even when Windows 98 rebuilds its driver database and assigns the correct driver after a reboot, it isn't sufficient. The computer must be powered off and powered back on again. (I hope it doesn't really have to sit overnight, but can only observe that it did so before being powered on and working.)

This seems like really odd
behavior for a USB device but seeing is almost believing.

After that, I did what you said, and the results were as you said. Your answer helped confirm that the connection is now working, but sorry to say that the power-off power-on cycle brought it to this state.

Before running the downloaded two-computers example, I opened up MAX and observed that the settings had been returned to their defaults when the USB device was redetected and had its driver assigned again. I set it to non-system-controller and PAD 1. After that, the two-computers example worked perfectly.

[NI-488.2 master]

I would recommend that instead of relying on the configuration utility to set the PAD and system controller state, you should programmatically set those values. Everything that you can configure in the configuration utility, can be configured programatically through the ibconfig call. This makes it easier for you to deploy systems because you shouldn't have to do quite as much manual configuration.

The GPIB-USB-B does have some interesting properties when it comes to enumeration. It will disappear and reappear in the device manager if the system does not stay powered. We'll look at improving this behavior in future revisions.

[ndiamond]

The problem in our case was that communication was not properly established until after the GPIB-USB-B disappeared and reappeared when the system was powered off and back on. The way it looks at the moment, if you fix the odd behavior of disappearance and reappearance, then the communication problem will get worse. The initial installation failed to communicate. If the initial installation remained properly visible permanently, then it would remain unable to communicate permanently.

In programming yes I do set the PAD and system controller state programmatically. But before running my own programs, I tried using MAX and then the two-computers example to see if I had set up everything properly. At first it appeared not so, which pr
ompted my first posting in this thread. But after being powered off overnight and back on the next morning, it started working. I have the impression that even programmatic setting of rsc and pad wouldn't solve this. I think it still wouldn't have been solved until powering off and powering back on caused the lesser misbehavior of redetecting the GPIB-USB-B and important behavior of working properly.