-1073807343 ERROR NI VISA write in

NI VISA driver was working fine until I installed a Tektronix driver .It threw the following error from then on
"1073807343 ERROR NI VISA write in"
So I uninstalled the NI VISA driver to install the new version with the bug fixes .
But I was not able to install the newer version NI VISA 14.0.1 as throws the following error
Unsupported version of NI-VISA detected
A version of NI-VISA that is not supported on this operating system has been detected. You must cancel this installation and uninstall the older version before continuing. Visit ni.com/info and enter the Info Code CleanVista for more information."
But I have uninstalled the older version already . How do I fix it ?

I'm wondering if the driver installed the Tektronix VISA. You should uninstall that before installing the latest version of NI VISA.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Similar Messages

Why do I receive error -1073807339 VISA Write

I have a LV app built using LV2010 SP1 on a WinXP 32-bit machine. The app uses VISA to communicate serially through a RS232 to USB adpater to a pump. I can run the compiled app (exe) on another Win XP 32-bit machine without error. But the app generates "error -1073807339" with a VISA Write VI (timeout before completion) when run on Win7 64-bit machine. I have verified that both WinXP machines and the Win7 machine all have the NI device drivers installed (NI VISA 5.0.3), the LV2010 Run-Time engine, and the RS232-USB device drivers.
I have investigated sources of the timeout error and tried increasing the timeout with no success. I have also verified port settings, although the app is
identical between all machines.
I have verified that the installation on the Win7 64-bit machine was done using admin rights and files were installed correctly.
I feel like I must be missing something, so I'd appreciate some suggesitons.
Thanks
Dan

Can you communicate to the device on the Win 7 machine using hyperterminal or some some other communication program? Make sure that you have basic communication and it isn't some strange Win 7 thing. Are you runnign Win 7 64-bit? If so make sure you use the correct drivers.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Visa write connection has been lost

When I tried to use visa write, sometimes I will get an "1073807194" error on VISA write. "Connection for the given session has been lost" The only way to get rid of the error is to reboot computer, but the communication only be good for a while, then I got the same error again.
Anyone know what it means? I searched the forum, back in 2001, someone post the same question, and the solution was to install NI VISA 2.5.2 But I am using LV8, NI VISA is 3.4 now.
Thanks,

Hi DGU,
I'm assuming that you are using VISA to communicate over TCP/IP. This error is indicating that a connection has been lost with the network. You can enable or disable this keep-alive checking using a VISA property node. Here's a link to the LabVIEW 8 Help information on how to use this:
http://zone.ni.com/reference/en-XX/help/371361A-01/lvvisaprop/tcp_keepaliveinstr/
There a few more helpful links in the Resources section of this page. Also, here's a KnowlegdeBase entry that explains how this keep-alive property works.
http://digital.ni.com/public.nsf/websearch/072E607EE6E48AA986256F43005D2969?OpenDocument
Since rebooting fixes this issue, the problem may be with how Windows is handling this network. Is Windows reporting that the connection is being lost?
Michael Chaney
Systems Engineer - TestStand
National Instruments

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

Error -1073807346 occurred at VISA

My progarm has a very simple Visa write to a E4432 Signal Generator, which worked very good. After sometime Suddenly an error occurs which I cannot understand :" Error -1073807346 occurred at VISA Write in Setting Generator.vi;Possible reason(s):VISA: (Hex 0xBFFF000E) The given session or object reference is invalid."
But when I am using the NI-488.2 Communicator with the same SCPI syntax, it works right away. I chose the right Instrument handler address from the pull up menu of the controller.
What is wrong?
Regards
Yariv

Hi Yariv,
I didn't dig through every part of your code, but for the most part, it looks good. You've got it set up to run the "Quit" case last, which closes out your two VISA sessions before exiting. However, I did notice that on the "Sensitivity check" case, there is a possibility that the Front subVI will pass out a True, which would then stop the while loop immediately without going through the Quit case. If this happens, and something has happened in the SensitivityBlock 1.vi to interrupt the VISA Resource Name wires (and I did notice that these wires were not passed through in all of the cases in this subVI), then the state machine will exit immediately without passing the proper VISA Resource Name values out to the VISA Close VIs.
I also see in your post that you said that this error came back after some changes. When this happens, I would always look very closely at the parts of the program that I modified in order to see what I have changed in order to cause the error. You could also go back to a previously saved version of the program and add the changes one by one, making sure that the program still works at each step.
I won't be able to go through your code extensively, but I recommend tracing through the VISA Resource Name wires and making sure that in every possible scenario, these values get passed through to the close VIs. Good luck with your application!
john

VISA Write Error when using loop Err 1073807339

My program requires that I 'Start' my VISA device, poll it every second 10 times without clearing the device buffer. It is a counter and we are trying to accumulate counts over a 10 second period.
I first initialize the device with the 'Sart' command then try to get data.
For some reason the vi consistently runs successfully only 9 times and generates an error on the 10th run.
I guess the simple answer would be 'Why don't you just take 9 samples for your data?' I'm hoping there is a better explanation so that I can do it properly.
Attachments:
VISA_loop.png ‏68 KB
VISA_loop.vi ‏26 KB
Ortec Start2.vi ‏29 KB

The time out error on the VISA write to a GPIB device could be that the device did not ACK that it read the message.
On a quick look at your code, it first looked like you are sending \n at the end of your command, but you did not set the display mode of the Combo Box to "\' Code Display. So in fact what you are sending is SHOW_COUNTS follow by the "\" follow by the letter "n" and not a line feed.
How does your device handle the text "\n" at the end of the commands?
Does your device responed to the "System Error" command or the *STB command to see if it is setting an error flag?
Is it a SCPI device?
Most SCPI devices will hold up to 10 errors in it's system error buffer.
Just a guess without knowing much about your GPIB device.
Omar

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

VISA Write differs between TS Development System and LV Run-Time Engine

Hi all
I made an application on LabVIEW to test BERs (Bit Error Rates), and I used VISA Write between two COM ports to exchange data.
Everything works fine using just LabVIEW.
Afterwards, I used TestStand to call my application (VI). The LabVIEW adapters from TestStand were set to Development System by default, and everything works OK!!
Finally, I needed to disable the development system, and set the LabVIEW adapters from TestStand to LabVIEW Run-Time Engine and I notice that the speed of the data exchange between the two COM ports decreased dramatically.
The only difference was the speed...because all the data (changed slowly in this case) arrived correctly on the other COM port too.
The symptom was the same as decreasing the baud rate...but the baud rate and all the other configurations remained the same. The only difference was the change between Develpment System to Run-Time Engine to notice this decreased speed between the exchanged data using VISA Write.
Any solutions for this?
Thanks in advance
Joao
Solved!
Go to Solution.

Joao,
you state that using the LV Developement System as execution platform for your LV code modules result in faster datatransfer between the COM ports than using the LV Run-Time Engine.
So i am pondering: Does this refer to TS at all?
Please check the following:
Run you communication using a sole LV application in LV Developement System. This should be fast. Now build an executable of this application and run that one. Do you see the same behavior?
If there is no difference in a sole LV approach, there have to be some settings in the TS approach making this slow. So please let us know:
Are there different modules involved in that data transfer (which in fact points to the reply Christophe made)?
What about loading/unloading options of the modules?
How big is the hierarchy of the modules, e.g. is it necessary for the RTE to load stuff the Dev Env has already in memory due to loading a lvproj.......?
Could you provide a simple example sequence+modules showing this behavior?
What versions of LV and TS are you using?
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

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

Why does VISA write vi get a clock symbol added?

In an application, I was using the older serial I/O primitive vi's, and now that I've switched to LV 7.1, I wanted to change the older serial read and write (worked fine) vi's (not VISAs) to the VISA Read and Write. When I place a VISA write on the block diagram, it adds a little clock symbol at the upper right corner that was not on the templates.
What is this clock symbol doing there, when it wasn't on the functions panel version of the VISA write vi?
Having a lot of problems getting the VISA read and write vi's to work; they seem to be far more tricky than the old primitive serial read and write vi's.
All my VISA read vi's are getting errors, and some of them cause a severe slowdown on execution with those er
rors. Thoughts on debugging these problemsome VISA vi's. (These problems are why I used the primitive serial read and write vi's in the first place.. couldn't get the VISA vis to work.)
Thx.

The little clock symbol means to do I/O asynchronously. If you right click on the function, you'll see the option to do it synchronously. Select that and the clock will disappear.
What exactly are the errors that you're getting? One thing to try is to disable termination character detection with VISA Configure Serial Port and use VISA Bytes at Serial Port to determine how many bytes to read. If you have enabled the termination character and specify too many bytes to read, you'll get an error because VISA Read will timeout waiting for the termination character to be detected.

Visa write in Modbus

Dear All,
I am communicating a device on modbus protocol.
i have kept it under observation for 2-3 days.
I am able to communicate it properly til then, but after that 2-3 days time out error comes.
Setup is as follows:
i have connected the labview program on COM5, have used a virtual com port pair software to transfer its data to other port(name is com0com) say on com4.
now this com 4 is connected to the instrument, and also i can observe the number of bytes transmitted and received with the slave.
Till 2-3 days the bytes are transfered and received also, but after that the transmitted bytes doesnt increase, so i debugged in the modbus library of labview,
In MB Serial Transmit vi bytes are also written on the port as the return count (8) is given on visa write vi .
then also the counter for transmitted bytes doesnt increase.
I am not able trace where the exact problem is,
any suggestions..
Regards,
Shrek

Hello,
The only fault I know was in the modbus Slave library regarding coils, however that one has probably been fixed a while ago i guess, and is easy to fix yourself. The master library however works like a charm
If the problem persists, these could be some options?
1 - ignore that virtual com port software and connect directly. If that works long-term you know whats wrong
2 - If that not works, run a little bench test on the equipment. Speed up the communication and see how the instrument behaves. Try writing a lot of holding registers and see the handling of thoes, and the time delay before the instrument answers. Some instruments may react terrible after a while under pressure, and may have some buffer issues, or do not keep up but still acknowledge that the registers have been set, but internally it processes the data afterwards. giving these slower instruments some processing time might solve something. If this crashes before 2-3 days you might know the fault
3 - A work around if still stuck is re-establishing the communication when it times out. If that doesnt work its instrument related as you actually must reset the instrument?
My feeling points towards point 1
Hope this is of any help.

VISA Read Timeout and VISA Write not working

I'm writing a program that sets a triangle wave pattern voltage (using Triangle Wave VI) to a DC power source (GWInstek PST-3202) through a RS-232 connection. I know my instrument parameters are set up correctly because I've been able to control this power source using a different VI with the same parameters. I also know I am connected to the power source because I can talk to it using MAX. I have a string indicator before my VISA Write statement that shows me the command being sent to VISA Write. It shows the correct syntax for setting a voltage on this instrument. However, when I run the VI, the voltage is not changed on my instrument, even though the correct command is sent to the instrument. After the VISA Write operation I have inserted a VISA Read function in order to read the newly set voltage from both a numeric and a waveform indicator. Using the Error Out cluster I am able to see that there is a timeout error from VISA Read. I thought perhaps I needed to clear or flush the buffer after each Read statement, but that didn't work either. I'm stumped as to why VISA Write isn't writing to the device. I have included my VI below, as well as the initialization subVI for the power supply.
Attachments:
Triangle Volt Mod.vi ‏27 KB
GW Instek initialization.vi ‏18 KB

Yep, you need to append the End of Line character to the end of your command. And for your read to work properly, you need to request the data. That requires a querry command to be sent. Look closely at the differences in command and communication structures between your working VI and your mod.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Error output to 'write to spreadsheet'

Hi
I dont know, whether someone talked about this earlier.
But I prefer error output for 'write to spreadsheet file' subvi, as it keep crashing the software with error 5.
I want this,
Thanks
Cube

> that would make people think it works with Excel "spreadsheets".
actually, tab-delimited text files work fine with excel (of course there are some exceptions )
I would rather have this VI removed from the palettes and marked it as deprecated since it does not conform to LV style-guides (no error in/out) any more. I also guess that the pop-up dialog might block other LV threads which will be a serious issue if you have some data logging running. (I can find/build/provide several nice examples where a pop-up VI set to dialog appearance - and also user interaction on GUI elements - can block other loops running in LV)
Thus, I never use the pre-programmed write/read spreadsheet VIs, I always write my own version - usually takes 2-3 LV primitives + a few constants ...
just my 2 cents
-Benjamin
CLA

Array to String (VISA Write)

Hello all, I'm trying to use the function "Triangle Wave.vi" from the Owning Palette "Signal Generation VIs" to output a triangle wave pattern voltage to an external DC power source. My power source is an RS-232 connection, therefore I'm using VISA Write to write the triangle pattern voltages to the power source. The problem is that I have to:
1) Write the voltage to a string input for VISA Write (syntax: :CHAN1:VOLT\s__, where the blank is where the voltage we want to write to the instrument goes). The output for the Triangle Wave VI is an array of doubles. How do I extract each voltage value from the array of DBL?
2) How do I take those single voltage values and write them into a prewritten string? I'm assuming we'll use concatenate strings for part 2.

I appreciate the feedback. I implemented your suggestions, but it still isn't working. I can't figure out why it won't work. When I turn on execution highlighting, the error seems to occur at the actual Triangle Wave VI, because the number it shows as the output from the triangle wave VI is nonsense (although at first I assumed this is because it is outputting an array that hasn't been parsed yet). I added 15 to the output of the Triangle Wave VI which I thought would work, since arrays are polymorphic. However, the number that the program sets to the power supply is 15 over and over again. I am including the (nearly) completed VI.
Attachments:
Triangle Volt Mod.vi ‏19 KB

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

-107380734​3 ERROR NI VISA write in

Similar Messages

Maybe you are looking for

-1073807343 ERROR NI VISA write in