GPIB Configuration

Bonjour,
J'ai un problème pour connecter mon appareil(SOLARTRON 1250) à mon PC à l'aide d'un GPIB. En effet, sur MAX j'arrive à detecter l'appareil mais lorsque j'essaye de communiquer avec lui cela ne marche pas. De plus, d'autres anomalies me perturbe: -MAX detecte 2 appareils alors que j'en est connecté que un
-"Identification" : Apparament il y a un problème d'identification???
-Problème de communication voila ce que me dis MAX quand j'appui sur "query":
"iberr = EABO
EABO indicates that an I/O operation has been canceled, usually due to a timeout condition after a GPIB read. Before reading from the instrument, verify that the GPIB command you are sending is understood by your device and instructs it to place data in its output buffer. For information on your device's command syntax, consult the instrument manufacturer's user documentation."
Je pense que l'un des facteurs de ces problèmes sont l'état des boutons du gpib(definissant l'adresse de l'appareil et son mode read, write ....) vous pouvez voir ces boutons en pièces jointes.
Merci d'avance pour toutes aides
Attachments:
Probleme configuration GPIB.JPG ‏121 KB
Boutons.JPG ‏12 KB

C'est etrange qu'il y a deux ports GPIB sur l'instrument. Cependant, il semble que l'instrument supporte IEEE 488.1 ou plus vieux.
Parfois, lorqu'on envoie une commade a l'instrument, elle necessite pas une reponse. Donc si tu essais d'obtenir une reponse pour une commande de configuration, tu receveras un message d'erreur.
Le SCPI est un protocol provenant des annees 1990, alors seuls les intruments plutot recent supportent les nouvelles commandes (standard). Voici une petite description (ci-dessous). Malheureusement en anglais.
Essais d'envoyer une commande de configuration sans point d'interrogation (?) et verifie si l'instrument a changer de configuration selon la commande envoyer.
RayR
SCPI standard:
IEEE 488.2 instruments are easier to program because they respond to common commands and queries and use standard message exchange protocols and data formats. It defines precisely the format of commands sent to instruments and the format and coding of responses sent by instruments. Before SCPI, each instrument manufacturer developed its own command sets for its programmable instruments.

Similar Messages

How to configure the GPIB controller in LABVIEW or MAX to send UNLISTEN and UNTALK when each message ends?

In a PC to PC GPIB configuration, one PC is used as a non-controller and it reads either LACS or TACS status bits continuously. It apears that the controller PC does not send UNTALK and UNLISTEN at the end of each message. The non-controller reads and writes therefor times-out.
What is the correct message synchronisation for a non-controller?
I use Labview 6, PCIIA, WIN98SE.
Thanks.

Are you using LabVIEW as the controller, non-controller, or both?
NI-488.2 does have a configuration option to enable unaddressing. I am not sure of where it is in LabVIEW, but if you search for unaddressing, you should find some information on it. With unaddressing, NI-488. will unaddress the device after communicating with it.
If you are not using LabVIEW as the non-controller, National Instruments does have a software package called NI-Device that may help. This is an API designed for non-controllers. It does not currently have a LabVIEW interface. It works under C++ with a PCI-GPIB board.
A third option is to rewrite your device application. Your device should really not care about TACS or LACS as you read them from the status register Your device
should only look for LACS, DCAS, and perhaps DTAS (if you desire triggering). When it is LACS, it should read data. After a read has completed, it should interpret the data and get ready for a response. It is only at that moment that the device should look for TACS (and DCAS). It is hard to put a flowchart here, but if you design the flow of a standard instrument, you will see some patterns about when to look for certain status bits.

GPIB and RS232 communication problems

I've been having several "interesting" problems with GPIB and RS232 communications in LabVIEW VIs. Some I'll mention at the end for curiosity, but right now I'm facing a rather big problem. I'm essentially self-taught at doing LabVIEW (using 8.5.1 right now), but by now I've had a lot of experience as their either has not been any drivers or pre-made VIs for the instruments I've needed or I've not been able to get the available drivers to work and had to write my own anyway (such as with the HP 3458A), but nothing seems to be working right now. I'm not at work, but we typically find forum sites blocked anyway (I can't even download the NI drivers at work since they house them on a ftp server, go figures) so I can't give the VI itself (it wouldn't be easy to get approval even if I could) so the best I can do right now is in words describe everything I've tried. I will be happy to post follow-ups of specific details if I can if they would be helpful.
I've been working on a routine to read data from an MKS 670 Signal Conditioner/Display with a MKS 274 Multiplexer with 3 connected MKS 690A Baratrons. Previously I've worked on programs using other older displays and the analog outputs which were being read by a DAQ card, but for a new project it was decided to try and just read the data directly. I first worked with a unit with just an RS232 Serial Port which I managed to get to work, but had so much problems with garbage readings and having to add checks and re-reads that by the end no matter what delays I added between each reading and how simplified the command routine down to just 2 sequences and the read that it took at least 10 seconds to get 1 reading from each channel.
Figuring maybe it was a limitation of the serial communications for these instruments I tried to re-work it for a unit with a GPIB port with which I'm actually much more familiar. The problem is that I cannot get anything at all from the unit through GPIB. Everything even the bare-bones built-in GPIB CLR function times out with no response from the instrument no matter how long I set the timeout limit and it also freezes the entire GPIB bus as well. It isn't a waiting issue as it freezes on the very first command. The GPIB initialization function seems to work (I typically find this to be unnecessary), but the instrument itself doesn't even respond with a status code. I've also tried just the basic GPIB write functions with even just passing the <cr> and <lf> characters as well. In Measurement and Automation Explorer most of the time the instrument won't even appear when doing search for instruments and when it does it shows as not responding to the *IDN? command (yes I've messed with the EOI, EOS, etc settings and I've even changed the GPIB address even though when it gets this far it confirms that I have the correct address) and even tried manually doing the *IDN?, *RST, and *CLR commands even with <cr> and <lf> characters which the manual for these units clearly states are compatible commands and NI SPY and everything show no response at all. I've tried 2 different GPIB units, 3 different computers including several that are not online and haven't been updated for a while, and using older LabVIEW versions, extensive re-booting and resetting of computers and devices and still nothing. I'm using an NI GPIB-USB-HS GPIB to USB adaptor which I've used extensively on other systems and even re-connected to those systems and everything worked fine. When I hooked up equipment that I knew was working, it would either freeze the entire GPIB bus until well past whatever timeout setting I set at which point all the instruments would appear, but none responding to *IDN? queries or nothing would appear at all, or if I manually turned it off when frozen the other instruments would work and most even respond to the *IDN? queries. The same goes for both of the GPIB instruments of this type that I tried and again for different versions of LabVIEW, difference computers (all Windows XP though), and every GPIB configuration setting I can find to mess with in every combination.
Any thoughts or suggestions would be greatly appreciated. I've had all sorts of weird problems with equipment and LabVIEW (you've got to love undocumented design features) that have frustrated me before, but I've never had an instrument never respond at all especially a GPIB one. Getting garbage yes, no response at all, no.
The side side issues I'm just mentioning as they may be related, but I'm really interested in the above as I have working solutions for these:
One I've had is with a Hart Scientific (prior to being bought by Fluke) 1560 Black Stack that would continually stop responding to GPIB commands when on a continual read function taking readings just every 4 seconds with 250ms between each GPIB read or write command but for up to hours in total and the times it stops responding are random as far as I can tell. I even started sending the *RST command before and after every read or write command and still it freezes. The only thing is to manually turn it off and then back on or manually go through the menus and manually trigger the GPIB reset routine at which point it immediately starts responding. However, when I got sick of having to babysit it and just decided to try the RS232 serial port (as that is all it has without the extended communications module) it works fine no problem and I can even get readings slightly faster from it. Using a Hart Scientific 1529 Chub-e it could give me data on all 4 channels every second without problems. I just find it a bit odd.
When I couldn't get any of the HP 3458A driver packs to work to even give a single measurement reading and just made my own using basic GPIB read/write commands using the programming manual I still have a few interesting problems in randomly when reading off the full possible 256 bytes on the bus and clearing the bus I often find garbage partial readings on the bus every now and then. I've added a few routines to do some basic checks, but it is annoying. What is really weird is when just doing basic DC Voltage reads the "-" sign will randomly be dropped from some readings (started as about 1 out of every 5, down now to about 1 out of every 10). Fortunately I'm taking several readings and averaging and taking the standard deviation with limits on the deviations and basically added a routine to say if there is even 1 negative number take the absolute value of all then make all negative, but again I find it weird.
Thanks.
-Leif
Leif King
Metrology Engineer
Oak Ridge Metrology Center

Greetings Leif,
I understand you have completed extensive troubleshooting techniques to pin-point the problem with the GPIB communication. To begin, I want to ask you a few questions to help me understand your set-up and the issue at hand.
1) Is the NI GPIB-USB-HS cable the one which cannot communicate with your instrument?
2) When using the GPIB-USB-HS, does the GPIB interface show up in MAX?
3) If yes, does the instrument appear in MAX after scanning for instruments (from what I understand in your issue, it does so in an intermittent manner..)?
4) What driver version of VISA do you have installed in your computer?
5) Are you able to communicate to the same instrument using another GPIB cable?
Thank you for trying out some of these steps again, but we want to make sure we rule out other aspects in the systems which might be affecting the GPIB communication.
As for your other issues, please post seperate threads for each so we can help you accordingly. Thanks!
Sincerely,
Aldo
Aldo A
Applications Engineer
National Instruments

AT-GPIB/TNT PnP and Sound Blaster 16 Clashing

Hi Group
The Story is:
I have had a AT-GPIB/TNT PnP on a old Pentium 75/Win 95 Machine doing some testing, and havn't had a problem with it.
I now wanted to install a Creative Sound Blaster (Vibra) 16, also PnP ISA, card for basic audio analysis measurements.
The problem is when the Sound Blaster card is installed the PnP BIOS doesn't recognise the GPIB card at all, even with PnP
disabled.
Has anybody seen this before?
Could it be that the PC can only handle 2 ISA PnP cards (there is also a PnP network card)?
Would I be better of with a PCI SB card.
Any help would be gratefull
Tim S

Tim,
I had similar struggles with a 1995 vintage Pentium. My ISA GPIB conflicted with PCI sound card and PCI network card. It
tooks me hours to hit upon a sequence of installing the cards, and manually locking in the resources, in order to get them all
working.
Some general suggestions: get back to a configuration that works, say without the sound card. Make note of the resources for
the network card and GPIB card. While your there, examine the other possibilities. You can select other GPIB resource
configurations and see what the I/O range, INT and DMA settings would be. For example, some GPIB resource configurations
don't use INT and DMA at all. Write all of this down.
Then install the sound card, without the GPIB. See what resources it wants, and explore what other configurations it might be
happy with. Sound cards are tricky, because they usually use a lot of resources because they have a lot of functions: wave,
midi, mixer, etc. Some also have "legacy drivers" that mimic the older DOS based sound cards, for backwards compatibility
with games. You may be able to install the sound card and then remove some of these "extra drivers."
With sound card working, and the network card working, reinstall the NI488 software. Then power down and install the GPIB
card. Reboot. You may get lucky and everything just works.
More likely, the GPIB will work and the sound card won't. Go check the GPIB card resources and you'll probably see that the
NI488 drivers snagged one or more of the INT or DMA channels that the sound card was using. Try a different GPIB
configuration, or manually edit the DMA and INT settings to NONE. Also check for I/O range conflicts. (Consult your written
list, because the conflicts won't show in Device Manger -- since the sound card's not working it's not using any resources!)
Hopefully, by telling Device Manager to NOT use Automatic Settings, you can get the GPIB working and still leave enough
resources available for the sound card. Which you will probably have to go back and reinstall, from scratch. Possibly a few
times before you get everything to fit.
How bad do you want that sound card ? :~)
Isn't (Microsoft) plug and play wonderful?
p.s. you might also consider using CMOS setup to disable any motherboard resources you are not using, for example a COM port
that's not connected to anything. Remember to write down EVERYTHING, you do so you can put it back if you have to.
Good luck!
Best Regards,
Mike T
Mike Tranchemontagne
Consulting Applications Engineer
TeraComm, Inc.
148 Main Street
Building A, 3rd Floor
North Andover, MA 01845
877-900-TERA (8372)
978-557-9490 (FAX)
603-598-4773 (Direct Line and Cell)
Timothy John Streeter wrote:
> Hi Group
>
> The Story is:
> I have had a AT-GPIB/TNT PnP on a old Pentium 75/Win 95 Machine doing some testing, and havn't had a problem with it.
> I now wanted to install a Creative Sound Blaster (Vibra) 16, also PnP ISA, card for basic audio analysis measurements.
> The problem is when the Sound Blaster card is installed the PnP BIOS doesn't recognise the GPIB card at all, even with PnP
> disabled.
>
> Has anybody seen this before?
> Could it be that the PC can only handle 2 ISA PnP cards (there is also a PnP network card)?
> Would I be better of with a PCI SB card.
>
> Any help would be gratefull
>
> Tim S
Attachments:
miket.vcf ‏1 KB

Can anyone help me with Labview/GPIB timing problems?

I am trying to use a very simple VI (downloaded from the NI site) to control a Newport 1830C optical power meter.
I have been spending most of my time trying to use the VI issue a command to read the current displayed power. When I run the VI normally, I get no response from the meter, and the VI simply terminates without any error message. (The "remote" indicator does light on the meter, though, so it seems to be receieving the command.)
However, when I run the VI in the "highlight exectution" mode, everything seems to work just fine, and I receive a correct reading from the meter! Needles to say, this makes it really hard to debug the problem.
My guess is that I have some kind of timing problem, and t
he "highlight execution" feature fixes it by introducing delays. Is this correct? If so, how can I achieve the same thing by putting in delays by hand?
thanks, Whitney White

Whitney,
I agree that this is very likely to be a timing issue. VIs run much slower in highlight execution mode, therefore your instrument may need more time to prepare the data you have requested. Try wiring a delay inline prior to the GPIB reads and/or writes, or try using Service Requests (SRQs) to give the instrument enough time to generate the data it needs to send back to the computer.
Another possibility is that your instrument may not be IEEE 488 compliant. Some older instruments indicate that they are ready to receive data before they really are. Try changing the GPIB bus timing to the slowest setting (in the GPIB Configuration Utility). This only affects the time that the GPIB controller waits before valid data is on the bus and the DAV line i
s asserted (a step in the GPIB handshaking that occurs each time a byte of information is sent to the device) so this may not be effective.
Lastly, you may wish to try the instrument driver for your instrument. There is a contributed driver at this location: LabVIEW Traditional Instrument Driver: Newport Optical Power Meter 1830C. A 'contributed driver' means that someone outside of National Instruments wrote the driver and then submitted it for posting. This driver also contains a good example of adding a time out.
Regards,
Heather S.
Applications Engineer
National Instruments

After upgrade to win2K, my AT-GPIB/TNT(pnp) fails 3rd test in Getting

Started Wizard Hi,
I upgraded my PC to win2k from win98, and loaded GPIB drivers ver. 1.70.
After that my GPIB board fails to pass the "GPIB Interfaces Sequentially
Verified" test in Getting Started Wizard|Verify your hardware and
software installation. I saw an exact same problem posted here earlier
by somebody, but the proposed solution was to see if it was still
possible to communicate with instruments in IBIC, and it's not.
My board shows up in the device manager, and doesn't report any
problems.
I played with GPIB configuration and tried to uninstall and reinstall
the board a few times, nothing solved the problem. What else should I try?
My system: Win2kProfessional (with service pack 3
), P3-560MHz, 384MB
memory, AT-GPIB/TNT(pnp) board, driver ver. 1.70
Thanks
Yuri

Started Wizard Hi,
I upgraded my PC to win2k from win98, and loaded GPIB drivers ver. 1.70.
After that my GPIB board fails to pass the "GPIB Interfaces Sequentially
Verified" test in Getting Started Wizard|Verify your hardware and
software installation. I saw an exact same problem posted here earlier
by somebody, but the proposed solution was to see if it was still
possible to communicate with instruments in IBIC, and it's not.
My board shows up in the device manager, and doesn't report any
problems.
I played with GPIB configuration and tried to uninstall and reinstall
the board a few times, nothing solved the problem. What else should I try?
My system: Win2kProfessional (with service pack 3
), P3-560MHz, 384MB
memory, AT-GPIB/TNT(pnp) board, driver ver. 1.70
Thanks
Yuri

Compatibility of Agilent GPIB/USB adapter with NI

Hi,
I have an Agilent GPIB / USB adapter 82357B, and I'm experiencing some problems for detecting my instruments in the laboratory when I try to use the labview software for capturing the data from the measurement instruments.
I installed the CD with the libraries the adapter has and through this software I can detect the instruments, however once that I open the Labview software from National instruments(NI) for capturing my data, I miss comunication with the devices in both programs, the Agilent one and in the MAX of NI.
I run across a document regarding tip on using Agilent GPIB solutions in National instruments's Labview environment. I have done all the document indicates, but It is not workingt, I experience the problem I outlined above for detecting the instruments.
I hope someone can help me with that.
Regards

DCU STUDENT wrote:
Yes I am. According to documents it is possible. But I don't know want else to do, since I have done what document indicated. I as mentioned in previous message, now I can see the measurement instrument with Labview and using the Agilent cable adapter, and I can stablish communication with device since that when I select the device in the labview program, a led in the instrument is ON, indicating communication. However when I try to capture the data on screen, there is not data at all.
Hello DCU STUDENT,
It sounds like there may be some conflict between the NI VISA and Agilent drivers, which can occur between certain models; considering when you use the NI cable data can be collected when when you're using the Agilent you cannot. Please tell me what versions of both drivers you are using so I can determine whether or not there are any known incompatibilities between the two if you're still receiving the same error after following these instructions.
Can you also please go through this instrument troubleshooting guide to see if your installation matches the expected configuration of a functional device so we can confirm that your driver has been installed correctly from the previous guides.
For a IEEE488 Agilent Device Card, as you mentioned that you have the NIVISATulip.dll enabled, for this GPIB configuration to work you must ensure that the 488 Programs must be activated with NI 488.2 (At the Enable Agilent GPIB cards option) through the Agilent Connection Expert.
You've mentioned that you've been able to establish a connection with the device and see communication transfer, yet you are getting no returned communication. Do you see a similar response when you view the device through the Measurement and Automation Explorer?
If it is possible, could you test your configuration with any other Agilent devices with your current configuration and see if the error persists?
Alex Thomas, University of Manchester School of EEE LabVIEW Ambassador (CLAD)

Raw GPIB and VISA commands

Hi,
i have a software, written by an external company in labview 6, to
control several devices. But I dont have the block diagrams. This
software use VISA calls to communicate with a profile 800 mainframe.
Now I want to set an parameter of the mainframe via GPIB raw command.
I can integrate my own VIs in our software.
So I have written my VIs to send and read an GPIB-string (with GPIB
write and GPIB read) and within Labview all is running fine.
But if I use this VIs within our software, I get an GPIB-error 6. At
this time there is no other communication in background with this
device. But if I start Labview and communicate with my VIs once, then
my VIs work in our software too.
Do I have a problem with initialization?
What can I do to solve
my problem?
Regards,
Uwe Roessner

Hi Uwe,
It seems like it could be an initialization issue. Perhaps your VI does an initialization that the software doesn't do, but is necessary for your VI to run. I would definitely consider that. According to GPIB Error Codes document:
EABO (6)
Error Condition: I/O operation aborted.
Description: EABO indicates that an I/O operation has been cancelled for some reason.
Possible Cause: The EABO error is usually the result of a timeout during a read or a write operation, but it can also be caused by calling the ibstop function, the ibclr function, or similar functions while an I/O operation is in progress. You may receive a timeout during write operations with a PCI-GPIB board, if the PCI bus mastering (an option in the BIOS of your computer) is not enabled. You may receive a timeout during read operations, if the instrument you are reading from did not understand the previous command, so it has nothing to write to you. There are a few reasons why the instrument may not have anything to say:
The message to the instrument may have been misspelled. For example, "*IDN?" is a common identification query for IEEE 488.2 compliant instruments. It is easy to misspell this message as "*IND?", which the instrument will not understand, so it will not generate a message string for you to read from the instrument.
The message to the instrument may contain a command that the instrument does not understand. For example, the "*IDN?" message from the previous example is only understood by IEEE 488.2 compliant instruments. If your instrument is an older, non-IEEE 488.2 compliant device, then it will not understand "*IDN?", so it will not generate a message string for you to read from the instrument.
The instrument may use a particular EOS (end of string) character as its termination method, but you may forget to append this termination character to your message. For example, if your instrument expects a linefeed as the EOS character, then "ID?" will not work, but "ID?\n" (where \n represents a linefeed in IBIC) will.
You may expect to see EOI (end or identify, one of the five bus management lines) as the termination method, but if the instrument does not set the EOI line when it finishes sending its message, any read operation that you perform will time out.
Solutions:
Make sure that your messages consist of commands that the instrument understands. Check your device's user manual for a list of possible commands.
Verify that you are using the correct termination method for your instrument. Byte count (where you expect to receive a certain number of bytes in a message) is always used, but some instruments use EOS and byte count, some use EOI and byte count, and some use only byte count. Check your device's user manual for the possible termination methods to use with your instrument.
If EOS is the termination method, then be sure to append the termination character to the end of your message. You can specify the termination character in the GPIB Configuration Utility, but the NI-488.2 driver will not automatically append it for you!
Lengthen the timeout period for I/O operations using the ibtmo command.
If you receive all of the data and get an EABO error, then look for a particular end of string character (e.g., linefeed or carriage return) and configure the GPIB board to terminate the read on that character using the ibeos function.
Hope this helps.
Anu Saha
Applications Engineer
National Instruments
Anu Saha
Academic Product Marketing Engineer
National Instruments

Problems installing PXI-GPIB

Hi,
I had already installed the PXI-GPIB board in my PC (cPCI with NT4.0)
and it worked fine. I removed it from the system and put it in again
some time later.
But now it is not working. Even removing all drivers and reinstalling
did not make it work. When configuring the board I always get the
message: "Changes to NI488.2 software could not be saved". What is the
problem?
Thanks,
Andreas

Andreas,
Try this:
1. Go to GPIB under Control panel
2. Select GPIB interfaes one by one (i.e, GPIB0, GPIB1 etc) and then select board type as 'None'
3. Then close the GPIB configuration and reboot the machine
4. Go to GPIB under Control panel again and pick PCI-GPIB from the list. Exit again and it should be able to save the changes.
Nasir

Fixing a GPIB ESTB 15 error with LabVIEW 6

I am using LabVIEW to make vi's that control a compumotor 2100 indexer. One of the steps is to do a wait for SRQ then a serial poll. The serial poll keeps on giving me a GPIB 15 error. The NI database said to disable autopolling, but I don't know how to do that in LabVIEW 6. Any ideas or help on how to fix the error, or disable autopolling are gladly appreciated.

Autopolling can be enabled or disabled though the use of the GPIB Configuration utility (IBCONF) or
dynamically through the use of the ibconfig functions. If you are using GPIB vi's then you can probably use the MISC.vi, but I have not tested this.
The link below talks about disabling autopolling.
http://ae.natinst.com/operations/ae/public.nsf/fca7838c4500dc10862567a100753500/9c25d443b106b30f862562870079afe8?OpenDocument
Kim L.
Applications Engineer
National Instruments

CVI aborts with no warning when compiling

When I compile a simple instrument driver with the CTRL-K shortcut in CVI 2009 (9.1) it aborts CVI without warning
No popup, no nothing.
All I had done was delete a typedef in the driver file for a structure containing GPIB configuration info.
After it did it about 5 times in a row it finally stopped when I included a header file that re-established the typedef for the GPIB struct.
So the problem was that this typdef appeared as a parameter type in a prototype in another header file, and when I eliminated the definition it caused the abort. The abort was immediate, I have to think it was something wrong in the preprocessor. I do not have precompiled headers checked in the build options. I am using the standard CVI compiler.
Weird, huh.
Menchar

Some how I knew you'd ask for that
I don't have a simple case.
It was absolutley repeatable, I couldn't believe it when it first happened.
I had something like this in the driver file:
typedef struct _GPIBConfig {
DWORDBus;
} GPIBCONFIG, * LPGPIBCONFIG;
and in a header file I had a prototype that used the typedef as a parameter type:
headerfile.h
INT myFunc (GPIBCONFIG config);
When I eliminated the typedef from the driver file, I got the crash.
When I added another header that defined the GPIBCONFIG struct, the crashes stopped.
Restarting CVI did not cure the problem. When I restarted, CVI did a popup saying the previous instance of CVI had been stopped abnormally. I recovered the project per the popup. Then when I restarted and recompiled, it crashed again, but when I restarted I didn't get the popup.
Menchar

NI-488.2 no instruments found

Using PCI-GPIB card with NI-488.2 version 1.6 (or 1.7) and Windows NT 4.0:
- If a GPIB instrument is at GPIB address 1 on PCI-GPIB configured as GPIB1, this instrument is not found using N.I. "Scan for instruments" utility. If I change this GPIB instrument address to 0 or anyone from 2 to 31, the utility can find the instrument.
- Same observation if I connect a GPIB instrument at address 0 on GPIB0, or at address 2 on GPIB2, etc.
Is the PCI-GPIB card number used to configure it is then no more available for the address number of any instrument connected to this bus?
Thanks.

The problem is an address conflict. To answer your question at the end, yes, if the GPIB board has a particular address, it is not available for any instrument connected to the controller. All controllers/devices must have a unique address.
I don't remember how the NT configuration utility worked. It is possible that the GPIB configuration utility automatically configures GPIB1 for PAD1 and GPIB2 for PAD2, etc. In general, you should always configure your GPIB controller to be at primary address 0 and have your instrument(s) be configured for an address in the range 1-30.
The GPIB configuration utility lets you choose the GPIB number AND the GPIB primary address separately. Therefore, if you GPIB controller is GPIB1, go into the configuration utili
ty and configure it be at PAD0. Then everything should work.

Some component with an unsupported version is trying to use NI Spy

This problem is intermittent. In GPIB Configuration, Network settings, when I select the IP address of GPIB ENET/100, I get this NI Spy message: Some component with an unsupported version is trying to use NI Spy. Please contact National Instruments for an update. Do I need to update the firmware of GPIB/ENET100? The current version is B.9.

Hello,
Try uninstalling 488.2 driver, then uninstall MAX and then reinstall the 2.1 version for 488.2 from CurrentGPIB driver versions. Also make sure you are the administrator while you uninstall and reinstall.
I have not seen this problem happen before so I hope uninstalling and reinstalling helps solve this problem.
Please feel free to email me back incase you have further questions.
Good luck and have a great day!
Koninika
National Instruments

Why can I read from my instruments in LabView only when NI Spy is open?

This is a recurring problem, but I hope someone has an idea of what may be causing it. I have two older (c. 1992) instruments that we use for simple measurements. One is a Newport PMC-400 actuator driver/motion controller, the other is a EG&G/Princeton Applied Research 5302 lock-in amplifier. I am using Labview 6i with a PCI-GPIB card.
The instruments themselves work fine, and seem to run somewhat reliably if NI-Spy is open. However, if we close NI-Spy, the GPIB seems to "lock up" and time out, requiring resets of all the instruments. This seems to be something related to either command termination or timing.
Any thoughts/hints/solutions would be greatly appreciated.

Hi JFoley,
The reason this happens is usually related to the instrument! Certain older instruments communicate with the GPIB board in such a way that they indicate that they are able to receive data before they really are. This was a nice trick back in the day when computers were slower, and it could get away with �lying� about its state as it would make the instrument look faster than it was! With the faster computers of today it throws off the bus timing and can cause problems.
You may be able to resolve the timing problems, either by introducing delays between GPIB commands, or by changing the GPIB bus timing to the slowest setting (in the GPIB Configuration Utility). The first option is usually successful, but the second option is less effective becau
se it only affects the time that the GPIB controller waits before valid data is on the bus and the DAV line is asserted (a step in the GPIB handshaking that occurs each time a byte of information is sent to the device).
Hope this helps out!
Best Regards,
Aaron K.
Application Engineer
National Instruments

EABO on under linux 2.4

I am using nigpib-linux-0.8.2.tar.gz driver with AT-GPIB/TNT under linux 2.4.3. Get consistently EABO errors on ibwrt, ibrd, ibclr and other commands both in C programs and in ibic interactive operation. Tried all the combinations of enabling/disabling DMA, changing EOS character, enabling and disabling EOI assert etc.
Any ideas what else might be wrong?

Hello:
There is a website that lists common GPIB error codes and solutions. You may check there for some things to try. You'll find the link at ni.com > Support > Troubleshooting > Installation/Getting Started > GPIB, titled "GPIB Error Codes and Common Solutions"
Here are a couple of suggestions from that page.
-Make sure that your messages consist of commands that the instrument understands. Check your device's user manual for a list of possible commands.
-Verify that you are using the correct termination method for your instrument. Byte count (where you expect to receive a certain number of bytes in a message) is always used, but some instruments use EOS and byte count, some use EOI and byte count, and some use only byte count. Check your device's u
ser manual for the possible termination methods to use with your instrument.
-If EOS is the termination method, then be sure to append the termination character to the end of your message. You can specify the termination character in the GPIB Configuration Utility, but the NI-488.2 driver will not automatically append it for you!
-Lengthen the timeout period for I/O operations using the ibtmo command.
-If you receive all of the data and get an EABO error, then look for a particular end of string character (e.g., linefeed or carriage return) and configure the GPIB board to terminate the read on that character using the ibeos function.
Hope this helps.
Pavan B.

GPIB Configuration

Similar Messages

Maybe you are looking for