Visa timeout stuck at 0?

I have an application which uses ni-visa (version 4.2) USB raw bulk communications on Vista PC. It works well most of the time. Periodically I get a timeout error at VISA write (-1073807339) even though the visa resource is present, which I know because immediately before the Visa write I query lots of the visa properties. I noticed that when this error occurs that the property: general settings>timeout value = 0, instead of 2000 msec which it normally is. So I added code to my app to explicity set the timeout to 2000 msec right before the visa write. This DIDN'T fix the timeout on the visa write and when I read this property I see that my setting the timeout value to 2000 was ignored (no error), and that the timeout is still 0. Note - all other USB status properties look good, the out pipe and its status are good. The visa resource is not locked. When I rebooted the computer the problem goes away.
So, my question is: what could be changing the timeout to 0 (it's not my app doing this) and also not allowing me to programmatically change the value?? Does a timeout of 0 signify some special status of the visa driver?

Hello DrMike,
Thank you for your post. I have a few suggestions/questions.
First, have you tried handling the error, setting the timeout back to 2 seconds and trying the VISA write again? It is possible that this is a strange USB issue that could be resolved by trying to write the data a second or third time.
Another suggestion I have would be to upgrade to NI-VISA 4.4.1. Sometimes these issues are present in older versions of the device, but are fixed along with other issues in driver upgrades.
Let me know if this works or if you find another workaround.
Regards,
Dan King

Similar Messages

DAQmx VIs Timeout Problems

Hello,
I am trying to acquire 9 frequency input chanels thorugh PXI-6624 card.
I have 9 independent loops for 9 frequency counter chanels. I am able to read all the frequencies above 10Hz properly.
Now the problem is,
Sometimes there will be no pulses, and the Counter Input DAQmx VI will wait for timeout.( I have given the timeout of 1 sec). During this time my CPU consumption goes very high and I am not able to read any of the analog inputs too.
and say if similar condition happens to all the 9 frequency input channels then my software hangs.
I have tried using wait mode method but i wasnt able to read any frequency with it.
I have also read it that, when "Counter Input DAQmx VI is in timeout mode at that time we cannot make any other DAQmx VIs call". Please refer this link http://zone.ni.com/devzone/cda/tut/p/id/3166
Thanks,
Krunal

What version of LabVIEW? Did you install DAQmx AFTER installing LabVIEW?
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

NI-Visa - Timeout during initialize of power supply

Hello, I'm having an issue initializing a power supply using the NI-Visa libraries. After creating the session, the 1st call to Initialize() always fails. If I call it once again, it always succeeds. Adding a delay between the session creation and the init call did not help.
An oddity is that running SPY causes the problem to go away. I tried this a few times while recording and never saw the timeout. However, once SPY was stopped the same timeout behavior could be seen again. Does SPY add some type of latency within the NI-Visa libraries?
Any suggestions or troubleshooting tips would be greatly appreciated. Below are some setup notes in no particular order. Thanks.
1. Power supply: Lamda 40-85, Genesys 3.3kW
2. Issue: Initialize() must be called twice before returning successful
3. Visa error: Timeout expired before operation completed.
4. Steps to recreate:
4.1. Create session
4.2. Call initialize, results in a timeout
4.3. Call initialize, returns success
5. Setup details:
5.1. NI Visa libraries
5.2. Visual Studio 2010, C#, .NET 4.0
5.3. Reference libraries:
5.3.1. ivi.dcpwr.interop, runtime version v1.0.3705, version 2.0.0.0
5.3.2. ivi.driver.interop, runtime version v1.0.3705, version 1.0.0.0
5.3.3. ivi.sessionfactory.interop, runtime version v1.0.3705, version 1.0.0.0
5.4. NI PXI Chassis, Windows XP
5.5. GPIB interface

I tried the updated dll's, actually only "ivi.sessionfactory.interop.dll" was newer, but received the same behavior.
I also sent the "*IDN?" message using the communicator,but was unable to reproduce the behavior no matter how many times I queried the power supply. However, there is a discrepancy between sending the "Initiate" command from within code versus using the communicator and sending "*IDN?", so I am unsure how to replicate the same steps. My previous post detailed the SPY log in response to sending the "Initiate" command, while sending "*IDN?" results in:
1. ibwrt(UD0, "*IDN?", 5 (0x5))
Process ID: 0x00000F58         Thread ID: 0x00000330
Start Time: 16:25:12.437       Call Duration 00:00:00.000
ibsta: 0x100       iberr: 0             ibcntl: 5(0x5)
2. ibrd(UD0, "LAMBDA,GEN40-...", 2000 (0x7D0))
Process ID: 0x00000F58         Thread ID: 0x00000330
Start Time: 16:25:12.437       Call Duration 00:00:00.359
ibsta: 0x2100       iberr: 0             ibcntl: 45(0x2d)
My app uses VISA commands while the communicator uses "ibwrt", etc. How do I go about simulating the "Initiate" call while using the Communicator? My code is posted at the bottom of this reply for clarity.
An oddity that is that, after a failed attempt to initiate the device which results in a timeout exception, the communicator can be used to read the standard response to the "*IDN?" command. This is the case even if the "idQuery" boolean of the "initiate" method is set to false. If idQuery=true, how is the resulting name supposed to be read back? The initiate function does not have a return value or any way of passing by reference. I tried all four combinations of the two flags, "idQuery" and "Reset", but nothing seemed to change in any configuration.
In response to your question about the firmware version, I pulled this from the spy file: "LAMBDA,GEN40-85-IEMD,S/N:xxxxxxx,REV:2U:3.0-D-". The reply appears to be truncated so I'll double check the response on Monday once I'm at the computer with the SPY file.
Again, thank you for input and attention. If you have any suggestions, please let me know. It will be sometime next week until I will be able to perform any more troubleshooting unfortunately. Do you see anything wrong with the "Initiate" method call, especially the name used? I'm curious if I should use the full name instead of the alias, but if that is the case why does the "initiate" call work the 2nd time? Oh well, I'll give it a try. Thanks again.
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.DCPwr.Interop;
using Ivi.SessionFactory.Interop;
namespace IviDcPower
    public partial class Form1 : Form
        IIviDCPwr _DcPwrSession;
        IIviDCPwrOutput _IiviDcPwrOutput;
        public Form1()
            InitializeComponent();
        private void btnCreateSession_Click(object sender, EventArgs e)
            try
                IIviSessionFactory factory = new IviSessionFactoryClass();
                // Ask the session factory to create an instance of
                // the appropriate driver based on a logical name
                _DcPwrSession = (IIviDCPwr)factory.CreateDriver("ProgDCPS");
                addText("Session created");
            catch (Exception ex)
                addText(System.Reflection.MethodBase.GetCurrentMethod().ToString() + "\r\n" + ex.ToString());
        private void btnInitialize_Click(object sender, EventArgs e)
            try
                addText("Initializing...");
                _DcPwrSession.Initialize("ProgDCPS", cbQueryID.Checked, cbReset.Checked, "");
                if (_DcPwrSession.Initialized)
                    // Use IIviDcPwrOutput class-compliant interfaces, interchangeable code
                    _IiviDcPwrOutput = _DcPwrSession.Outputs.get_Item("");
                    addText("Success");
            catch (Exception ex)
                addText(System.Reflection.MethodBase.GetCurrentMethod().ToString() + "\r\n" + ex.ToString());
                addText("Failed (Exception)");
        private void addText(string text)
            textBox1.Text = text + "\r\n\r\n" + textBox1.Text;
        private void btnCloseSession_Click(object sender, EventArgs e)
            try
                _DcPwrSession.Close();
                addText("Session closed");
            catch (Exception ex)
                addText(System.Reflection.MethodBase.GetCurrentMethod().ToString() + "\r\n" + ex.ToString());

Serial VISA timeout

We are using a VISA serial read configured without a termination character. We are reading 84 bytes in 20 second intervals, with the timeout set to ~10ms. The goal is to read all 84 bytes, and use the time out to stop the read operation between the transmissions.
The timeout should effectively end the receive operation during the rest between transmission intervals, but this is not the case. The 84 byte message is being split into two or even three parts.
How excatly does the timout property operate? How can we configure the VISA to read all 84 bytes of the message together before reading the next message and exit only on the interval between messages? Thanks

Did you confgure VISA to not use a termination character because the device does not send one or for some other reason? If the device does not send a termination character and it is constantly sending data, you have a synchronization issue that the timeout is not going to solve. You need to provide some more details on the instrument and how it works.

VISA timeout, how to deselect and wait and wait...

Hello All
Is there a way to deselect (set to infinity) the time out of the serial port VISA?
I know I can use loops, etc. but I am interested especially in this solution.
Thanks a lot.
Pawel

Pawel:
Yes, 0xFFFFFFFF is the timeout for infinite. It is a special value and should not time out after 1.5 months. (As you had noticed, 0 does mean immediate.)
Dan Mondrik
National Instruments

What causes the VISA timeout error 1073807339?

I'm getting this error while using a HP audio analyzer. The error also says "Timeout expired before operation completed." Can anyone give me any info on this?

Hi
Try increasing your timeout value. Check this link too: http://www.ni.com/support/labview/visa/verr2.htm
Hope this helps
Regards,
Luca

Visa Read Timeout Occurs with multiple Reentrant VI Calls

I have written a test application in Labview (6.1) which will be used to test (burn-in) up to 15 serial instruments through a 16 Port USB->RS232 Hub. Here's how it works:
When the App loads, I am transmitting a Connect command to each of 15 com ports (one-at-a-time) using VISA. If I receive the proper response from the unit on that port, I add the port to an array and continue on to the next system. Once I've found all systems on the hub, I wire my array of active Visa references to a for loop in which I open up to 15 reentrant VIs which will run in the background in parallel. Each of these reentrant VIs (all are idential with the exception of the Visa Resource they use) running in the background are sending commands to the the respective instrument and receiving a response. One Function in particular "Get Unit Status" is important and the response determines whether or not the instrument is functioning correctly. Here's the problem -- In my Main Loop, I am continuously acquiring indicator values from each of the reentrant VIs that are running in the background. After a period of time (not consistent) I will lose communication with a port (the symptom is no response from the unit). I've looked closely at the COMM engine I created and found that the Visa Write function is completing without error, then when I perform a Visa Read I immediately get the "Timeout occured before operation completed" error (please keep in mind that this occurs after 100-5000 successful attempts at writing/reading). Eventually another port will drop out, followed by another. This seems to stop occurring and the remaining systems run to completion without a problem.
Some background on what how I'm setting up my Visa Sessions...
When I originally scan for systems (before I load and run the Reentrant VIs)
- Init Visa Port
- 19200, 8, N, 1
- Use Termination = True
- Timeout = 400mS (I've tried larger values already) 400mS should be plenty
- Termination Char=13 (/r)
- Open Visa Session
- Visa Write "CONN18/r" (the command required to connect to my instrument)
- Visa Read with 1 for requrested byte count to read 1 byte at-a-time, concatenating the results until /r is received (or 1000mS timeout occurs -- this is not a VISA timeout) I've also tried 16 for requested byte count and just waiting for Visa to timeout -- both methods work.
Once all 16 ports are scanned I Close ALL of the ports using the Visa Close Function.
It is important to know at this time that I "AM" using proper wiring flow to ensure open occurs before write, write occurs before read, etc.
I'm assuming at this time that all of my Visa sessions are closed.
On to the Reentrant VIs:
Inside each reentrant VI I first Initialize all of my variables and Init/Open a 'New'? Visa session using the same parameters mentioned above.
Then I enter the "Run" case structure where all of the communication begins.
I am using the same Communications Engine to operate the instrument as before (the only difference being that all of the VIs in the comm engine are now reentrant and operate at higher priorities) I have actually saved two different versions of the engine (one for the reentrant calls and one for when I first scan for systems from my Main GUI).
When I init the reentrant VI, I am placing the Duplicate Visa Resource output of my Visa Open Function on a shift register. When I enter the Run case, it takes the Resource from the register on the left, wires through any Comm Engine Vis then back out to the shift register on the right and keeps going for a 12-hour period or until "Get Unit Status" has returned 60 naughty results.
On my Main GUI I am continuously (every 500mS) I am Getting certain Indicator Values from each reentrant VI AND I am also setting some control Values on each reentrant VI. There is no VISA interaction between each Reentrant VI, and the Main GUI.
As I said earlier, up to 15 systems will run for a time, then one will stop responding, followed by another, and another until a few remaining systems will run to completion.
Any advice as to why I'm encountering the timeouts with the VISA read fucntion as I have metioned would be appreciated. I managed to find one suggestion which uses the Bytes at Port function to ensure there is data at the port before doing a Read otherwise, skip the read and retry the whole operation -- I haven't tried this yet.
Sorry for the wordiness of my question. If anyone would like some screen shots of portions of my code (I can't submit the actual code because some of it is confidential) I'd be happy to post them.
Doug.

Hi Doug,
The first thing I would recommend is the solution you have already found, to check and see if there is data at the port before attempting a read. I would be interested to see if this will solve the problem. Does there seem to be any trend to which ports have this timeout error? How many ports does it cut down to before operation seems to continue as expected? Does this number vary, or is it always the same number of ports? I think the best thing to do will be to identify constant attributes of how the error is occurring so that we can narrow it down and see what is going on.
John M

VISA Serial and Elapsed Time as a Timeout

Hi folks,
Still new to LabView, so please bear with me...
I have a VI that sits and wait for a certain character string to arrive over the serial port, but I need a timeout that doesn't rely on the VISA timeout.
I expect a bunch of text through the serial port for ~45 seconds, then my input string will compare the matching string and move on to the next VI.
In the event of no string match, the serial port may keep on sending serial data, or may be inactive (non-determinisitic because this test is to see if a computer system booted correctly). But once the VI starts, I should have 60 seconds to find the match, or set the bool output 'selection' to fail.
I have tried putting my Elapsed Time loop inside the main loop, outside, with/without SRs, and now I'm at a loss. I looked at the VI highlighted and the serial activity wasn't active until the 60 second timer expired.
Please take a look at the attached, and thanks for taking a look at this post.
Solved!
Go to Solution.
Attachments:
Untitled 1 (SubVI).vi ‏33 KB

I'm not entirely certain that I understand what you are trying to accomplish. However here are my thoughts:
The VI you attached will wait 60 seconds before checking the serial port for waiting bytes ONCE then read bytes if they are availale and quit immediately. This is because you have the while loop around the elapsed time and it must execute completely before moving on to the serial communication loop.
I assume you have setup the serial port and set termination characters, etc in a main vi
Please try the modified VI attached and let us know if that helps
Thanks,
Charles Chickering
Charles Chickering
Architecture is art with rules.
...and the rules are more like guidelines
Attachments:
Untitled 1 (SubVI) Modified.vi ‏33 KB

Timeout units for VISA Configure Serial Port

Hi there,
Can anybody answer a simple question:
What units are used to setup a timeout: seconds or milliseconds?
LabView Help is very confusing.
Thanks,
Greg
Attachments:
VisaTimeout.JPG ‏75 KB

It's milliseconds. You can see this for yourself by just opening the front panel of the function. You'll see the label of 'timeout (10sec)' and a value of 10000 in the control.
Message Edited by Dennis Knutson on 05-02-2007 09:29 AM
Attachments:
VISA Timeout.PNG ‏23 KB

Semaphore get stuck

Hi,
I have a case with semaphore vis getting stuck (deadlock) waiting for each other.
I have 2 dynamic VIs.
The first one, called sendprocess.vi, sends continously messages to CAN at different rate. So I used parallel time-loops with different interval times. Each of these loops has a semaphore to guarantie that there is only one loop can send data to CAN at a time.
The second one, called receiveprocess.vi, receives messages from and send back some asynchronous message. Cause it also using send CAN function so I also use semaphore to guard it.
After runing for couple of seconds, all of these semaphores get stuck.
I would appreciate any helps or suggestion of another architect which make it runs better.
Best regards,
Thang Nguyen
Attachments:
deadlock semaphore.JPG ‏160 KB

I don't see anything blazingly obvious despite the fact your pics overlap.
Are you sure you have no other code trying to acquire semaphores? (any at all).
By the way, your case statements will never execute the TRUE case with the timeout on the Acquire set to the default of -1 (meaning Acquire will hang waiting for the semaphore as long as it takes as you have observed).
Message Edited by Bill@NGC on 07-31-2009 11:22 PM
“A child of five could understand this. Send someone to fetch a child of five.”
― Groucho Marx

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

How to resolve the serial communication error in HP34970?

I want to use serial port to commnucation between pc and hb34970. In gpib mode, it is ok. But in serial mode, report error. just like this:
for setting com2:
16:11:47.359 2009-8-26 [Init_dq_Device]error:-1073807339--HP34970A Initialize.vi->Init_DQ_Device.vi->main_app.vi VISA read.visa name:ASRL2::INSTR
for setting com1:
16:13:25.921 2009-8-26 [Init_dq_Device]error:-1073807339--HP34970A Initialize.vi->Init_DQ_Device.vi->main_app.vi VISA read.visa name:ASRL1::INSTR
I don't know the meaning of -1073807339 and whether i should set:ASRL1::INSTR for com1. Anyone can help me about this problem.
Thanks very much.
attach my subvi.
Solved!
Go to Solution.
Attachments:
Init_DQ_Device.vi ‏48 KB

Hi, Dennis Knutson
very glad to see you.
For my vi, i only provide a UI for user to select GPIB or serial mode, and setting related port.
About "Also, the 34970 llb you are using should be replaced with the 8.x project library.", What do you
mean? There is a new driver for 34970,right?
I search the forum and find a old thread:Agilent 34970 Visa Timeout.
There is your answer:
I made a mistake. The initialize function already had a timeout function. I just didn't look at the VI closely enough. There is a case statement that sets either the serial port parameters or just sets the VISA timeout. If you are setting the timout right after the VISA Open, it's just getting set back to 10 seconds. Change it in the case statement and see if that works. Sorry, and I hope this works.
Do you think this is the same with my problem? Your mean to modify default 10 seconds to more longer timeout,right?
Thanks.

Serial port vi taking too much time to communicate?

i am using visa vis for serial communication the read vi takes too much time to give me the bytes at serial port.what should i do to decrease the delay?

You wouldn't happen to be specifying a byte count to read or setting read termination when a specific character is read would you? If you are, if you don't have the right number of bytes in the serial buffer or if the termination character is not seen, then VISA read will wait for the time specifed by the VISA timeout value. To fix the first problem, use the VISA Bytes at Serial Port function to determine how many bytes to read. In the second case, use a VISA property node to set Message Based Settings:Termination Character Enable to false and Serial Settingserial End Mode for Reads to none.

Not executed Commands from Testprograms written in Labview communicating over GPIB

Hello
Sometimes I have the problem that the commands sent from testprograms written in Labview aren't executed from the devices
(for example a counter or a power supply).
An extension of the the wait time between Write and Read couldn't solve the problem (We use VISA-VIs or the Manufacturers-VIs).
First workaround is to send the command again.
Somebody else ever had the same problems to deal with? What did you do?
Many thanks
Best Regards
Silvio

Usually stuff like this is caused by incomplete understanding of communications using the GPIB bus (either by the programmer OR by the supplier of the drivers - the latter reason being why I almost always write my own drivers).
Many times, an instrument fails to respond in what we considre a "timely" manner - a prime example is an instrument that takes several seconds to complete a measurement. Many times, instruments don't queue commands, so if you send a command to an instrument while it is still processing a previous command, it won't be aware of the command you just sent, and you will get a timeout. In this case, it's best to make the VISA timeout something like 5000 ms and - if your instrument accepts the command - use *OPC? to turn your command into a query. This way, your application always waits for a response - usually a "1" - from the instrument being commanded before sending the next command.
Bill
Bill
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.

Upload and read binary files

I have created ADF form with input file item for initiator human task ( to upload a binary file)
In the second form, I want see link of the file uploaded and I want open the file in other window ( to see the content of the binary file)
How can I do?
Thanks Elena

Azazel,
Looks like you are just being an over achiever. There are VI's specifically written for reading and writing binaries. I would guess that the VISA timeout is caused by the way you are calculating the size of the file. Since it is too big the VISA session will time out. See attached example for the easy way to do this.
Matt
Matthew Fitzsimons
Certified LabVIEW Architect
LabVIEW 6.1 ... 2013, LVOOP, GOOP, TestStand, DAQ, and Vison
Attachments:
RWbinary1.vi ‏100 KB

Visa timeout stuck at 0?

Similar Messages

Maybe you are looking for