Visa write problem

hello,
I am trying to control a Coherent Cube laser with labview 8.0 (RS232)
I always get the response 'invalid cmd' from the laser.
There is a software furnished by Coherent which works without any problem.
I monitored the datas sent by this software and labview through the serial port but I did not notice any difference.
Have you got an idea? (the baud rates is well configured)

Hi,
So your query works but your command doesn't, is this correct?
(Query being the string which starts with ? eg "?S". Command being "Command=<value>" eg CW=1)
If this is correct then you haven't got a problem with your Write because the Query has to seed the "?..." charaters before you can perform the Read.
Therefore the problem is on the exact syntax of the command string. There can't be any spaces between the command, the = and the <value> ie CW=1 not CW = 1.0.
Hope this helps
Regards
Ray Farmer
Regards
Ray Farmer

Similar Messages

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.

How can i write a sign string in VISA Write?

Hello everybody.
I would like someone to help me. I have an
array, which is transformed (by Byte Array to String) in a string that
reaches the VISA Write Serial Port. My problem is that when making the
transformation with Byte Array to String, i lose all the bytes with sign
(negative).
What can I do? I don't want to lose the sign bytes and be able to send them to VISA Write Serial Port.
Thank you very much.

It sounds like you have a typecasting problem. First, why do some of your bytes have a sign? I assume they are I8. Strings are based on U8 because they are just a series of ASCII characters vs. values. The ASCII character table goes from 0 to 255.
What happens on the other end of the VISA communication string?
One thing you could do is to typecast your bytes to a U8. Though I think the coercion dot of an I8 byte array going into the byte array to string is doing this automatically.

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 Write go slow

I have a LabVIEW program which uses a duplicate session to write stuff to an Arduino and read stuff from an Arduino. After running for some time, occasionally some of the VIs "freeze". This was on an executable so I haven't investigated what's going on there.
I put an EZ Tap Pro snooper on the Tx and Rx in the Arduino and found that the characters were being written with a delay between characters. The Arduino reply is quick as normal.
I am struggling to see how the VISAWrite can decide to go slow. The Visa session is set to have no handshaking. To me the whole string should be written into the PC write buffer and the UART should spit the thing out the serial port with no delays. The PC is connected to the Arduino via USB but as far ask I know the PC thinks it's like a serial port.
Can there be anything in VISA Write which drip feeds characters to the UART?
This is early days in solving the problem. The software runs well for hours and hours without crashing
Thanks for any clues

pgaastra wrote:
I have a LabVIEW program which uses a duplicate session to write stuff to an Arduino and read stuff from an Arduino. After running for some time, occasionally some of the VIs "freeze". This was on an executable so I haven't investigated what's going on there.
I put an EZ Tap Pro snooper on the Tx and Rx in the Arduino and found that the characters were being written with a delay between characters. The Arduino reply is quick as normal.
I am struggling to see how the VISAWrite can decide to go slow. The Visa session is set to have no handshaking. To me the whole string should be written into the PC write buffer and the UART should spit the thing out the serial port with no delays. The PC is connected to the Arduino via USB but as far ask I know the PC thinks it's like a serial port.
Can there be anything in VISA Write which drip feeds characters to the UART?
This is early days in solving the problem. The software runs well for hours and hours without crashing
Thanks for any clues
clues?
how about posting your VI ?

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

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

Erreur de timeout sur Visa Write

Bonjour,
Je suis étudiant en énergétique 4e année et je réalise dans le cadre d'un stage une méthode de mesure de débit à travers une porte à l'aide de capteurs à fil chaud et de deux autres types de capteurs.
J'utilise dans labview un programme dont le visuel+fichier est en pièce jointe.
Sur le principe, le programme (assez complexe car le signal est traité par la suite) fonctionne de la manière suivante : j'utilise pour acquérir les signaux donnés par le multimètre agilent 34970A trois ensembles "visa write puis visa read" pour l'acquisition successive de signaux de tension, d'intensité, puis de tension (3 types de capteurs différents) avec timeout de 20 seconde, le tout dans une boucle while pour des acquisitions de plusieurs centaines de points, avec une série de valeurs toute les 5 secondes.
Aléatoirement, au bout d'un certain nombre de réalisation de la boucle (non régulier, parfois 1H, parfois 10 minutes, parfois 6h), la boucle s'arrête, et j'obtiens l'erreur suivante :
L'erreur -1073807339 s'est produite à : VISA Read dans VitesseTemperatureRTDDirection2-essais10bon_moymobil.vi
VISA: (Hex 0xBFFF0015) Le délai d'attente (timeout) a expiré avant que l'opération ne soit achevée.
Pourtant, le temps de réponse de mes capteur est inférieur à la seconde. ce sont des capteurs à fil chaud
Je pense qu'il peut subsister un problème dans mon programme labview sur la méthode d'acquisition de ce multimètre. L'erreur peut également venir du multimètre ou des capteurs (faux contact)
J'ai essayé d'être le plus claire possible, néanmoins n'hésitez pas à demander des explications
Merci d'avance pour vos précieuses réponses
Attachments:
VitesseTemperatureRTDDirection2- essais10bon_optimize_avecsigne050510.vi ‏155 KB
erreurprogramme.jpg ‏164 KB

Pourquoi vous employez le "Read" dans la premiere commande de VISA, et "Init-Fetc" dans le prochain VISA? Essai utilisant le "Read" tout pars tout. Si ceci ne fixe pas le probleme, changez du "XON-XOFF" au aucun handshaking. Temps au temps, les "binary bits" (je ne savez pas les mots en Francais) resemble XOFF. J'espere que ceci vous aide.
- tbob
Inventor of the WORM Global

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

TCP Write Problem Sending "FF"

Hello people! I'm having a weird problem with TCP Write on sending "FF" (hex). I will explain some tests I have already done and I hope you guys can help me somehow.
My whole system is something like this:
[PC 1] --- [MUX/DMX nº1] --- [RF Transmission] --- [MUX/DMX nº2] --- [Serial/Ethernet Converter] --- [Switch] --- [PC 2]
My objective is to send a message from [PC 2] to [PC 1]. In [PC 2] I use TCP Write and in [PC 1] I use Visa Read.
When I send anything that doesn't contain "FF" from [PC 2], the [PC 1] receives everything correctly. For example, if I send "12345678" from [PC 2], the [PC 1] will receive "12345678".
However, when I send a single "FF", the [PC 1] stops receiving from [PC 2]. Being more accurate, it's [PC 2] that stops to send data. If I send "1234FF5678" from [PC 2], the [PC 1] only receives "1234". Then the [PC 2] stops sending any kind of data and it will only send again if I restart the software. [PC 1] continues to receive data from [PC 2] after this restart. If I send "FF" again, [PC 2] stops once more to send data.
I also tried the other way. [PC 1] used Visa Write and [PC 2] used TCP Read. It worked correctly even sending "FF". I started to think that the problem was in TCP Write.
Then I tried the following scheme: [PC 1] --- [Switch] --- [PC 2]
[PC 1] used TCP Read and [PC 2] used TCP Write. I used LabVIEW's example of TPC Active and Passive and it worked correctly to send "FF". I got more confused.
Then I tried: [PC 1] --- [Serial/Ethernet Converter] --- [Switch] --- [PC 2]
It occurred the same problem as before. [PC 2] sent correctly to [PC 1] every data that didn't contain "FF". When I sent "1234FF5678", [PC 1] only received "1234" and [PC 2] stopped to send data.
Well... now I'm out of ideas of tests. I think the problem is with TCP Write or with my serial/ethernet converter. Do you guys have any sugestion or solution?
Thank you very much. Best regards,
Solved!
Go to Solution.

Yahoou! Finally found the problem. The problem was inside serial/ethernet converter. It had an option "Use NVT (RFC2217)". I searched over the internet and found that "FF" for this kind of protocol has a meaning and probably it was affecting my message.
I disabled it and then I was able to send "FF" (hex) without any trouble!
Thanks for your attention. Best regards,

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

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

Why does visa write hang with Labview 2009 instrument drivers.

I'm having an issue with a code package that I'm running. The pacakge is very complex and was written by someone other than me. It runs fine while using the labview 8.5 drivers, however, when the 2009 instrument drivers are install there is a visa write call to an instrument where the software will hang up at the VISA write VI. I tried setting the timeout attribute but that makes no difference. I would expect that if the visa write did not work, that it would time out with an error instead of hanging up.
Some additional information. The instrument is an EPM which is on a GPIB bus with other instruments. When I place the EPM2000 on a serparate bus this problem goes away, but I want to be able to operate on the same GPIB bus.
Has anyone experienced a similar problem? What can I try to help troubleshoot the problem. I tried opening NI Spy but that shows no activity going on.

Hi Steve,
My apologies, when you said instrument drivers I assumed you were refering to the individual drivers for your instrument. Were you refering to the VISA drivers? If so, the latest version of these is 5.1.1 which can be downloaded here: http://joule.ni.com/nidu/cds/view/p/id/2659/lang/en.
Also are you able to communicate with this device using the test panels in Measurement & Automation Explorer? There is also a tool called NI IO Trace (or it may still be called NI-SPY in 2009) that can be opened from MAX that monitors all GPIB commands sent and received on the machine. Getting a log of the commands when the hang occurs may help to diagnose it.
It is possible this issue could be caused by opening and closing the VISA reference frequently in the code such as in a loop iteration. Is this is case in your code?
Justin D
Applications Engineer
National Instruments
http://www.ni.com/support/

Visa write problem

Similar Messages

Maybe you are looking for