Re: Keitheley USB GPIB visa write returned vi_error_rsrc_nfound

"Can you explain why VISAIC works and labview does not?"
Visaic is a 32-bit application and you are using 64-bit LabVIEW. There is no passport for tulip in 64-bit VISA so there is no way to access the gpib-32.dll that the Keithley USB GPIB driver has.

I have left similar message in Keithley forum so far 20 + views no reply so far.
I have replace the keithely driver with 3.12.1 found in their website instead of what I was using in the CD that came with the adapter. but still the same behavior.
I just downloaded VISA 14.0.1 and still the same.
I launched the NI-VISA wizard and on the USB - Device Selection it recognize the adapter as Keithley model KUSB-488B. but when I choose Install the generated files on this computer I got an error dialog.
first time
got an resource error dialog 
second attempt go this error dialog
"An Error has occured that has prevented the driver from being installed on your computer. One reason for this error may be because you lack the proper privileges to install this driver. You may need to log in as administrator to complete this operation"
third attmpt no error
launch NI-MAX and now it has the USB show up on the Device and Interface list.
the device show up as USB0::0x05E6::0x488B::NI-VISA-4003::RAW in NI-MAX
launch VISA Interactive Control now the three device GPIB0::9::INSTR, GPIB0::20::INSTR, and GPIB0::22::INSTR are replace by USB RAW Resource and with only one entry so I can no longer send command to each individual device thru input/Output. the same address show up in NI-MAX is also in there USB0::0x05E6::0x488B::NI-VISA-4003::RAW.
attempting the same labview visa write and visa read using GPIB0::9::INSTR as input because I don't know where USB0::0x05E6::0x488B::NI-VISA-4003::RAW is getting routed still get the same error BFFF0011 insufficient location information

Similar Messages

  • Make visa write return sooner

    This is somewhat a continuation from this thread but I figured it was different enough to warrant another one. My question is this: I have multiple visa (serial) references in an array. I use an autoindexing for loop to write to each one. I have benchmarked the VISA write function and it takes 14 ms to execute when writing 68 bytes of data with a 38,400 baud rate. Because I have them in a for loop if I am using 8 serial ports, it takes over 100 ms for the for loop to complete. By this time, the hardware has expected another write to have happened on the first serial port, but because the subsequent writes (which are in serial..ha..ha.) take so long to execute, it hasn't written again. I know one solution is to put them in parallel, but I am trying to avoid spawning off threads on a PXI chassis based on the number of serial connections I have. This not only complicates the serial communication, but greatly complicates my application because then I would need to manage a dynamic number of queues being used to pass data to my host communication thread.
    As a side note, I have tried both synchronous and asych writes.
    Is their any way to communicate via serial, maybe on a lower level than visa, so it just sticks the data in a transmit buffer and leaves it there for the hardware to manage, rather than waiting for what looks to be a return after the data has been sent.
    CLA, LabVIEW Versions 2010-2013

    Jeff Bohrer wrote:
    Well, the async writes should be about as fast as you can go.  but the math (14mS for 68 bytes at 38400 Baud) seems off.  How are you connected to the PXI device.  I'm thinking a chassis controller might have less latency than say a MXI bridge.  You aren't doining anything silly like re-initing the VISA session right?  Put a conditional probe on the session in- is it valid?
    Currently I'm not sure how I am connected. However, I can say that no, I am not opening and closing the session in the loop. I made a test program that is just visa open, loop with visa writes, then visa close outside the loop. I have also verified the string truly is 68 bytes and there aren't extra characters in there I'm missing, or something like that.
    I have connected a scope up to the serial line. I put a gap of a few ms between writes so I can see where one transmission ends and the next one starts when looking at the scope. If I (on the scope) measure the delta time between the start and end of the transmission, it's ~19.4 ms. If I calculate 68 bytes*8 bits/byte + 3 bits for start stop parity / 38400 baud I get .0142 seconds or 14.2 ms. Is this calculation correct? The result is very close to what my benchmarking of the Visa Write is showing. Also, I'm curious of the 5 ms discrepancy between the delta t on the scope and the visa function time to execute. Any more thoughts?
    CLA, LabVIEW Versions 2010-2013

  • 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.

  • GPIB reads/writes compared with VISA reads/writes

    Hello all,
    Being slightly new to LV (3 months of casual use, and 1 month of really getting to know it)...
    I was just wonder what the difference between VISA reads/writes and GPIB reads/writes.
    Actually this is my main question: Is the GPIB Write "data" parameter and the VISA Write "write buffer" parameter the exact same thing?
    Would I write the exact same command with either parameter and get essentially the same effect (if all parameters are correct?).
    I have a list of GPIB commands that I want to use to write drivers for  a PSA, and I really want to use VISA, and not have to change my paradigm of thinking.
    I would hope they are quite similar.  In fact, my research is telling me that GPIB is almost like a subset of VISA?
    Thanks for your help.

    The data you write with the GPIB functions is identical to the data you write with VISA. There are some things that are a bit easier to use the traditional GPIB calls but for 99+% of the time, VISA will do the trick. VISA was originally conceived as a common api for GPIB and VXI instruments. The first VXI instruments were basically the same GPIB instruments without a power supply and the user interface (buttons, screen, etc.) but they required different drivers. VISA permitted a single driver to be used for both types of instruments. Now, VISA has expanded to include serial, Ethernet, USB, and PXI and not having to change your "paradigm of thinking" is one of the big reasons that VISA is so widely used.

  • Serial VISA 'Write' -why is it slow to return even with large buffer?

    Hi,
    I'm writing a serial data transfer code 'module' that will run 'in the background' on a cRIO-9014.  I'm a bit perplexed about how VISA write in particular seems to work.
    What I'm seeing is that the VISA Write takes about 177ms to 'return' from a 4096 byte write, even though my write buffer has been set to >> 4096.
    My expectation would be that the write completes near instantly as long as the VISA driver available buffer space is greater than the bytes waiting to be written, and that the write function would only 'slow down' up to the defined VISA timeout value if there was no room in the buffer.
    As such, I thought it would be possible to 'pre-load' the transmit buffer at a high rate, then, by careful selection of the time-out value relative to the baud rate, it would self-throttle once the buffer fills up?
    Based on my testing this is not the case, which leaves me wondering:
    a) If you try to set the transmit buffer to an unsupported value, will you get an error?
    b) Assuming 'yes' to a, what the heck is the purpose of the serial write buffer? I see no difference running with serial buffer size == data chunk size and serial buffer size >> data chunk size??
    QFang
    CLD LabVIEW 7.1 to 2013

    Hi, I can quickly show the low-level part as a png. It's a sub-vi for transferring file segments.  Some things like the thin 'in-line' VI with (s) as the icon were added to help me look at were the hold-up is.  I cropped the image to make it more readable, the cut-off left and right side is just the input and output clusters.
    In a nut-shell, the VISA Write takes as much time to 'return' as it would take to transfer x bytes over y baud rate.  In other words, even though there is suppused to be a (software or hardware) write and read buffer on the com port, the VISA write function seems to block until the message has physically left the port (OR it writes TO the buffer at the same speed the buffer writes out of the port).  This is very unexpected to me, and what prompted me to ask about what the point is of the write buffer in the first place?  -The observations are on a 9014 RT target built in serial port.  Not sure if the same is observed on other targets or other OS's.  [edit: and the observation holds even if transmitting block-sizes of say 4096 with a buffer size of 4096 or 2*4096 or 10 * 4096 etc. I also tried smaller block sizes and larger block sizes with larger still buffers.  I was able to verify that the buffer re-size function does error out if I give it an insane input buffer size request, so I'm taking that to mean that when I assign e.g. a 4MiB buffer space with no error, the write buffer actually IS 4MiB, but I have not found a property to read back what the HW buffer is, so all I have to base that on is the lack of an error during buffer size setting.) [\edit\]
    The rest of the code is somewhat irrelelvant to this discussion, however, to better understand it, the idea is that the remote side of the connection will request various things, including a file.  The remote side can request a file as a stream of messages each of size 'Block Size (bytes)', or it can request a particular block (for handling e.g. re-transmission if file MD5 checksum does not match).   The other main reason for doing block transfers is that VISA Write hogs a substantial ammount of CPU, so if you were to attempt to write e.g. a 4MiB file out the serial port, assuming your VISA time-out is sufficiently long for that size transfer, the write would succeed, but you would see ~50% CPU from this one thread alone and (depending on baud rates) it could remain at that level for a verrry long time.   So, by transferring smaller segments at a time, I can arbitrarily insert delays between segments to let the CPU sleep (at the expense of longer transfer times).  The first inner case shown that opens the file only runs for new transfers, the open file ref is kept on a shift register in the calling VI.  The 'get file offset' function after the read was just something I was looking at during (continued) development, and not required for the functionality that I'm describing.
    QFang
    CLD LabVIEW 7.1 to 2013

  • I can't install VISA driver and USB GPIB driver on my PC with VISTA... help me...

    I have LabVIEW7 and VISTA, it's ok, but I can't install VISA driver and USB GPIB driver on my pc... it's necessary to connect my pc with instruments? Or LabVIEW7 have this files??? Thanks,
    Vanny.
    Thanks,
    Vanny
    Sweet, Beautiful and Young Female Physicist (SBYFP)
    (I speak a not very good english, so If U are Italian LabVIEW expert speak in Italian, if U speak in Eglish... please speak easy )
    My e-mail for personal contact: [email protected]_NO_SPAM_PLEASE
    Solved!
    Go to Solution.

    You need Administrator privelages to install drivers on Vista
    David
    www.controlsoftwaresolutions.com

  • GPIB-USB-B VISA I/O Library version

    I need a GPIB interface that VISA I/O Library version 1.1 compliant to connect to an Agilet 8722ES network analyzer. Is the GPIB-USB-B VISA I/O Library version 1.1 compliant?
    Thanks,
    Brian Keats

    Hi Brian,
    The GPIB-USB-B device is simply a hardware device that responds to the driver you have installed for the device. The NI-488.2 drivers which control the device have complete NI-VISA functionality, and there is even an instrument driver on our website available for this device which uses GPIB and VISA. You can click here to go to the download page. The GPIB-USB-B should work great for this application.
    John M
    Applications Engineer

  • GPIB locks up after about 15 minutes with a VISA Write Timeout Error

    I am using GPIB to control two electronic loads.  After about 15 minutes of runtime on the program, the GPIB communication locks up.  A probe reveals an error message about a Visa Write Timeout.  When this occurs, I have to stop the program, cycle the power on the two loads, and then restart the LabView program. When addressing the loads, I use the same routine every time.  1) Initialize communication, 2) Send command/request, 3) Close communication.  I thought I might have been overloading the GPIB bus, so that's when I added the close command after each sequence. However, it didn't seem to make a difference.  Could there be a compatability issue with the GPIB of the loads and the NI GPIB or Windows version? (I'm using XP and LV 10)  The electronic loads are older models, so I'm not sure how that impacts this scenario.

    Hi kcarbon80, 
    As this thread is over 2 years old, I do not know what solution was found for the previous problem being addressed, if any. However, if the device is locking up in the middle of your program, you may want to try clearing the device programmatically using the DevClear.vi that comes with the NI 488.2 driver. 
    I hope this helps. 
    Best Regards,
    Thomas B.
    National Instruments
    Applications Engineer

  • GPIB instruments connected through Agilent USB/GPIB Interface can bee seen in MAX but can't communicate in labview

    I have an Agilent 82357B USB/GPIB Interface connected to my computer. 
    Attached to that, I have two lock-in amplifiers (an SR830, and an SR
    850).  I would like to be able to communicate with them through GPIB.
    I have downloaded and installed the software for the Agilent device
    (Agilent IO Control), and I can see the interface and the two devices
    in that software.  Here's what is configured in this software, that I
    can see:
    The VISA interface ID is GPIB0, and its address is 0
    The VISA addresses of the devices are GPIB0::4::INSTR and GPIB::12::INSTR, and the GPIB addresses are 4 and 12
    In Measerment and Automation Explorer (MAX), I made sure that the
    Passport for Tulip box was checked.  Once it was, I could see the
    devices in the Configuration window under Devices and Interfaces ->
    Miscellaneous VISA Resources.  There, I see GPIB0::INTFC, GPIB0::4::INSTR and GPIB::12::INSTR.
    I can right click on either of the instruments, and "Open VISA Test
    Panel" where I am successfully able to send commands and read from both
    devices.
    HOWEVER, when I am running an actual LabView program, I am unable to communicate with the devices. 
    For example, when I try to communicate to the devices through VISA,
    using the 'Basic Serial Write and Read.vi' (while VISA Resource Name is
    GPIB0::12::INSTR), I get an error:
    Error -1073807331 occurred at Property Node (arg 2) in VISA Configure Serial Port (Instr).vi->Basic Serial Write and Read.vi
    Possible reason(s):
    VISA:  (Hex 0xBFFF001D) The specified attribute is not defined or supported by the referenced resource.
    When trying to communicate with them through GPIB (which is what I want
    to do in the end), using 'GPIB.vi' I also get an error.  Here, GPIB
    address is 12, and I am just trying to give it the command *IDN?
    GPIB Write returned error code:
    EDVR: Error connecting to driver or device
    What's going on?

    You can use VISA Write and VISA Read. You just can't use the example called Basic Serial Write and Read because that is specifically for the RS-232 port. The GPIB-VISA is one of the shipping examples. Start the example finder and go to the search tab. Search for VISA.
    Again, no you cannot use the GPIB functions with a non-NI controller. The low level functions for an NI board and an Agilent one are completely different. You can rewrite the driver to use VISA or you can rewrite it to use the low level functions that Agilent provides. You use the Call Library Function Node, I believe to access their GPIB driver.
    I hate to say it but the $20 difference between the Agilent and the NI controller does not seem like much of a saving.

  • Error -1073807346 occurred at VISA Write in rsspecan_core_write.vi

    Possible reason(s):
    VISA:  (Hex 0xBFFF000E) The given session or object reference is invalid.
    I'm using a USB to GPIB connection to a Rohde Schwarz FSV30 Spectrum Analizer from Windows 7.
    My program works 100% in LabView but the problem comes in when I've compiled the program into an executable.
    I have already installed the NI VISA Run Time Engine 5.0.1 and it still does not work.
    I've also installed the NI-488.2 2.73 drivers for the GPIB unit.
    Any ideas?
    Solved!
    Go to Solution.
    Attachments:
    Error -1073807346 occurred at VISA Write.png ‏30 KB

    Hey,
    the problem when building executables with LabVIEW is, that the driver core of the attribute based instrument drivers (esp.. the VIs which are creating this error) is linked while runtime dynamically to the VIs. The application builder which follows all dependencies and include them into the package fails in this case.
    To get a running executable please add manually all VIs for the folder <inst lib>\rzspecan\_utility\rsspecan_core\callbacks\ to the LabVIEW project and everything should work fine.
    For more details of this driver refer to http://www.rohde-schwarz.com/appnote/1ma170
    So long, juergen

  • How do I input multiple string constants into VISA Write

    I am trying to put in multiple string commands into VISA Write to control a motor arm. However, when I use "concatenate strings" to link together my multiple string constants, only the first command is executed, and neglects the other commands below it. Should I be using something other then "concatenate strings" or do I need to use a delay so that the next command executes when the one before it is finished? Help.

    Concatenate strings should work or just use one string constant with multiple lines. The problem you're having could be that the instrument requires some sort of delay but without details on the instrument, only you or the vendor can answer that. Some instruments will have a queue and others won't. The other possiblity is that you need some kind of termination character between commands. This might be a carriage return for a serial instrument or the ; character for a GPIB one. Check the instrument manual or provide the make and model and maybe someone here has some experience with it.

  • Connecting hp 8508a vector voltmeter with agilent 82357a usb/gpib converter

    Hello
    For my experiment, I need to connect to a HP 8508A vector voltmeter by using an agilent 82357A usb/gpib converter. I have a serious problem about communicating with my device using NI-VISA. I tried to do the steps indicated at following links which were indicated at the forum posts by people using 82357A:
    http://digital.ni.com/public.nsf/allkb/F7C187DBF09EBE1186256F550065BD32?OpenDocument,
    http://digital.ni.com/public.nsf/websearch/3B3626D9C1F999218625694200791AD7?OpenDocument,
    http://cp.literature.agilent.com/litweb/pdf/5990-3731EN.pdf?cmpid=1273CN.
    The version of MAX is 4.3.0f0 and i am using labview 8.5 with NI-VISA 8.2. I am trying to configure my 82357A using agilent io libraries suite 14.1. 
    First, I tried to configure my usb/gpib controller using  agilent connection expert and set the visa interface id to GPIB6 and connect to the 82357A without any problems. Then I connect this gpib converter to my vector voltmeter. The gpib adress of the voltmeter was 6(gpib address of the interface converter was 10) so visa address GPIB6::6::INSTR was assigned to voltmeter by connection expert. I tried to connect to the voltmeter from the connection expert by using the agilent interactive IO. Send *IDN? command and took the proper response from the voltmeter. The voltmeter went into remote mode and I tried to read the voltage values by using the FETCH? command of the device and got the voltage properly which means I successfully connected to the device.Then I went to MAX and enabled the NIVISATulip.dll and restarted the MAX. Then I went back to agilent connection expert and checked the box: "use agilent 488 library where possible" for side-by-side communication between the NI and agilent visa. By the way agilent visa was installed as the secondary library.  Then when I went back to MAX, I start to see the voltmeter under miscellaneous VISA resources with the address  GPIB6::6::INSTR. But the problem started here. When I tried to send commands from MAX to voltmeter with the "open visa test panel" I encountered an error which exactly says:"unable to open session to GPIB6::6::INSTR, return status code:0xBFFF009E, status name:VI_ERROR_LIBRARY_NFOUND, a code library required by VISA couldn't be located or loaded." As I said before i enabled the libraries of agilent 488 from the options of the agilent connection expert. When I went back to connection expert and unchecked the box for using agilent 488 libraries nothing changed. Also when I went to NI-VISA interactive control I couldn't see my device under the tab of VISA I/O. 
    I tried to read some posts from this forum. People are using this usb/gpib converter successfully without any problems by performing the steps I have done. I have some questions about possible subtle points specific to my application.
    First question is according to the manual of the voltmeter(this is an old device by the way from 1988):"vector voltmeter is capable of remote operation via the HP-IB which is HP's implementation of IEEE standard 488.1  "So, what I understand from this sentence is my device is communicating remotely with IEEE standard 488.1 and not 488.2 Does it make any problem? What kind of modifications should I do to my setup for overcoming this if it creates any problems? As I said before I was communicating with device very properly from the agilent connection expert. In manual there is also a sentence like "HP-IB commands used in the vector voltmeter conform to the standards set by document IEEE 488.2 1987." 
    Second question is should I install newer versions of agilent io libraries suite or MAX or NI-VISA. I wrote the versions I am using before are they compatible? Where can I install newer versions? As I know the newest version of the agilent io libraries suite is 15.1 or 2. Is is compatible with 82357a?(maybe I should ask this question to agilent people)
    Third question I don't remember how I did it but agilent visa is indicated as secondary visa resource in agilent connection expert(I think I did it while installing agilent io libraries suite.) . How can I switch between NI and agilent visa as primary visa resource? Do you think think this will help?
    I terribly need measurements from this set up and really appreciate your help if possible.
    Sincerely
    Caglar Yavuz, University of Michigan,Ann Arbor,EECS department. 

    Caglar,
    The documents you mention ahould include the proper prcedure for using this hardware in LabVIEW. Here are my recommendations:
    The version of NI-VISA  you mentioned is not valid. The most recent version is 4.6.2. I would recommend ugrading if you do not have this version. After the upgrade,ensure that tulip is enabled as well as the other settings and see if this helps.
    When talking about the instrument, the biggest concern that usually is relevant with 488.1 is that it will not respond to *IDN?. In your case, it looks like it does, and should work as 488.2 is backwards compatible. It seems to me, the issue is still with the 82357A, and we have not yet reached the voltmeter.
    In order for NI-VISA to work with your device, NI-VISA must be the primary visa driver.
    Hope this helps, let us know how the upgrade turns out. If you continue to have issues, take some screenshots of the preferences in MAX and upload them on the forum.
    Regards,
    Peter Flores
    Applications Engineer

  • How can a I solve and GPIB/VISA compatibility problem?

    My Labview (version 5.1 on a Macintosh) application talks to a variety of instruments over GPIB. In one mode it communicates with both 1) a LakeShore 340 temperature controler (LS340) using VISA-based drivers and 2) a Linear Research LR-700 AC resistance bridge using low-level GPIB functions. My application can query these instruments a couple of times per second, usually without trouble. However, periodically (about once an hour) the GPIB Read will cease to work with the LR700 or any of the other instruments on the same bus, returning error 6 (I/O operation aborted). GPIB Write still works fine. Querying the LS340 when the system is in this state produces the VISA error Hex 0xBFFF003C (Insufficient system reso
    urces to perform necssary memory allocation). Querying the LS340 a second time is successful, and thereafter GPIB Reads are also successful.
    I think somehow the GPIB and VISA protocols are interfering with each other. (Although the data dependency requires that the VISA Write/Read be complete before the GPIB Write/Read begins, I am not opening/closing the VISA session with every iteration. The VISA session is opened on the first iteration and stored in a shift register.) However, the maddening infrequency of this problem makes it very difficult to troubleshoot. Any suggestions?

    Hi Chris,
    One suggestion;
    Write two seperate test routines that each use only one method or the other.
    Test the H*&#$ out of each to attempt to determine if the issue is associated with the high level or the the low.
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • How can I solve a GPIB/VISA compatibility problem?

    My Labview (version 5.1 on a Macintosh) application talks to a variety of instruments over GPIB. In one mode it communicates with both 1) a LakeShore 340 temperature controler (LS340) using VISA-based drivers and 2) a Linear Research LR-700 AC resistance bridge using low-level GPIB functions. My application can query these instruments a couple of times per second, usually without trouble. However, periodically (about once an hour) the GPIB Read will cease to work with the LR700 or any of the other instruments on the same bus, returning error 6 (I/O operation aborted). GPIB Write still works fine. Querying the LS340 when the system is in this state produces the VISA error Hex 0xBFFF003C (Insufficient system resource
    s to perform necssary memory allocation). Querying the LS340 a second time is successful, and thereafter GPIB Reads are also successful.
    I think somehow the GPIB and VISA protocols are interfering with each other. (Although the data dependency requires that the VISA Write/Read be complete before the GPIB Write/Read begins, I am not opening/closing the VISA session with every iteration. The VISA session is opened on the first iteration and stored in a shift register.) However, the maddening infrequency of this problem makes it very difficult to troubleshoot. Any suggestions?

    Hi Dan,
    I'm trying to follow your suggestion, but I can't get the VISA upgrade to function. I downloaded the NI-VISA 2.6 full development installer, which recommends uninstalling the prior version first. I couldn't find a good way to do this (the documentation is no help), so I ended up just reinstalling the entire Labview 5.1 without the VISA package. But even this approach (I tried several others) doesn't work - when I run VISA commands from within Labview after the VISA 2.6 install, I get 'unknown system error'. Any suggestions?
    Chris

  • VISA Write hangs after running OK for a while

    VISA Write function (VISA abc W) in my VI runs OK, with a Return Count of 4, for a while (100's to 1000's of times)  then it hangs.  The Return Count from this function is then 0.  The Error In and Error Out show no errors.  Clicking HIGHLIGHT EXECUTION shows the output wires from the VISA Write as colored grey, while everything else has normal color. 
    Clicking the VI red ABORT button, or any of the sub VIs red ABORT buttons, fails to abort or reset the VI even after 20 minutes.  Task Manager will stop LabVIEW, but then LabVIEW will not start up again without shutting down and restarting the computer.  Changing to a different Windows XP computer and a different PCI-GPIB, NI-488.2  board, as well as reinstalling LabVIEW 7.0, or using a different LabVIEW 7.0 serial number, has not solved the problem. 
    Thank you for your help.

    Thanks for your reply.  Attached is a PowerPoint file that shows info on our computer and LabView, and a For Loop
    (Slide 3) that runs the VIs addressing one of our instruments (Hart 1590 Super Thermometer).  Slide 4 shows the
    block diagram that is pretty much as downloaded from National Instruments.  The block diagrams for each of the
    colored sub VIs contains a sub VI having a VISA abc W function as shown in Slide 5.  The only places this VISA
    function hangs is in inside the While Loop, inside the yellow Meas. Status. VI or the blue Read Meas. VI.  The
    Meas. Status. VI sends "new", and  the Read Meas. VI sends "tem" to the Hart instrument. 
    Also attaced are the VIs for the Measurement Status and the Read Measurement.  In the course of trying to fix this
    problem I've added various time delays of 50, 100 msec, up to 1 sec, thinking that the Hart needed more time to
    respond before receiving another command; none of this improved the situation.  I added indicators and arrays to
    capture the last several strings that were input to the VISA function, but I saw nothing unusual.  All I've been
    able to determine is that the VISA abc W function hangs as described in my posted message. 
    Attachments:
    VISA Write Hang 9-15-05.zip ‏282 KB

Maybe you are looking for