GPIB timeout

I'm using a GPIB to collect data from a Tektronix Oscilloscope and everyday when I come in and try to collect it gives me this error HEX 0XBFFF0A6. I'm using windows 7 and LabView 2011. Each time I just restart LabView and it works just fine throughout the day. Opening MAX shows that it is communicating with the instrument. If this error code is simple I apologize but Google is down due to SOPA.
I've also had similiar problems with USB DAQ devices but in that case it is windows disconnecting from the instrument.

Hi TSCline,
These kinds of errors are usually due to GPIB/VISA reads where the message received is larger than the expected amount of bytes. Try programming a routine which will flush the buffer contents and try the collection command again. http://zone.ni.com/reference/en-XX/help/371361H-01/lvinstio/gpib_clear/
In addition, if you are not doing this already, look through our 3rd party drivers page for your Tektronix model and see if you can download proven VIs to control your Oscilloscope (http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/sn/catnav:id/q/Tektronix/)
Hope this helps!
Aldo A
Applications Engineer
National Instruments

Similar Messages

Is GPIB timeout byte based

Is the GPIB timeout established with ibdev implemented on a byte basis or on a message basis?
If timeout is 10sec and I make an ibwrt call to send 10 byte message to a device that's been turned off, how long until I get a timeout return? 10 sec? 100 sec?
The gpib lib help implies that it's on a message basis but it's not perfectly clear to me. I know rs-232 library timeout is on a character basis, not a message basis.
Thanks.

According to the NI-488.2 Help, the ibdev command uses the input IbcTMO, which uses a v constant that specifies predefined timeout values. So if you make an ibwrt call to send 10 bytes to a disconnected or turned off device, you will wait whatever the v value of IbcTMO is.
Regards,
Daniel REDS
RF Systems Engineer
Help us grow.
If a post solves your question, mark it as The Solution.
If a post helps, give Kudos to it.

Labview gpib timeout when calling cvi dll

Equipment used :
VXI Rack with Slot 0 controller
Labview V5.0.1
Lab Windows V5.0.1
GPIB controlled Power10 I63 PSU
We run an intermediate Labview driver which communicates with a low level CVI driver (dll) to control a PSU. We recently tried to run the Labview driver on a Slot 0 controller and we get timeout errors when waiting for a response after commanding the PSU to switch off ( "CST OFF" is sent , and the driver waits on "ST OFF" being returned - it never does and times out). Ni Spy is on when it fails. In the same driver, a call to return the Instrument ID is carried out happily, with the ID being returned with no errors.
I can run the low level CVI driver with an interactive script and it works fine with no errors.
I can run the Labview driver with NI Spy switched off and it works ok too, Our customer cannot get it to work even with Ni Spy switched off. They have the same setup as us.
Any ideas?

The solution I had previously documented only partly worked. It cleared the timeout error, but I am still experiencing various errors in testing the PSU with Labview (still no problems with running the functions with Labwindows directly). Also, if NISpy is running I see no errors, which still leads me to believe its a timing problem. I saw another thread on here from someone with similar problems and I tried all the recomendations in that, but it still did not fix it. The last recomendation was to re-write the GPIB driver to slow down the message transfer to the instrument!
A link to the thread with similar problems to mine.....
http://forums.ni.com/ni/board/message?board.id=140&message.id=20031
Message Edited by edinsofty1 on 09-09-2008 07:21 AM
Message Edited by edinsofty1 on 09-09-2008 07:21 AM

What is the best method to query for older GPIB equipment with ID? and newer with *IDN?

Good day,
I am writing a test executive where it needs to scan the bus for support of older (HP/Agilent 856x series) and newer (Agilent 440x and 444x series) spectrum analyzers. *NOTE* I originally posted this question in my NI Community blog. I apologize for redundancy but someone recommended I re-post here.
The first frame looks for the newer analyzers with *IDN? then if that fails sets the boolean in the error cluster to TRUE. The next frame then uses the error cluster's boolean to decide whether an older HP analzer is connected instead using ID? query. Disclaimer: the second frame is a clone of the ID query of the 856x Initialize VI. I just want to use what already worked - no reinventing the same wheel?
But, lo and behold, it doesn't work as expected. If I have the frames in this order and connect a HP8563E the GPIB time's out error. This code works with the newer 4407 or 4440 since the *IDN? query passes and the second frame is not executed.
Now, when I move the second frame to become the first frame and run it with HP8563E the query works but will have a GPIB timeout if I have the 4407 or 4440 connected.
Long story short, how do I support both older GPIB ID? and newer IDN? in my code?
I have attached the query VI created with LV 2012.
Many thanks!
Aldrin
Attachments:
Query ID and IDN.vi ‏11 KB

I think Michael Aivaliotis of JKI and NI have an elegant solution:
https://decibel.ni.com/content/groups/large-labview-application-development/blog/2015/05/14/what-is-...
Cheers!
Aldrin

TNT488.2 embedded issues

We are trying to use the NI-TNT488.2 GPIB chip in an embedded application.
However, we are having problems with the chip locking up when the host PC
(with clock speeds at 500+MHz) is pushing and pulling data to and from the
target (embedded system) in a TALK / LISTEN scenario. The symptom is that
the TNT488.2 stops presenting interrupts on "ADSC" status changes. We are
doing programmed I/O on the embedded system with the chip configured in "One-Chip"
mode. We have an event driven implementation scheme using a multitasking
OS. That is, we do not have a dedicated micro servicing the TNT488.2. We
have trapped a case where the chip stops presenting interrupt requests -
the transition from "ADSC" - "NEUTRAL" to "LISTEN". When we run t
he Spy utility
on the host PC, we see either no data or one character transfered followed
by a GPIB timeout on the host. Any time the chip (on the embedded system)
fails to present the interrupt request to the microprocessor, the chip is
locked up forever if there is no intervention by the microprocessor to reset
the device. Since we have observed this failure condition, we now set a flag
and a timer to check for the lock-up. If the lock-up has occurred we issue
a "PON" to clear the lock-up. The downside to this approach is that it forces
customers to run through error recovery proceedures in their host applicaitons
a very high percentage of the time. Error recovery should be part of every
solution, but not within every minute of operation.
If anyone has had similar problems and has found the cause of this type of
problem, we would like to hear from you.

no, but have you tried clearing the history, cache, and cookies then resetting the touch? Reset the touch by holding the home button and the sleep button until you see a silver apple. Do nothing else but this then try the problems again.

Keithley 228 power supply

Hi, i have written a labview program to control the keithley 228 power supply. If i input 5V and 1A into the power supply from my front panel when the power supply is turned on, the power supply display panel will display 5V and 0.2A. The 0.2A is the current which is drawing by the DUT. My question is if i were to display the 0.2A onto my labview program on the front panel, i need to input a 1000ms into the timeout of the GPIB read function, inorder for the current to display out. If i input less than 1000ms, the current is unable to display out. But i need fast reading and measurement, the 1000ms input into the GPIB timeout have affect my testing. My hardware configuration consists of the keithley 228 power supply, 7053 switch card and 7002 switch box.
I have tried using the 228 driver from the NI web, but it don't seems to work. You may take a look of the attachment file of my written VI. Please advise.
Thank you.
Attachments:
Set_228a.vi ‏46 KB

Hi Desmond
Try to add an extra endcharacter to your string.
I saw that you rely on EOI (End or identify) and the keithley should respond.
But maybe it is faster in mode 3 (add CRLF)
I'm talking about the send/read data
Furthermore...
You are using a sequence frame for sequencing the write and read..
You can use sequence by wiring instead.
See case 3 of your vi.
greetings from the Netherlands
Attachments:
Set_228a.vi ‏46 KB

Gpib, wait does not return after timeout

I use this code line:
gpibDevice.Wait(GpibStatusFlags.DeviceServiceRequest | GpibStatusFlags.Timeout);
I want to wait for a Service Request or a Timeout.
The IOTimeout is set to 1s, but the Wait function does not return after 1s.
What is the problem? Do I have to set any other timeout?

Hi Gregor,
I am sorry but this link that you send, did not help me. I am using this code within a c# application. This is a bit
different to LabView. Here is my full code:
gpibAddress = 1;
timeoutValue = TimeoutValue.T1s;
gpibDevice = newDevice( 0, gpibAddress , 0 , timeoutValue );
gpibDevice.IOTimeout = timeoutValue;
gpibDevice.Clear();
gpibDevice.DefaultBufferSize = receiveBufferSize;
gpibDevice.SerialPollResponseTimeout = timeoutValue;
gpibDevice.Wait(GpibStatusFlags.DeviceServiceRequest | GpibStatusFlags.Timeout);
And I still have the Problem, that this Wait Function does not return after the
timeout value - here 1s. Do I have to configure anything else from the GPIB device?

VISA READ timeout error - multiple GPIB resources

Hi,
I am working on a 3 instruments GPIB network (optical attenuator, fiber amplifier, spectrum analyzer), controlled using VISA sessions in Labview. When run separately, the three corresponding VIs (which are located in three different Labview projects) work as expected. However, when they are ran simultaneously, one of them gives VISA READ -1073807339 timeout errors. These errors seem to happen when an other instrument is sending / receiving data / instructions at the same time as it is.
The exact context for these error is either :
- an other VI is running, which includes sending several queries and reading the answers every 100 ms,
- upon starting the failing VI, I get a timeout error from one of the first subVI containing a VISA READ operation to be executed (sometimes initialize.vi (in state 1), sometimes one of the subVIs ran from the Idle state (state 0) upon timeout of the event structure).
or :
- the failing VI is running,
- upon starting an other VI, which includes repetitively sending queries and reading answers, the failing VI throws an error from one of the first subVI containing a VISA READ operation to be executed (one of the subVIs ran from the Idle state (state 0) upon timeout of the event structure).
What I tried :
- gradually increasing the delay between the VISA WRITE and READ operations for the relevant instrument (from 10 ms to 10s), to no avail. More puzzling is my obseration that, when this VI is run alone, increasing the WRITE / READ delay leads to the same timeout errors. I could not find any mention of such behavior through google and forum searches. Hopefully this can point to a solution to the main issue,
- switching between synchronous and asynchronous VISA WRITE / READ operations,
- reordering the GPIB network from a star topology to a linear topology (all three instruments do have different GPIB addresses in case anyone wonders).
My thoughts :
It seems to me that the error is related to a delay introduced between a VISA query and its associated read operation by the transmission of another query to another instrument in the same GPIB network. However I have no idea why transmitting a query to another instrument would introduce such a delay, or why this delay would lead to a timeout error (and only from one instrument, while the write / read VIs in each driver are basically the same). Hopefully a more experienced Labview-er will be able to shed some light on my issue.
Included is the project containing the failing VI (main.vi) and the custom driver it makes use of.
Solved!
Go to Solution.
Attachments:
Manlight EDFA Control - Failing VI.zip ‏73 KB
EXFO FVA 3150 - Driver.zip ‏348 KB

Thank you for your input crossrulz. This is indeed what I realized while looking into semaphores.
Let me first make our architecture clear so that I'm 100% certain we are talking about the same thing. We have a NI GPIB-USB-HS GPIB Controller connected to a linear GPIB network of three instruments. I was convinced that a network allowing up to 15 instruments to be connected at the same time would allow for parallel operation, but it seems I was mistaken.
I like how semaphores work, and I don't see any obstacle to gathering all these VIs into one project. My conception of a Labview project was that one Labview project was intended to gather subVIs, libraries and controls used in a more complex "main" VI, which would ultimately be made into a single standalone executable. It seems I was mistaken too and that a single Labview project should be used to gather several standalone VIs designed to work together, and their subVIs. Hopefully I got it right now.
The other option that you suggest for accessing the same GPIB bus from different projects (having a TCP control interface running and controlling communications through the bus) might indeed be a bit overkill for what I'm tring to achieve, and I would need to spend too much time learning and developing it.
A last option I looked into is the VISA Lock Async VI, but I don't understand yet if 1. locking the VISA session for an instrument in the bus would lock the entire bus ; 2. if it would be possible to use this approach with VIs running in different projects and 3. if it would not just yield errors when one VI is trying to access the locked GPIB bus instead of making it wait until the resource is available.
I'll look further into these options today, but would appreciate any additional information / advice you might have. Thank you.

Why do I get timeouts with a GPIB-ENET/100 under Solaris that I did not get with GPIB-ENET.

We have an existing application that works fine under Solaris 2.6 and Solaris 7 with a GPIB-ENET. When we swap the GPIB-ENET with a GPIB-ENET/100, we get devices timeouts all the time.

Hello-
Unfortunately, it's difficult to determine any possible cause for this occurance. It was mentioned in a previous email that the instrument will communicate for a few commands. When does the timeout happen? What command fails? Also, what type of instrument is connected (make, model, etc)? Is this a timeout from the write or read? What is the distance of the Ethernet from the host? Is it possible that another machine is accessing the GPIB-ENET/100? Would it be possible to include the code that communicates with this instrument? Does ibic or VISAic communicate with the instrument without timeouts?
Hopefully, this information can pinpoint the exact cause of the timeout.
Randy Solomonson
Applications Engineer
National Instruments

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

How to resolve the error -1073807339 when using Agilent LAN/GPIB Gateway (E5810A)?

Dear Sir/Madam,
Appreciate that you could advise me on the following error occur when connect power meter E4419B to computer via E5810A LAN/GPIB Gateway(remote interface) & run with Labview:
-1073807339
VISA Write in E4419_read_power.vi
I have added 5s timeout to Labview program but the result as previous.
There no error occurs when the power meter to computer via USB/GPIB interface(82357B).
Is it related to E5810A driver or the program I wrote?
How to resolve it?
Attachments:
E4419_read_power.vi ‏16 KB

Hi.
I'm experiencing the same problem when connecting a laser controller (New Focus Vortex TLB-6000) via the Agilent E5810A to a PC.
There are no problems when connected through a regular serial port, but timeouts arise every few seconds through the E5810A. I have another controller (SRS LDC501) which works very well with a second Agilent console.
Have you managed to find a solution to this problem?
Thanks,
Orel.

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

Slow GPIB performance after upgrading GPIB from 1.7 to 2.6 in Windows XP

We have bought several GPIB cards and installed driver 2.6, and I also installed the driver on my computer too. After installation, I got some questions:
1. After installation, under the path folder "C:\Program Files\National Instruments\Shared\ExternalCompilerSupport\C", there are three subfolders: include, lib32, and lib64.
    1) What is the difference between ni488.h, and ni4882.h? In my software, I choose include "decl-32.h", but I can also choose include "ni4882.h", right?
    2) Under the path folder "C:\Program Files\National Instruments\Shared\ExternalCompilerSupport\C\lib32\msvc", there are two lib files "gpib-32.lib" and "ni4882.lib". Is there any
        difference for user between these two lib files?
    3) How about lib32 and lib64?
2. Is the GPIB 2.6 compatible with its former version, V1.7, V2.4, and V2.5?
3. Why did our system become much slower after we change the GPIB card from driver 1.7 to driver 2.6 in Windows XP? Even after I changed the GPIB related lib and include files?
BTW, our lab PC is Optiplex 760, Core 2 Duo Dell E7500/2.93GHz, 3M, 1066MHz, FSB, with Windows XP SP3.
Can we make the timeout to be 0? how?

Actually it is not the GPIB driver version issue, and the issue becomes:
NI GPIB card cannot work good with Dell PC with Optiplex 760, Core 2 Duo Dell E7500/2.93GHz, 3M, 1066MHz, FSB, with Windows XP SP3.
NI technical support team, please give suggestion ASAP. Thanks

Utility to send text file over GPIB, one line at a time?

We are developing instrumentation that receives data and commmands over GPIB as plain text, and returns them as well. I'd like to create GPIB "batch" files and send them over the bus, one line at a time, so I can debug the instruments' behavior. I'd also like to be able to read back responses, one line at a time.
Is there such a utility? I've got our programmer working on something like this, but I'd hate to have him re-invent an existing wheel.
Thanks!

Apart from NI-SPY, I have not heard of such a utility. This may be simple to implement using proper termination. If the instrument is capable of sending line feeds or carriage return, you should be able to easily create a document. Also, using IBWRTF, you could write the ASCII file (containing the termination characters) to the bus. Depending on how you have your timeouts specified, this may be ideal.
Alternately, if you read a static amount of data, you could IBRD chunks of data. the result may need editing for broken words at the end of a line but would achieve such a result.
Ryan Mosley
National Instruments, Applications Engineer
http://www.ni.com/exchange

How to read data from a GPIB when sending a function generator command

I'm using Visual C++ with the ComponentWork ActiveX and I'm tring to plot a
CWGraph using the data coming from a GPIB device. When I write command such
as "*IDN?" to the GPIB device, everythings if fine and I can read what the
GPIB device return me. But when I send a command like "SOUR:FUNC SIN;SENS
DATA?", the writing seems to be okay, but when I try to read the data, I
alway get a "Timeout expired before operation completed" error message. I
have tried with the CWGPIB and with the CWVISA but the result are the same
with both.
My reading code looks like this:
COleVariant vReadBuffer;
vReadBuffer = m_VISA.Read( COleVariant( (short) 2000 ) );
and it work fi
ne for "*IDN?" or for multimeters command.
I want to know how I must read the data for function generator commands.
Thank alot

It sounds like your device is not accepting that command string as valid. The string you listed above is probably missing a colon between SENS and DATA. "SOUR:FUNC SIN;SENSATA" Try sending this string in Measurement & Automation Explorer to the instrument first to make sure it is working.
Best Regards,
Chris Matthews
Measurement Studio Support Manager

GPIB timeout

Similar Messages

Maybe you are looking for