GPIB erreur communication

Bonjour,
J'ai un problème d'exécution d'un vi bloqué sur un sous vi permettant l'initialisation d'un gaussmètre DG6 par une carte AT-GPIB/TNT branchée sur un port isa (avant de procéder à des mesures avec une sonde fixée sur une table 3 axes)
Le sous vi isolé et exécuté renvoit:
GPIB write returned error code
EDVR= Error connecting to driver or device
Seulement, le périphérique est reconnu par Win 98 (en l'installant manuellement), et apparait à l'exécution de MAX (la recherche Scan for Instruments renvoit quelque chose et non instruments not found)
J'ai donc Win 98 avec Labview 6.1 et NI 488-2.
Les programmes fonctionnaient sous Win 95 avec labview 6.1 avant de faire le transfert.
Quelle pistes pour voir d'où vient cette erreur de communication?
J'envoie le sous vi pour l'initialisation du gaussmètre.
Attachments:
sequence init Gauss1.vi ‏28 KB

Bonjour,
Dans un premier temps est-ce que votre instrument renvoie son identifiant lorsque vous lui envoyez la commande "*idn?" à partir du "GPIB Communicator" dans MAX?
Ensuite, votre instrument répond-t-il de même si vous envoyez cette commande à partir de votre VI?
Si la réponse est oui, il y a peut-être une erreur dans la syntaxe des commandes que vous envoyez à votre instrument.
Cordialement,

Similar Messages

GPIB, Serial Communication.

Does JAVA support GPIB or Serial Communication?

check this out for a Java wrapper for GPIB Comms
http://cs.ulb.ac.be/projects/jpib
Regards Flacky

GPIB-VXI communication protocol

Hi:
I met a problem when i set up communication with GPIB-VXI machine. i don't konw which protocol it use when the computer talk to
VXI machine. And I know they connect each other with GPIB. But i wonder which protocol? And is it the same as one in the condition
that computer directly talk to instrucment with GPIB. Thanks very much if some one tell me!

Xiaoyiyi wrote: I think it is clear this time! Thanks!
Nope. You added absolutely no new information. Again, what is the instrument (make and model)? Do you have the manual?
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Will it be any different if I call GPIB function instead of VISA to write to the device?

Hi all,
I am still using LV7. I have a function generator using GPIB interface. In the labview code, I use VISA write to send commands to the function generator. But I am reading some related documents about GPIB in labview. I wonder what's the advantage of using VISA instead of GPIB for communication, also the interface is actually GPIB so what's VISA really doing in this case? Thanks.
Solved!
Go to Solution.

VISA by itself does not provide instrumentation programming capability. VISA is a high-level API that calls into lower level drivers. The hierarchy of NI-VISA is shown in the figure below:
Advantages of VISA:
1. One of VISA’s advantages is that it uses many of the same operations to communicate with instruments regardless of the interface type.
2. Another advantage of VISA is that it is an object-oriented language which will easily adapt to new instrumentation interfaces as they are developed in the future.
Reference:
http://www.ni.com/support/visa/vintro.pdf
I am not allergic to Kudos, in fact I love Kudos.
Make your LabVIEW experience more CONVENIENT.

Using LabVIEW for temperature control with AMREL SPS200-50-A022 power supply

Hi, I hope someone can help me out. I'm an ME undergrad with pretty much no knowledge of LabVIEW. I am working a project which requires a temperature controller. Previously, we were using an SPS120-10 power supply from AMREL and a grad student wrote a LabVIEW VI which performed feedback temperature control. The VI would acquire temperature from a Benchlink which acquire the temperature from a thermocouple. The VI also monitor the output voltage & current and determine the power output and heater resistance from those values. When a desired temperature is set, the VI compares the actual temperature to the set temperature and adjust the voltage/current setting to achieve the desired temperature. The VI was designed to keep temperature deviation to within +/-0.5 deg C. I'm not sure of the data refresh rate, but it's on the order of seconds since the system has a small thermal mass and we're operating in the 800+ deg C range. When we were using the SPS120-10, the device used GPIB for communication with the PC. Due to higher power output demand for the heater, we switched to an SPS200-50, which only has an RS-232 port. First of all, I was wondering if someone could help me modify the VI so that it could communicate with the SPS200-50 through the serial port? In addition, the drivers for the SPS120-10 and SPS200-50 might be different. If modifying the VI to communicate through the serial port isn't enough, I would need to figure out where to modify the VI with the SPS200-50 drivers, which is provided by AMREL. If anyone would like, I can send you the VI files so that you can take a look at the block diagram and tell me where to modify it. I'm still not 100% certain I understand how to read LabVIEW block diagrams.
Please let me know if you need any additional information. Any help would be appreciated. Thanks in advance!

I have looked over your vi. First of all you have to do some changes in the "ARSPS Initialize.vi" See picture.
The best way to check instrument communication is to send the *IDN? Command. The instrument will indentify itself in response to this command. The vi I have included is a labview example. Use this Vi to test your communication. Do not progress before this is working. The VI is also an excellent example on how to set up and close down RS232 communication.
The VI "Tfeedbackpowercontroller-nolvdt-Dinh.vi" looks OK so I guess it will work then your RS232 communication with the SPS200-50-A022 is working
good luck
PS as mentioned before you will find all the RS232 details in the instrument manual
Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)
Attachments:
sample.PNG ‏38 KB
Basic Serial Write and Read.vi ‏29 KB

HP35670A data capture

Hello,
Attached is some labview code that I wrote for the HP35670A. However, for some reason, I get the error (HEX 0xBFFF0015) Timeout expired before operation completed (please see "error" attachement) whenever I try to capture the data from the screen.
Can you assist me in capturing the data correctly?
Please note that the code requires the Agilent 35670A drivers.
Thanks,
hiNi
Attachments:
error.png ‏8 KB
microphonics setup_3.vi ‏80 KB
labview code.png ‏18 KB

Hello hiNI,
Taking a look at your code, I am going to assume that you are using GPIB for communication to your instrument, if this is incorrect please let me know what you are using to communicate. With this being said, we have a great KnowledgeBase that I would like for you to take a look at called Error -1073807339 When Using VISA Read or VISA Write in a Serial VI
Although this is for serial communication, the principles are very similar. The idea is that communication to your device is going smoothly, but the communication back is taking longer than expected and it would be best to up the timeout to allow for all communication to finish. Try running your VI in Highlight Execution and see if it timesout. If it does not, then you simply need to up your timeout! Thanks again and let me know if this helps.
Regards,
Nicholas K
National Instruments
Applications Engineer

Problème communication GPIB avec HP8753B

Bonjour tout le monde,
je vous écris car je n'arrive pas à résoudre un problème de communication avec un analyseur de réseau HP 8753B (très vieux), j'ai fait un programme sous labview qui marchait parfaitement, puis quelques jours sans utilisation maintenant je ne peux plus dialoguer avec lui, je n'ai a priori rien modifié.
Au démarrage de l'ordi je peux communiquer avec lui grâce à MAX mais pas avec mon programme, il y a une erreur lorsque j'utilise le vi de gpib write (code erreur 3). Lorsque je retourne sur MAX il me dit erreur iberr=EADR, cette erreur explique que mon instrument a la même adresse gpib que le controleur mais j'ai vérifié et ce n'est pas le cas, j'ai modifié l'adresse gpib de mon instrument mais cela donne la même chose, les même erreurs. J'ai pourtant éplucher le manuel du HP sans trouver de solution, l'instrument est en mode "listen" mais pas "talk".
Est-ce que quelqu'un aurait déjà rencontré un problème similaire, même avec un autre instrument?
Cordialement
Mélanie

Bonjour,
Merci d’avoir posté votre question sur les forums de National Instruments.
L’erreur que vous reportez correspond effectivement à un problème d’adressage entre votre contrôleur GPIB et votre instrument. Sur le document suivant, GPIB Error Codes and Common Solutions (Part 1), il est clairement indiqué que cette erreur peut survenir si votre contrôleur GPIB à la même adresse que vos instruments. Je pense qu’en plus de vérifier l’adresse de votre instrument, vous devriez aussi vérifier si votre contrôleur GPIB n’a pas une adresse fantaisiste. Le plus simple est de lui donner l’adresse 0. Vous pouvez également vérifier les adresses secondaires de vos instruments et contrôleur afin de vous assurer que ce ne sont pas elles qui causent problème.
D’ailleurs quel contrôleur GPIB utilisez-vous ?
Avez-vous vérifié que les paramètres d’adressage que vous utilisez dans votre programme LabVIEW sont bien les mêmes que ceux que vous utilisez dans MAX ?
Enfin, savez-vous si votre appareil GPIB est bien prêt à entrer en communication avec le contrôleur GPIB ? Je veux dire par là que votre instrument est peut être bloqué en mode remote ou local et qu’il n’arrive pas à basculer dans l’autre mode. Cela pourrait empêcher la communication de s’établir. Il faudrait dans ce cas vérifier si vous n’avez pas sur votre instrument un bouton permettant de passer manuellement d’un mode à l’autre.
J’espère que ces informations vous aideront à résoudre votre problème.
Bien cordialement,
Guillaume H.
National Instruments France
#adMrkt{text-align: center;font-size:11px; font-weight: bold;} #adMrkt a {text-decoration: none;} #adMrkt a:hover{font-size: 9px;} #adMrkt a span{display: none;} #adMrkt a:hover span{display: block;}
>> NIDays 2011, le mardi 8 février au CNIT de Paris La Défense

VISA erreur 1073676294, Probleme d'adaptateur USB/GPIB

Bonjour à tous
Je communique avec un oscillo tektronix grace à une liaison GPIB. N'ayant pas de carte GPIB sur mon ordinateur, j'utilise un adapteur qui convertit la liaison en GPIB en USB pour le brancher à l'ordi. Or lorsque je teste de communiquer en VISA (sous Labview 8.5) vers l'oscillo (test IDN), il se produit une fois sur 2 une erreur 1073676294 dans VISA Read.... J'ai par ailleurs testé avec une carte GPIB sur un autre ordinateur, il n'y a pas d'erreur dans le Read (testé sous Labview 5...).
Connaitreriez vous la cause de disfonctionnement avec l'adaptateur GPIB/USB ? et comment résoudre le probleme ?
merci d'avance
Résolu !
Accéder à la solution.

Bonjour Charles38,
Il s'agit d'un rapport de statut et non d'une erreur :
http://digital.ni.com/public.nsf/allkb/C96C84C922DC3F978625632500482F78
En fait cette "erreur" indique que le nombre d'octets lu correspond parfaitement au nombre demandé, et que d'autre données pourraient être disponibles. D'ailleurs l'indicateur d'erreur ne devient pas actif lors du passage de ce code d'erreur.
EDIT
J'ajoute que vous pouvez ignorer cette erreur de la sorte:
http://digital.ni.com/public.nsf/websearch/BF72229C53F7633386256EDD0069331B?OpenDocument
Cordialement,
Message Edité par Alex_NI le 04-20-2010 04:49 AM
Alexandre D.
National Instruments France
#adMrkt{text-align: center;font-size:11px; font-weight: bold;} #adMrkt a {text-decoration: none;} #adMrkt a:hover{font-size: 9px;} #adMrkt a span{display: none;} #adMrkt a:hover span{display: block;}
>> Les présentations NIDays 2010 déjà disponibles au téléchargement !

Communication GPIB avec un keithley 2000

Bonjour à tous,
j'essai d'utiliser mon multimètre keithley 2000 en communication GPIB sur mon labview 8.6. J'ai télécharger un vi (pièce jointe) qui est un exemple. J'arrive à initialiser sans pb... mon pb se situe au niveau de la fonction lecture. Le sous vi atteint le time out de 25s et me renvoie l'erreur suivante :
L'erreur -1073807339 s'est produite à : VISA Wait On Event dans Wait for RQS.VI:1->_ke2000 Wait for SRQ.vi->ke2000 Data Read Single.vi->Keithley channel test.vi
Raisons possibles :
VISA: (Hex 0xBFFF0015) Le délai d'attente (timeout) a expiré avant que l'opération ne soit achevée.
Je ne comprends pas du tout ce qui se passe, quelqu'un aurait-il une idée !!! Merci à tous
Attachments:
Keithley channel test.vi ‏48 KB

duplicate post

GPIB Communication between multiple devices

Hello,
I am trying to build an application in C# which will be able to send commands to more than one device on the GPIB BUS.
For example I have 3 devices connected to the computer with addresses as:"GPIB0::18::INSTR","GPIB0::19::INSTR","GPIB0::28::INSTR"
Now, I know how to communicate with a single device.
But is there a way I can send commands to multiple devices. So far I have the following.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using Ivi.Visa.Interop;
namespace Step_Attenuator
public partial class Form1 : Form
ResourceManager rMgr = new ResourceManager();
Ivi.Visa.Interop.FormattedIO488 ioobj = new FormattedIO488();
object resources = null;
string address1 = "GPIB0::18::INSTR";
string address2 = "GPIB0::19::INSTR";
string address3 = "GPIB0::28::INSTR";
public Form1()
InitializeComponent();
private void PsaComm()
private void Form1_Load(object sender, EventArgs e)
private void button1_Click(object sender, EventArgs e)
ioobj.IO = (IMessage)rMgr.Open(address1);
ioobj.WriteString("*RST");
But now If I want to send a RST command to say device on address2, do I have to again open the session and send it?
There are going to be a lot of commands to these devices. I am sure there is a much simpler way to do it.
Please pardon me if this seems to be a silly question.
Thank You.

Hi nmedelec,
I made a research about “Ivi.Visa.Interop.FormattedIO488” and it seems that it is related with Ivi.Visa.Interop which is a third party product. If you have any issue about a third party, I would recommend you go to the office site for help.
Thanks for your understanding.
Best Regards,
Edward
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click HERE to participate the survey.

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

GPIB error in the instrument while no communication error

I am developing a test system by connecting several measurement instruments through GPIB with LabVIEW 6.i. The driver is written by using VISA command. GPIB control card is NI PCMCIA. When using laptop everything runs fine. When using an old PC with something like EISA to PCI converting card for slotting in the NI PCMCIA card. One instrument always displays an GPIB error. The error is instrument specific, no further detail is given by the manual. When the error comes out, no GPIB or VISA error exists. If only the driver for this instrument is installed so that the software only communicates with this particular instrument, no error. With other driver installed, there is no error in the first or two commnunication
. Later on the error is surely out and display in the instrument screen only. Once again, no any other GPIB or VISA communication error. Anybody can help on this ? Thanks a lot.

Hi JLS,
First of all, thank you very much for your prompt response. I am not sure some of your questions because our hardware engineer is away for a week. I am trying to explain what I know and see whether you could help to figure out the reason.
0. The operation system in the old PC is Win98. The CPU is PII 350MHz, 32G Hard disk and 320M RAM. The reason why we are using the old PC is that we have a 3rd party motion controller. Its control card is a ISA card.
1. The conversion device is a kind of card, put in the ISA slot in the PC extention I/O bus. We can slot in 2 PCMCIA cards in the conversion device. The driver for the NI PCMCIA card is supposed to be the same with that in laptop.
2. The driver that works with the instrument is developed by me by using NI-VISA. The instrument is a signal generator (SG) from Marconi instruments. Basically what the driver does is to turn on or turn off SG and read back its on-off status. When turning on SG, send setting frequency and signal level data as well. The calling of the driver is in a loop where frequency is stepping up.
3. There are other measuring instruments. e.g. electric field monitor probe to get the electric field strength etc. All these instruments' driver are developed by me by using NI-VISA. I also develop a set of dummy driver for all the instrument for demo purpose. Dummy drive did not communicate with instrument, inside, control is directly wired to status. When all other instruments except SG uses dummy driver, The running is OK. No error is displayed in the SG screen. If I use any of the other instrument's driver with that of SG, there is no problem at the first run (that means at the beginning of the loop), problem surely comes out later on. But it is OK when running in the laptop of which the OS is Win2000. The funny thing is if I takes out the status readback in SG driver, there will be no error at all even running with other instruments' driver in the old PC. I have compare through the GPIB card setting in the old PC and laptop, make sure that the EOI setting, primary address, EOS etc. to be the same in the two computer. It does not work.
4 & 5. The error displayed in the instrument screen is Error#403 "Data Expected". The manual said it is caused by the GPIB programming wrongly. No further explaination on how it may happen. Even there is such error display, no any GPIB or VISA error happens in my driver, the error cluster is clear. I debug the problem and find that the SG error appears when executing VISA resource open. I have also checked through all the NI GPIB help. It seems I could not find the answer.
6. I am not sure how to check the version of NI-488.2 and NI-VISA. NI-VISA is installed with the LabVIEW 6.i together.
Best Regards
Jason

Keithley 238 GPIB Communication

I am using LabView 6.1 and writing an application that communicates to this instrument (among others) via GPIB. My communication to the Keithley is usually okay for a while in the beginning, but after the program has ran for about 5-10 minutes, it loses communication with it. The Keithley drivers I am using just timeout and it looks like there is not really a specific error code except for ERR(0). Has anyone had issues communicating with this or a similar instrument, and how was it resolved?
I did see someone post that it may be a good idea to modify the Keithley drivers to use VISA instead of the older GPIB communication vi's.
Any help would be greatly appreciated.
Thanks in advance.
Rey

A.S. Thank you for your reply. I used the Keithley 238 Device Errors VI to try and get more info., but it still returned the same thing. I had looked at EDVR(0), but I couldn't find any place where the name could have been changed. Although, I am using an Event loop, so I will double check and make sure this does not reset a value that I set somewhere else.
Here is an interesting thing that I did. There is a part in my program where I am just reading a measurement from the Keithley 238 on a continual basis, and this where it seemed to usually crash after a few minutes. So I opened up the Keithley VIs (namely the Read Measurement one) and ran it in LabView debug mode (slow motion). The funny thing was that when I did this, I had no problem. It ran fo
r 45 minutes in this mode and never failed. I noticed in the Read Measurement VI that they do some writes/reads and even poll the intstrument once or twice in a while loop. So what I did was added some delays in a couple of different places of about 500ms. I also slowed down the polling in the while loops to like 250ms. Once I did this the program, so far, seems to work. I know all the delays (and the times) might be overkill, but it looks like it may be a step in the right direction. We are not looking for super fast response times, so if this did indeed fix the problem, it should be okay. So far for the last couple of days it seems to have worked. I will continue to monitor it, to see if it ever fails even with the delays.
Does any of this seem to make sense? The thing that I don't understand is that I am sure there are people that must have used these VIs from Keithley without any issues, so it seems weird that they would behave differently on my machine, as far as tim
ing. It is not a fast machine by todays standards (PXI 1000B, I think ~1GHz).
Thanks for you input,
Rey

Any one having the knowledge of communicating Agilent 81250A via GPIB

any one had done interface b/w Agilent 81250A via GPIB
I am working on Agilent 81520A
If anyone can provide me driver, it will be great help for me.
Anyone having some important document used for GPIB communication with Agilent 81250A please provide me.
thanks,
anurag

What do you have it connected to? Doesn't the optical head you are refering to require an actual instrument like the 8153?

Establishing communication with GPIB devices

I am a newbee to GPIB and a novice at VB (6.0). Have been unable to establish communication with devices from the VB .exe. I think I am not declaring something in the right place? Any suggestions?

TG,
What kind of trouble are you having reading data from the instruments? There's information that addresses some of the common issues about why communication with instruments might fail. For more information, please refer to:
Why Can't I Communicate with My GPIB Instrument?
A couple of useful tools that you can use to check out communication to the instrument before writing your Visual Basic app are NI-488.2 Communicator and
Interactive Control (IBIC)
If you are still having trouble after trying out some of the suggestions listed above, it would be helpful if you capture the ibwrt and ibrd calls using NI Spy, save the Spy capture, and then attach it to this forum. If you are unfamiliar with Spy, here's a link with information about how to use Spy:
NI Spy
Hope this information helps with getting data back from the instrument.

GPIB erreur communication

Similar Messages

Maybe you are looking for