GPIB instrument holding up bus

I am having an intermittent problem with my GPIB system. Occasionally and seemingly randomly, one of my instruments holds the GPIB hostage; no other instruments can use it. The controller is the Agilent GPIB card and is accessed using the NI Tulip Passport. The device is power cycled and the bus is released and normal communications proceed.
My hope and question is: Is there a programmatic way to steal control back from the device by sending for instance the interface clear? My thought is if the interface clear asserts a different line perhaps the instrument's GPIB function would re-initialize and release the hold it has on the bus.
Can anyone help me with this? I am going to try to replicate the problem, but I'd like to know if this is theoretically possible.
Thanks,
Nate
-Nate

Hi Nate,
I believe the following forum post will help you:
http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/how-do-i-tell-labview-to-release-a-GPIB-resou...
To summarize, it seems like you can with VISA. However, using functions from the 488.2 drivers aren't as straight forward. However, GPIB devices don't really have a "session". You've got various states, such as talker, listener. It is up to the controller to keep and set these states for the device.
Hope this helps.
Regards,
Che T.
Applications Engineer
National Instruments

Similar Messages

How do I create Labview VISA ports for *individual* GPIB instruments using Prologix USB GPIB controller?

Hello,
I'm trying to use a Prologix USB GPIB controller to control GPIB
instruments, and I would like to have a virtual serial (VISA) port for
*each instrument*, as is the case with a normal GPIB controller with a
standard NI driver. However this is not what the Prologix driver
provides -- it provides a single VISA virtual serial port for the
entire controller. To address the instrument with GPIB address 11,
you first send "++addr 11" to the serial port, and then you're talking
to instrument 11. However, this means I have to change all old
Labview programs.
Is it possible to create a "wrapper" function of some kind that will
define a virtual serial (VISA) port for each *instrument* on the
controller? For example, to talk to GPIB instrument 11, call it
ASRL3::11::INSTR, each time it is written to it would have to write to
the virtual serial port of the controller, say ASRL3::INSTR, first "+
+addr 11" and then the command that is sent to it.
A clearer explanation of the difference (i.e. incompatibility), and of
my objective:
1) A normal GPIB controller with NI driver: I go to the NI
Measurement & Instrumentation Panel, under GPIB, and Scan for
Instruments; all the live instruments show up; subsequently when I
want to use Labview programs that use VISA ports, the VISA drop boxes
allow me to choose a different port for each instrument, e.g.
"GPIB0::11::INSTR", "GPIB0::12::INSTR" would be instruments at
addresses GPIB 11 and GPIB 12.
2) The Prologix GPIB controller that plugs into a USB port: In
Labview you get a *single* VISA virtual serial port, ASRL3::INSTR, for
the entire GPIB0 controller. Therefore to address GPIB instrument 11,
you write "++addr 11" to the virtual serial port ASRL3::INSTR, and
then you are communicating with device 11, so you can write and read
ASRL3::INSTR to talk to that device. Then to talk to device GPIB 12,
you write "++addr 12" to the same VISA port, and then you are talking
to that device. The problem is that this requires recoding all
Labview code, whereas I would like to be able to use the same program
either with a normal or with a Prologix GPIB controller. Therefore, I
would like to create code that scans the controller for all GPIB
attached devices and creates VISA ports for all. Such ports, when
written to, would have to first write "++addr DEVICENUM" to
ASRL3::INSTR (i.e. the port of the GPIB-USB controller) where
DEVICENUM is the GPIB address of the instrument corresponding to that
port, and then would have to do a write or read or whatever function
is being done on that instrument VISA port.
I haven't figured out if it is possible to do this easily. Help and
pointers on where to look for hints would be much appreciated. Many
thanks!
Milos

My first impression is that if you don't want to make any changes at all to existing programs is that the wrapper you need is one around VISA. You would need to intercept all of the calls into the NI VISA driver. If you create your own visa32.dll and in there, change the addressing and then call the real VISA driver, you might (repeat, might) get something to work. If this would even work, you still might find that you have to make significant changes anyway. The serial connection is going to be considerably slower, and interface specific functions such as service request handling, bus triggering of multiple instruments, etc., would be difficult to impossible. This would be a lot of work, imho, to just save a couple of hundred dollars over a real GPIB controller. I've seen this Prologix device before and have even used NI's RS-232->GPIB controller. The Prologix intended use to me seems to me more for a hobbyist or very casual user. Of course, I'm used to having multiple GPIB instruments worth 10s/100s of thousands of dollars and the cost of an fully compliant GPIB controller is just lost in the noise.

What is the recommended length of the cable in between the GPIB instrument and GPIB-USB card.

hi,
we are planning to use GPIB-USB Controller in our application by replacing the existing GPIB-PCI controller. Our GPIB instrument doesn't have the standard IEEE GPIB Connector. So, we will have to connect one more cable in between GPIB-USB controller and the GPIB Instrument. I just want to know what is the recommended lenth of the cable that can be connected in between the GPIB instrument and the GPIB-USB card. Could anybody please help me?
Thanks,
Rajaram

Page 730 in the 2001 catalog gives detailed cabling requirements for the GPIB bus. It's usually best to keep the length 2meters or less.
Randy Solomonson
Application Engineer
National instruments

Getting the same return string while reading multiple times from a GPIB instrument

I'm having problems reading data from a GPIB instrument.
I'm using a sequence similiar to this:
1. Send a "MEASCALRES?" command to the calibrator to measure the current pressure.
2. Read the result string sent from the calibrator.
3. Send a "SYST:ERR:NEXT?" query to check if an error has occured.
4. Recieve the error string from the calibrator.
When running the program, the error string sometimes contains the same data as the pressure reading. For example, if the calibrator's pressure output string was "1.0000000e2", the error string might be "1.0000000e2" or sometimes just "20, No Errors", with the extra "2" added to the normal "0, No Errors".
The problem a
ppears to occure randomly, a rough estimate would be that it happens one time out of 50 readings.
Are there any relevant GPIB card settings I can change to fix the problem?

It looks to me that more data is send or data end is signalled to early by hte iocard.
Maybe you should check the gpib bus cable speed. The default is much too fast for almost all instruments. Put it on 2 microseconds (the slowest speed). And we always disable autopolling, to prevent asynchronous actions.
greetings from the Netherlands

Desperate user need help. My GPIB instrument get stuck with my labview program frequently

Hello to all labview users,
i am a beginner in using labview. I am currently writting a labview program to automatically control a digital control rotator HD201e and a network analyzer 8720a to work with the anechoic chamber. The program receives an initial position, amount of increment and # of steps. My program will then ask the controller to rotate to the initial position and at the meantime, the program will monitor the position of the rotator to ensure the requested position is reached. After that, at the position, the program will ask the NA to perform a reading of the measurement. Once the reading is done, the program will ask the controller to rotate to the next position and does a reading of the measurement and so on.
My program seems to be able to perform the tasks; however, the dig.controller part seems to get stuck around 50% of the time when running the program. Sometimes, even the controller receives the requested position (can be seen from the lcd screen of the controller), the rotator just simply would not rotate; also, sometimes, the controller just simply does not respond when sending the command of moving a position, as in the debug mode (the one with a lightbulb), i see that i got "ok" on all the blocks in the writing portion ofthe program, but the controller just doesnt seem to receive the position (as seen no new position received from the lcd screen) and the cursor on the lcd screen blinks weirdly, due to that problem, my program will then get stuck in an infinite loop.....
Usually, that problem occurs after few positions have been reached.....
so, when that happens, i have to stop my program and re-run it. that means the program will have to re-do the measurement that were read previously....
sometimes i have to stop and re-run my program several times to get all the measurement of all the positions done.....so...that bug renders that program to be an unefficient program.
I have been trying to resolve that bug for weeks...but no success....i have tried to put some wait time between each block....result is not much different...
I have also tried putting "clear" block before and after the "write" block.....same problem.....
I have heard that the serial GPIB "flush" block may help...but i tried..but it seems the controller doesnt recognize/accept flush....
i have also tried using the "Visa open" and "Visa close" block to see if ithat reduces the stucking thing....but seems that the controller can still get stuck....
i have also even tried using "lock asyn" and "unlock asyn" block...but didnt seem to work....
Has anyone experienced such problem.? Is it a known problem with some gpib instrument?
Is there any discrepancy or bugs in my program that i am unaware of that causes this problem?
Any advice and or opinion would be greatly appreciated....
PS: i attached the controller part of my program and the overall program
desperate happyguy......
Happy guy
~ currently final year undergraduate in Electrical Engr. Graduating soon! Yes!
~ currently looking for jobs : any position related to engineering, labview, programming, tech support would be great.
~ humber learner of LabVIEW lvl: beginner-intermediate
Attachments:
HD201_Controld.jpg ‏231 KB
AChamber_Measurements_v1d.jpg ‏857 KB
AChamber_Measurements_v1d3.jpg ‏463 KB

hi xseadog
i got what you meant about the gpib reference
actually, that final frame works because the gpib reference is already done inside that subvi.
but my problem doesnt arise from that. most of the time ive seen, it arises between the writing frame and the while loop frame. as i mentionned, sometimes. the controller just simply doesnt rotate even i can see the requested position display on the controller lcd screen; also sometimes, just the controller is stuck without acknowledging the write position command. but in labview...while in debug mode. it is shown ok on the block.
Happy guy
~ currently final year undergraduate in Electrical Engr. Graduating soon! Yes!
~ currently looking for jobs : any position related to engineering, labview, programming, tech support would be great.
~ humber learner of LabVIEW lvl: beginner-intermediate
Attachments:
HD-201 RPosd.jpg ‏39 KB

Can I use GPIB instruments via GPIB-USB-HS and NI-VISA on MacOS with Matlab somehow?

I've just installed NI-488.2 (14.1) and I can see my GPIB instruments in the NI-MAX app. However I can not find them in the tmtool function in Matlab. Aparently Matlab on mac does not support GPIB (http://se.mathworks.com/help/releases/R2014b/instrument/supported-hardware.html) but it does support VISA.
Do you think there might be a way to connect to my devices in Matlab through VISA some how?

Hi thanks for you answer.
Yes, I installed this version: http://www.ni.com/download/ni-488.2-14.1/5090/en/ which says: "NI-488.2 for Mac OS X, Version 14.1, installs NI-VISA and NI-MAX by default". I can also see all the correct .framework-files in the "Library/Frameworks/"-folder:
And since I can see (and query) the GPIB devices in both the "/Applications/National Instruments/NI MAX.app" and "/Applications/National Instruments/NI-VISA/NI-VISA Configuration.app/
HOwever Matlab does not want to detect any VISA drivers...

Why can't the Instrument Wizard detect my GPIB instruments?

My system has the AT-GPIB/TNT card. I can detect the GPIB instrument connected to the card with "Measurement & Automation" but when I go into Labview Instrument Wizard and try to find the GPIG instrument, all I see is Serial ASRL1 and ASRL2. What can I change so that I can detect the GPIB instruments in Instrument Wizard? I've tried everything. I have NI 488.2 v1.60 installed and NI VISA v2.01. Any help would be appreciated. Thanks!

Make sure that you check the box next to "GPIB" on the second screen of the instrument wizard. Also, make sure that what you are seeing in Measurement and Automation Explorer (MAX) is the most recent case (refresh your screen). It is possible that the instrument is offline, but since MAX doesn't automatically refresh everytime a change is made, it may appear that the instrument is still being detected.
The following link may help.
http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/8e2f0a10f99519268625680400644435?OpenDocument
Kim L.
Applications Engineer
National Instruments

GPIB Instrument Driver Installation

Hi,
I'm currently making software that communicates with several different type of GPIB instruments such as power meters, spectrum analyzers, etc. With these instruments, I make different types of measurements. Obviously, to run these intruments I download the drivers or make my own. Now here is my question: Is there a way to implement a driver installation interface in my software so it could allow any user to easily install drivers for any types of instruments? What is also tricky is, these drivers have to be used in my code afterwards to get measurement data. Hope my intentions are clear enough!
Thanks!!

I don't understand the relationship between VI Analyzer and IVI. The VI Analyzer is used for checking your code for a variety of style recomendations. IVI is a standard for instrument driver interchangability.
For the instruments that fall into one of the 8 defined IVI classes, you should use them and IVI class drivers in your LabVIEW program. Right now, those are the only classes and your network analyzer isn't included. You can go to http://www.ivifoundation.org/ and check the status of other classes but I think the only additions on the horizon are AC power supplies and counter/timers. Since IVI has been around for 8 years and that's an average of 1 instrument a year, we'll probably have to wait another 2 years before these classes are released and if you want a network analyser class, you'll probably have to wait several more years for that to get approved.
Until this happens, you will probably need to provide your own drivers (or wrappers around existing drivers) for instruments that don't fall into existing classes. They may lack some of the true IVI functions such as state caching and simulation but the interchangable part would not be that hard to do if you can define a set of common functions that such an instrument has to provide.

MAX communicates fine with GPIB Instrument, LV Standalone Exe Front Panel Control Does Not See It.

I have succesfully created a LV standalone EXE which communicated with external GPIB instruments. I used LV 7.1 for this. I upgraded DAQMx to 8.0 on the development machine and also the target which runs the Exe. The EXe runs fine on the development machine but when run on the target laptop, the front panel control fails to see the GPIB instrument. On the target, in MAX I successfully setup communication with the GPIB instrument. Is there some incompatibilty with DAQMx 8.0 and LV7.1? An additional piece of info here: when upgrading to DAQMx 8.0, I selected the installation support for LV 7, 7.1 and also 8. Could this be where the problem lies?
Thanks
Peter

The GPIB code is actually an IVI driver made for a Rhode and Schwarz TRMS meter. Its the standard VISA Read/Write, nothing out of the ordinary. I'm using a USB-GPIB-HS adapter to communicate with it. Like I mentioned, the VISA instrument control drop down list on the front panel of the Exe does not list any GPIB instruments, all that is listed is ASRL...1, ASRL...4, and ASRL...10. In the EXE that used to work, there were no ASRL... references listed. What was listed was the GPIB0...INSTR...20, COM1, and the parallel port. So something weird is going on now, somehow effected with the load of DAQMx 8.0.
Pete.

Trouble reading data from GPIB instrument using VISA

Hello, I am having trouble with reading data from a GPIB instrument in LabVIEW. It appears that the data that is returned from VISA read is incorrect. (I used NI Spy to verify what it should be and what I get, they are different) The odd thing is that when I use the VISA interactive control utility to get the data, it works perfectly. Is there some sort of VISA property that I need to set to get it to work right? Writing to the device seems to work correctly. If you need more info, please e-mail me @ [email protected] Thanks in advance!

What exactly do you mean when you say the data you are getting is incorrect? I'm guessing that you are dealing with some sort of data type issue. The VISA Read VI will return a set number of bytes in string (ASCII) format. If you are expecting a different data type, you will have to do some conversion by either using a type cast or string conversion function. The type cast function can be found in the Advanced-> Data Manipulation palette, while the string conversion functions can be found in the String palette.

How remote/local mode for GPIB instruments works?

Remote/local mode for GPIB instruments is being controlled by REN one of five interface management lines. That's the only information available on this subject. Where can I find some more detailed explanation? I still don't know what conditions have to be met to put device in remote/local mode.

REM indicates whether or not the board is in the remote state. REM is set whenever the Remote Enable (REN) GPIB line is asserted and the GPIB board detects that its listen address has been sent either by the GPIB board or by another Controller. REM is cleared whenever REN becomes unasserted, or when the GPIB board as a Listener detects the Go to Local (GTL) command has been sent either by the GPIB board or by another controller, or when the ibloc function is called while the LOK bit is cleared in the status word.
A call to the function ibonl clears the following bits:
END LOK REM CIC TACS LACS DTAS DCAS
You can find more information in the NI-488.2M Software Reference Manual (see link below).
http://digital.ni.com/manuals.nsf/web_productcurrent/43AB49D953CE104E8625665E0
07D11FF?OpenDocument
All of our manuals are available online at the following site.
http://www.ni.com/manuals/
Thanks,
Kim L.
Applications Engineer
National Instruments

GPIB instrument driver identification

What is the right labview GPIB instrument driver for ESP300 motion controller produced by Newport Inc.?
The drivers for motion controllers of Newport posted in ni.com website looks all different with the models provided by newport.

Hamfery,
The drivers provided on our website don't apply to your Newport motion controler.Newport is providing motion utilities for this model. It's been written in LabVIEW but you cannot edit it since it is an executable.
Cyril Bouton
Applications Engineering
National Instruments
Cyril Bouton
Active LabVIEW Developper

Read multiple GPIB instruments

Hello,
I have a time issue when I want to read simultanously GPIB instruments (from 1 to 24 instruments with 2 GPIB cards - GPIB0 and GPIB1). The user can choose the nomber of instruments he's gonna read.
For 17 instruments choosed for example, there's is an array of 17 rows wired to a for loop where the read GPIB is done (See TestVi and For Loop.jpeg). It took about 5 sec to get all data.
But If I juste copy 17 times the read Vi (configured as a reentrant) in a simple vi like in Untitled2.vi, it tool about 1.5 sec to get all data for the same conifguration!!! (See Without For loop.jpeg)
How could I read as fast than in Untitled 2.vi with a for loop or something else to allow users to set more or less instruments without copying the read Vi any time the configuration changed ?
I tryed to use Call a VI dynamically but it didn't worked.
Thank you for your help
Solved!
Go to Solution.
Attachments:
TestVi.zip ‏461 KB

Hello Anthony,
You should be able to find examples in the NI Example Finder (Help > NI Example Finder in LabVIEW) by searching for the term "Asynchronous".
In 2013 there are some examples located in the place illustrated in my sceenshot.
Kind Regards,
Thierry C - Applications Engineering Specialist Northern European Region - National Instruments
CLD, CTA
If someone helped you, let them know. Mark as solved and/or give a kudo.
Attachments:
Capture.PNG ‏43 KB

Semaphors to synchronize several GPIB instruments?

Hello,
I have to develop a programm to diplay three different GPIB instruments on screen. The instruments should also be switchable between different modes. Thus, I have write and read access from time to time (of course read dominates to capture data).
I managed to program every single instrument with open/read/write/close VISA quite well, but when I first tried to implement two instruments in a block diagramm, I got error messages which disappeared when I switched to the slow highlighted execution. So I think there´s a problem with read an write access to the GPIB.
I now implemented semaphors to encapsulate every read and write access and it works.
Now, eventually, my question:
Is it common to use semaphor
s with GPIB access?
Should everything work without semaphors, which means that the architecture of GPIB should prevent such errors?
If you need additional information please let me know...
Thanks for any answer,
Andreas

Andreas:
Needing synchronization is a very common issue because if one area of code writes a query, and then another section of code comes along and does a query, there are a couple of issues:
1) In most 488.2 instruments, the response to the second query will overwrite the response to the first query. Only one of the two pieces of code (depending on which runs next) will get that response.
2) Even if the instrument generates two responses, it is possible the pieces of code will be interleaved, generating strange results. For example, write A1, (context switch), write A2, (context switch), read A1, (context switch), read A2.
There are several solutions. You can use LabVIEW semaphores, which you have done. You can also use VISA locks, which do p
retty much the same thing, as long as each section of code has its own session. If you use the same session in both pieces of code, then VISA locks wouldn't help you.
So since your solution works as is, keep it. It's good, it's needed in your case, and it's the right thing to do.
Dan Mondrik
National Instruments

Is it possible to control a GPIB instrument by the instrument through GPIB

I'm having a Function generator, it has an in built GPIB, I'm writing an application on oscilloscope which also as GPIB, I have connected the GPIB port of oscilloscope to the FG GPIB port. I tried to send a GPIB command from the oscilloscope to the function generator. I wanted to know whether it is possible to control an instrument from a instrument through GPIB.

The answer is yes and no. There are three categories of devices:
talker/listener
talker/listener/controller
talker/listener/controller/system controller
Most instruments are "talker/listen-only". All they can do is act like a device on the GPIB.
You do run across a few instruments that are "controllers' as well. These instruments can be passed control from the system controller to temporarily control the bus, perhaps to calibrate themselves with a collaborative instrument. To find out if your instrument supports this, you probably need to look in the instrument's user manual.
The other option is for the device to be a system controller. This means that the device can control the bus at bootup (system controller) and run a host-side API (i.e., NI-48
8.2) to control an instrument. This sounds like what you are interested in.
I hope this helps.

GPIB instrument holding up bus

Similar Messages

Maybe you are looking for