Serial control with VISA write

Hi,
I'm trying to write a vi that will control a stepper motor that moves a
linear stage, and use a linear transducer (potentiometer) as feedback
to get precise placement of the stage. I'm having difficulty using
VISA write to send commands to the stepper motor. I can use the
HyperTerminal to send commands, for example /2P0R to start the motor
moving. But when I try to get VISA write to write the same command to
the serial port, nothing happens. My code is attached. Can anyone
tell me what I'm doing wrong?
Thanks in advance.
Attachments:
Untitled2.vi ‏27 KB

VISA will indeed throw an error if the COM resource is tied up. But the OP's program does not use any error I/O wiring
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~

Similar Messages

0 bytes at serial port after Visa Write

Hi,
I'm having problems communicating with a Pollux box controlling a stepper motor (both from Micos). The Pollux box has an RS232/485 connection to the computer.
I have tried adaptations of LV's Basic Serial Read and Write example. Even for the basic example there has never been any bytes at the serial port after the write.
I have attached some sample code for LV 10.0.1(64bit) and the OS is Windows Server Enterprise 2008.
The Visa drivers have just been installed.
After some research I have added a 'Set I/O buffer size' as advised by http://digital.ni.com/public.nsf/allkb/60DDFED7EFEFE7188625705700750821?OpenDocument
The time-out is set to 10s, I have a wait of 1s before read and 0.5s between each write (the characters are written individually incase that was the problem).
The write command getaxisno_ should reply with the default axis no which is 1. However, there is never any reply.
The termination character for Venus2 is a space for transmitting commands and ASCII CR LF at the end of received data.
I'm not sure what else could be wrong. According to MAX the device is working properly. Although, when I try to open a Visa test panel in MAX the program crashes. I'm not sure if this is a related problem.
I'd be really grateful for any advice, have been trying to fix this for a few days now.
Thanks in advance!
Ciara
Attachments:
Getaxisno test.vi ‏18 KB

Thanks, I'll search those now.
When I click the test panel button, the Max window disappears and the program is closed. Next time I open it an Unexpected Error box opens with a message saying there was an unexpected error and I should search Info Code MAXKnownException.
'The exception occurred in the NIMax process in the function (Unknown).'
I have searched this and the info advised me to send a report with log files etc to NI which I have done. Just waiting on the reply.
I copied the Visa resource name from MAX and the termination character is the same as what a previous owner of the equipment used in Visual Basic.

Creating a drop down menu configured with VISA write

Hi I'm using the Basic Serial Write Read example vi in LabVIEW to communicate using the serial port. Instead of having a write box on the front panel connected to the VISA Write in the program I want to create a drop down menu on the front panel to be able to choose from a variety of commands. Is there a way I can program multiple commands into the block diagram and choose one of them on the front panel to send to VISA Write? For example, the commands to choose current are I/E\s0\r for 1 A, I/E\s-1\r for 100 mA and so on. I want to be able to choose between 1A, 100mA, etc on the front panel and have the code send the corresponding function to VISA Write. Is this possible?

Okay, please let us know the solution you came up with, so we might be able to use it sometime.
Cameron
To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.
To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):
LabVIEW Unit 1 - Getting Started
Learn to Use LabVIEW with MyDAQ

Using Visa "resource name" control with GPIB example

good morning
I have in my pc two resources of GPIB (Ni-Enet and HP-HPIB card) each one has differet VISA name (ie:GPIB0,GPIB1)
means Ni-Enet is GPIB0 and HP-HPIB card is GPIB1.
I tries to use the example Labview<>GPIB to communicate with GPIB1 but it failes
because the address given (string), to the gpib write object is a string and it recognized only the GPIB0 addresses
i tried to use the "visa resource name" control (used in the example Labview<>Serial)
in the Labview<>GPIB example but it failed. ("visa resource name" shows all resources includes GPIB0 nad GPIB1)
tell me pleae how to use the Labview<>GPIB example to communicate with the equipment addresses used in GPIB1
a bit long , but hope the issue is clear enough..
thanks in advance
Happy new year.
Simon

You can't use that example with an Agilent GPIB board. The GPIB functions are only for NI boards and the NI-GPIB driver. You should be able to convert it to VISA but you'll have to replace the GPIB Writwe/Read with VISA Write/Read as well as changing the GPIB Address String to a VISA Resource Name.

Fluke PM6304 controlled with LabView via RS232

Hi,
we're going to control our Fluke RCL Meter with Lab View via RS232.
Does anyone has experience and show sample code?
I failed already to make a terminal connection between my PC and the PM6304
Thanks for comments, maximint.

Okay, here goes. Once upon a time there was just serial and gpib. Each used completely different hardware,protocols, etc. and there were separate drivers for each. Years ago, a new instrument type was introduced. Based on a VME backplane, these were instruments on a card called VXI (VME with instrument extensions). So, a whole new low level driver was required. The makers of VXI, realizing that the first VXI instruments were the same as their GPIB instruments without a display or power supply, thought that it would be nice if the software that had been developed for the GPIB instruments could also be used for the VXI version. Several vendors, including NI, came up with something called VISA (Virtual Instrument Software Architecture). This was an API that united GPIB and VXI. If you wrote an instrument driver with VISA Writes and VISA Reads, it would work with either type of instrument. The VISA driver itself would determine the actual type of bus and handle all of the low level details. One of the goals of all these vendors was to also make it easy for users to change from GPIB to VXI instruments. While this didn't really happen, the idea of VISA caught on and became very popular and sort of a standard in many places. Eventually, other common forms of instrument busses were added to VISA. Among those are serial, ethernet, usb, pxi. All of the instrument drivers written by NI now use VISA.
I downloaded the driver for the instrument you need and had a look at it. It really doesn't have much, it's very old, and uses the GPIB functions (not VISA). Since there were so few functions, I went ahead and replaced the GPIB Reads and Writes with VISA Reads and Writes. That will give you a start. You will also need to add some code to initialize the serial port. A great place to look to see how this is done is with an example that has shipped with LabVEIW for years. The HP34401 DMM driver that is on the instrument driver palette is a VISA driver with special support for serial. All of the serial setup is done in the initialize subVI. The type of interface is determined and if serial, baud rate, parity, etc. are setup. Another important setting is a termination character. Serial instruments usually require a CR or LF at the end of each command. You will need to determine what your instrument requires.
Attachments:
flpm6304.llb ‏141 KB

Make visa write return sooner

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

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

Labview USB with VISA on Mac OS X

Hi-
I have a 3rd party USB DAQ device that I'm trying to make work within labview 7.0. I've gone through the device tutorial on creating a driver with Windows2000. With Windows 2000 after using the VISA driver wizard the subvi "visa find resources" finds the DAQ device and I can talk to it
with a bulk transfer with VISA write.
With a Mac OS X (10.4), the system profiler sees the DAQ but I the VISA driver wizard won't allow me to check the usb button. The labview subvi "visa find resources" doesn't find the
DAQ. What equilivent steps do I need to do with OSX so that the find resources vi finds my DAQ?

Finally fixed the PermGen errors. I can run all day now without crashing. It turns out the eclipse.ini file is very tricky! You have to have carriage returns in the right places. Run the jmap -heap <pid> on the eclipse process id. It will tell you if your PermGen memory is actually setup how you thought it was supposed to be.
Here's my final eclipse.ini
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
892m
-vmargs
-XX:PermSize=128m
-XX:MaxPermSize=892m
-Dapple.awt.graphics.UseQuartz=true
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx892m

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

Control Camera Attibutes through serial port using VISA commands

Hi there,
I'm using a Basler acA2000-340kc camera through an PCIe-1473R FPGA as frame grabber.
I would like to be able to configure the camera through the serial port just in LabView, not using a third-party as Pylon (which I can do now).
According to this forum post
http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/My-Basler-acA2040-180km-NIR-is-not-visible-in...
this is possible just taking the VI posted here
https://decibel.ni.com/content/docs/DOC-5049
and converting from IMAQ to VISA, as RIO frame grabbers cannot use IMAQ. I have been trying to do this by changing the IMAQ vi to their VISA equivalents, but I have no good results.
Does anyone know which are the steps to go from that piece of code to one that can be used to control the camera in my case?
Thanks a lot,

Hi i.popa,
Basler makes the Basler Binary Protocol Library for serial communication with their cameras. If you make sure you're running the serial server section of your FPGA code to keep the serial port open, you should be able to use calls from this library to communicate with your camera. We have a community example with more information on using the Call Library Function Node to call a DLL. This DLL will take care of all the processes needed to write from and read to the registry, so this implementation will probably be similar to the example program you listed above, using calls to this library instead of the IMAQ Serial functions.
Good luck with your application!
Emily C
Applications Engineer
National Instruments

Sync write with Visa 2.6/LabVIEW 6i

I setup a vi with 2 parallel paths; one sends 100 bytes at 300 baud to COM 2, and the other 100 bytes at 9600 baud on COM 3. The path for 9600 baud should complete before the 300 baud path, but no matter what setting I select for VISA write (sync/async), the 2 paths will not run separately.
What am I doing wrong?

LabVIEW-man:
You're not doing anything wrong, at least not based on what you've said here. Asynchronous Serial VISA writes aren't really completely implemented in NI-VISA 2.x but we're working on a better implementation for our next version (NI-VISA 3.0). Fortunately, there are a couple of possible solutions (workarounds) for you in the meantime.
1) Put each VISA Serial write in a separate VI in a separate LV execution system. You can set this in the VI properties. LV will then call each VISA Serial write from a different thread. This is not the most elegant solution because it requires you to redo parts of your code.
2) Assuming this is Win32, go into MAX and choose Tools>>NI-VISA>>VISA Options. Change the Minimum Async Transfer field from 102
4 (the default) to something lower like 64. NI-VISA will then perform the Serial writes in separate threads even though LabVIEW makes all VISA calls to viWriteAsync from the same thread.
Regardless of your platform, you should probably call VISA Set Buffer Size with mask 32 (I/O output buffer) and set it to a non-zero value. The default is 0, which tells VISA to not return from a VISA Write (sync or async) until all data bytes have been sent from the OS to the UART. In this way it is equivalent to other buses (such as GPIB) and if you are doing a query then you can immediately start your VISA Read operation. If you set the output buffer to a non-zero value (the exact value really isn't important because most OS's ignore it), then VISA will let its Serial write operations potentially return sooner. You should then call VISA Flush Buffer with mask 32 to guarantee that the data has been sent. This last part will likely *not* change in 3.0 because most users prefer knowing that th
e data has been completely sent.
Hope this helps,
Dan Mondrik
Senior Software Engineer, NI-VISA
National Instruments

Serial port: from 6i without visa to 7express with visa ?????

upgrading from NT4 6i max 2.5 to 2000 7exp max3.1 my pzt on PC serial port do not move anymore. The DA converter do not understand the instructions.
Running max on the coms: done OK
Looping back the visa instructions: done instructions OK
Trying hyperterminal: done OK (the DAC move)
the coms are in function but the DAC do not move while driving with visa...any suggestion??

I also upgraded from LV6.1 to LV7 and use serial communication. I now use VISA (and prefer it). However, for the older functions.. they should work..
Have you looked into the VISA Advanced controls under Interface Specific and under "Serial". You may find the functions you need to "upgrade" your serial comm vi's.
-JLV-

Static VI with Visa serial functions is very slow to display front panel

THere is a delay time of about 10-20 seconds to "display" the first VI's front panel that has Visa serial functions in the source code.
All works fine after the first load but the initial delay of the front panel load makes it look like the PC could hang during this time. AFter this other VI's load immediately with no delay. I am concerned because I do not want to have to load a VI manually every time I start the APP which is the only workaround I can do at this time.
Im wondering if anyone else has seen this kind of behaviour.
I do not remember this happening until I upgraded my APP to LV7.
DEll optiplex GX260 with 500MB RAM, Win2k and using N.I PCI-232-16 card w/ LV7 now.
Attachments:
RECV_LOOP.vi ‏55 KB

I would like to resurrect this thread, as I am having the same problem. The problem stems from the VISA resource control on my front panel, because I have many COM ports registered on my system. The last suggestion from Scott B. was to "post the resulting .SPY file and I'll take a look at it". So, here is my .SPY file, and as you can see, it takes far too long. As many of these COM ports were registerd from USB converters, most of them are not actually present at this time on the system. However, even the ports that ARE present take a long time to register (i.e. COM1 is present and shows 3 seconds to register). These COM ports shown in my VISA resource do not correspond to those shown in my Device Manager, nor do they correspond to those shown in MAX under Devices and Interfaces.
I am using LV 7.0 on WinXP SP2, with VISA version 3.2.
OK, I just discovered something that mostly cured the delay. When I was getting the VISA version number just now, from MAX in the Software>NI-VISA item, there is a tab "VISA Options", and another tree structure in the middle pane. Selecting "General Settings>Aliases", there was a list of the old COM ports, so I cleared this list and then re-started MAX, checked again, and now only the COM ports shown in "Devices and Interfaces" matched this list (which still doesn't match my Device Manager, but no matter). When I re-opened the LabVIEW FP, it opened quickly, and the ports listed in the VISA resource matched those I saw in MAX.
At any rate, although I just cured the symptom, the original problem of old aliases in VISA causing unacceptable delay should be fixed by NI.
David Moerman
TruView Technology Integration Ltd.
P.S. the message poster didn't allow my to post a *.spy extension, so here is the *.zip of it.
Attachments:
Capture.zip ‏2 KB

GPIB reads/writes compared with VISA reads/writes

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

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

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

Problem on WinXP / Labview 6.1 with VISA (serial port)

There is a problem on WinXP / Labview 6.1 with VISA which i use to poll the state lines of the serial port. The only functions that i use are "VISA Open", "Find Resource", line state properties and "VISA close".
On my own machine (WinME) it works fine as a standalone application (with runtime engine in the same direction), even if i rename the Labview directory so that Labview is not found.
From my VXIpnp directory i deleted all but these files:
directory "Win95",
subdirectory "Bin" containing "NiViAsrl.dll",
subdirectory "NIvisa" containing "visaconf.dll".
When shipping this to WinXP (and copying "VXIpnp" to the root directory), the serial port was not found, so i renamed the direction "Win95" to "
WinNT", but this did not work also.
I installed the VISA server, although it seems not to be required -- no result.
Final question:
What must i do for distributing the program as a standalone application for all windows platforms?

Hey Joachim,
In order to create an installer that includes the VISA Run-time engine for serial IO you will have to purchase LabVIEW 7.x. See screen shot. This packages a small compact version of the run-time that can only be used for serial, but it takes up much less space. The installer that I created has my application, the LV Run-time, and the VISA run-time and it is about 26 MB.
That is much smaller than if I had to include the 32 MB LV 7.1 run-time and the 14 MB VISA run-time separately. It would have been even smaller if I would have uncheck some of the items that I wasn't using.
-Josh
Attachments:
advanced.JPG ‏31 KB

Serial control with VISA write

Similar Messages

Maybe you are looking for