GPIB-Invalid Character and Query Unterminated

[ckryan]

---

@Jeff Bohrer wrote:

---

@ckryan wrote:

---

@Omar II wrote:

Try sending a GPIB IFC command in between sending commands to 'A' and 'B'

I had an instrument that after talking to it I could not talk to any other instrument on the GPIB bus.

But if I sent the IFC command to the GPIB card before switching to communicate to the other instruments I did not have any problems.

This instrument would also cause the VISA Find function to report back listeners on all 32 GPIB addresses!

Really messed up my routines to search out instruments that are on my system. 

---

Hi, How do I send the GPIB IFC command? Help...

---

First, Have you been able to get a response from any supported query?  (*IDN?) still won't work.

---

Hi Jeff,

Yes, *IDN? works for all the instruments. If let say I connect my A and B, B will complain "The device did not respond to a *IDN? query". A still get back the reply from *IDN?. Now I try to power-off my A and let's send *IDN? again to B, same will complain "The device did not respond to a *IDN? query". I have to physically unplug the GPIB connector to isolate A and B only I can send *IDN? to reach B.

[Omar_II]

There are two depending on how you address the bus.

Search the Palettes

The offending instrument would not release some control lines after talking until the InterFace Clear command was sent.

But if I understand you, your problem starts just by having the cable connected without first talking to it.

That might be a bad cable or a defected instrument.

[JÞB]

---

@ckryan wrote:

---

---

Hi Jeff,

Yes, *IDN? works for all the instruments. If let say I connect my A and B, B will complain "The device did not respond to a *IDN? query". A still get back the reply from *IDN?. Now I try to power-off my A and let's send *IDN? again to B, same will complain "The device did not respond to a *IDN? query". I have to physically unplug the GPIB connector to isolate A and B only I can send *IDN? to reach B.

---

Have you looked at the manual I linked in message 7 of this thread? Sending a *IDN? to the 7040 is pointless- The instrument does not support the query.  You might as well hit the darn thing with a hammer- It doesn't know what that means either and the device may ignore it or cease to function normally.  If the device WAS IEEE-488.2 compliant it would be required to respond to the command (as well as many other differances).  It is not IEEE-488.2 compliant.  Send it a "*ver" and see if you get a response- after you reset the device.

[ckryan]

---

@Jeff Bohrer wrote:

---

Have you looked at the manual I linked in message 7 of this thread? Sending a *IDN? to the 7040 is pointless- The instrument does not support the query.  You might as well hit the darn thing with a hammer- It doesn't know what that means either and the device may ignore it or cease to function normally.  If the device WAS IEEE-488.2 compliant it would be required to respond to the command (as well as many other differances).  It is not IEEE-488.2 compliant.  Send it a "*ver" and see if you get a response- after you reset the device.

---

Jeff,

The 7040 did support the query of "*IDN?" and in fact it can query the instrument manufacturer's name and firmware version but with some odd characters. I have attached the screenshot of MAX. PAD20 is the address for 7040.

AllDevices.jpg is all the 3 instruments connected.

AllDevices-BathOff.jpg is only off the 7040 bath and other instruments still on and connected.

BathUnplugged.jpg is 7040 GPIB connector physicall plugged off, then the other 2 instruments can response to MAX.

[JÞB]

---

@ckryan wrote:

---

@Jeff Bohrer wrote:

---

Have you looked at the manual I linked in message 7 of this thread? Sending a *IDN? to the 7040 is pointless- The instrument does not support the query.  You might as well hit the darn thing with a hammer- It doesn't know what that means either and the device may ignore it or cease to function normally.  If the device WAS IEEE-488.2 compliant it would be required to respond to the command (as well as many other differances).  It is not IEEE-488.2 compliant.  Send it a "*ver" and see if you get a response- after you reset the device.

---

Jeff,

The 7040 did support the query of "*IDN?" and in fact it can query the instrument manufacturer's name and firmware version but with some odd characters. I have attached the screenshot of MAX. PAD20 is the address for 7040.

AllDevices.jpg is all the 3 instruments connected.

AllDevices-BathOff.jpg is only off the 7040 bath and other instruments still on and connected.

BathUnplugged.jpg is 7040 GPIB connector physicall plugged off, then the other 2 instruments can response to MAX.

---

Yup- it reponded to the unknown command and LOCKED up the bus.  Power cycling the bath and getting the bus unF***ed shows the bath is the hoser-upper of the bus.  Just like I said, "Hit it with a hammer...." It responds badly to unknown commands.   Try sending it a command it knows.

You won't be able to use MAX to discover devices with the 7040 on.

[Omar_II]

I am in agreement with Jeff. Your device is not 488.2 compliant and does not understand *IDN?. 

I believe the reason your are getting something is that it is the default reply any time you tell the Bath to be a "talker"

To use a none 488.2 device on the same bus with 488.2 devices you may have to handle the low level GPIB commands yourself. Try bypassing VISA by using commands on the GPIB palette "GPIB Read" and "GPIB Write".

Learn about the bus control lines that you may have to control yourself.

http://www.hit.bme.hu/~papay/edu/GPIB/tutor.htm

Your Fluke Bath is not obeying the same rules that the other devices and VISA are. It is not being "nice"

Contact Fluke to see if there are any updates. 

Or learn how to control the GPIB Bus control lines yourself.

The way we had to do it back in the 80's (pre 488.2)

[ckryan]

---

@Omar II wrote:

I am in agreement with Jeff. Your device is not 488.2 compliant and does not understand *IDN?. 

I believe the reason your are getting something is that it is the default reply any time you tell the Bath to be a "talker"

To use a none 488.2 device on the same bus with 488.2 devices you may have to handle the low level GPIB commands yourself. Try bypassing VISA by using commands on the GPIB palette "GPIB Read" and "GPIB Write".

Learn about the bus control lines that you may have to control yourself.

http://www.hit.bme.hu/~papay/edu/GPIB/tutor.htm

Your Fluke Bath is not obeying the same rules that the other devices and VISA are. It is not being "nice"

Contact Fluke to see if there are any updates. 

Or learn how to control the GPIB Bus control lines yourself.

The way we had to do it back in the 80's (pre 488.2)

---

Hi,

What about if I have 2 GPIB card installed on my PC and try to seperate the command bus send to the Fluke and the other instruments? Does it make sense to work?

[JÞB]

Not really.  the "Problem" is sending commands that the instrument does not respond correctly to when addresses on a IEEE-488 bus.  Use the RS232 interface.  The manufacturer can't have screwed up a COM port right?.......OK several do (RS means Recommended Standard after all) but its only 1 instrument and not a whole bus.

[ckryan]

Guess what? It really work by having 2 PCI-GPIB cards installed in my PC. GPIB card 0 is connecting to the rest of the instruments and GPIB card 1 is connecting to Fluke Bath (non-IEEE compliant). I am getting the "Error 6 for LabVIEW: Generic file I/O error" when running the LabVIEW. NI-SPY gave me the hint that I should change something in GPIB Write ("Address", "Command", "GPIB Interface", "Timeout", "Byte"). How do I change the "GPIB Interface" 0/1 for GPIB Write and GPIB Read?

[Omar_II]

From the help

When there are multiple GPIB controllers that LabVIEW can use, a prefix to address string in the form ID:address (or ID: if no address is necessary) determines the controller that a specific function uses. For example, to set GPIB controller 2 to talk to a device on address 3, use the prefix 2:3. If a controller ID is not present, the function defaults to controller (or bus) number 0.