GPIB Startup Sequence

[HuffmanR]

We are comunicating to several pieces of equipemtn
1) HP 3458A Address 21
2) HP 4285A Address 17
3) Custom Controler Address 1
4) Master computer Address 0

Now the Problem
When I Start the Application with 1,2,&3 On, The Comunication to the HP3458 & the Controller works fine, and I can SEND commands to the HP4285A, But Can not Read from the HP4285A.

If I Turn off the Controller, Start the program But NOT LOG IN, And Then Turn on the Controller, All Comunication Works.

The Weard thing is, is that Before I Login, there is No
GPIB Comunication setup, and All GPIB Initilization Occures AFTER The Login.

RUNDOWN
Software Start When ALL Systems on, No Reading HP4285A
Software Starts Before COntroller Turned On, Can Read HP4285A

Al
so.
IF All 3 Systems are turned On, and I Use the Measurment Controller, I can Send the Same Commands, and It All Works.

The Read Command is as follows
Call ibwrt(Brd_LCR%, "FETCH?")
LCR_Results$ = Space(29)
Call ibrd(Brd_LCR%, LCR_Results$)

Thanks for any help you can give.

[ScottieB]

Hello,

Could you please give me more details regarding your setup? Which device has the National Instruments product in it? What National Instruments GPIB product are you using? What operating system are you running? What is your driver version?

What is the "custom controller" at address 1? Do you have multiple controllers in charge? What is the "master computer" at address 0? Is it a controller in charge? When you say "login", what do you mean? Is this on a Windows computer? Is the program running on it set to run something when you login?

You have a pretty complex setup and I want to fully understand it before I answer your questions so that I can be as helpful as possible.

Thanks,
Scott B
Applications Engineer
National Instruments

[HuffmanR]

Further Detal

1) The "Custom Controller" is a DOS Slave Computer running on Channel 1, Listening Only to GPIB Commands to Control a Digital Switcher, And 2 Analog Sources.
2) The Only Controller in charge is the Master Computer Running Windows XP and using a USB-GPIB Controler
3) The LOGIN is a Software Login in the program that we are developing. The Startup Sequence for the Visual Basic Application is From as Follows From "Form_Load"

1) Connect_Database (Makes a connection to a SQL Database)
2) User_Login (Get User name & Password for data Security)
3) If Login is valid then
4) Get Product List from Database
5) Setup GPIB
6) Setup HP_Meter first on Channel 21
Call ibdev(0, HP_Channel, 0, T10s, 1, 0, Brd_HP%)
Call ibclr(Brd_HP%)

Call ibtmo(Brd_HP%, 0)

7) Setup LCR Meter second on Channel 17
Call ibdev(0, LCR_Channel, 0, T10s, 1, 0, Brd_LCR%)
Call ibclr(Brd_LCR%)
Call ibtmo(Brd_LCR%, 0)

😎 Setup SlaveBox last on Channel 1
Call ibdev(0, SB825_Channel, 0, T10s, 1, 0, Brd_SB825%)
Call ibclr(Brd_SB825%)
Call ibtmo(Brd_SB825%, 0)

[ScottieB]

Hello again,

If you power all 3 devices up before you login, are you sure that your writes are successful to the devices, or do they simply return success? I'm wondering if your GPIB bus is in some sort of bad state when you power up the custom listen-only instrument on address 1. Can you write to the GPIB bus and everything works as expected? Also, what error are you seeing when you try to read? Does the read simply timeout, or does something more interesting happen?

Since GPIB is a bus protocol, it does require every device to "play nicely", so I it seems that the address 1 instrument is interfering in the handshaking or the addressing of the other instruments. What if you comment out the code that communicates with device 1? Does ev
erything aside from the device with address 1 work? What if you comment out the ibclr(Brd_SB825%) above? Perhaps the device does not properly respond or does not understand the SDC (clear) command, and this is what puts the bus in a bad state. Without a picture of what exactly is going on on the GPIB, it's hard to guess.

If you have a GPIB Analyzer board (such as a PCI-GPIB+), it might be interesting to see the difference between the slave box (address 1 device) being on the bus or not.

Scott B.
Applications Engineer
National Instruments