Visa error handling in serial communication

Greetings,
I have a problem with the serial communication in my Labview program.
I have made an application that reads from serial port, searches for beggining characters, and later counts data after that beggining characters into variables in Labview program.
Everything work fine, but problem starts when I unplug the device from computer.
Program blocks and I could not do anything. Even Visa Close does not do anything.
I need to restart my computer to make my application works.
I made some indicators in subVi, and I see that when I unplug the device the error from READ VISA changes.
My question is: How to handle this event(error) to restart or unblock my serial device.
I am attaching a SubVi, that searches for starting characters " KBON,"
Best regards,
Chris
Attachments:
find_start.vi ‏12 KB

Hi Chris,
From the standpoint of VISA capabilities, you should be able to programmatically handle the desconection of the serial port. I am however not certain that your specific serial port hardware is OK with that.
As to how to handle disconnection using VISA:
I recommend using the "timeout" pin of the VISA Configure Serial Port VI
when the timeout is reached and no data is transferred, you will get a timeout error on the error wire.
You can then programmatically handle this error case in your code in a very similarly to this example.
I recommend experimenting to see what error codes your application throws, or alternatively you can use the VISA error codes documentation to create the case structures needed to hande these errors.
In all cases, you should close the VISA reference. Leaving the serial port rescource "open" in your operating system may be the reason why you need to restart your computer every time (as restarting will for sure free up the serial port rescource).
Best Regards,
T Simon
National Instruments
Applications Engineer
Certified LabVIEW Developer - Certified TestStand Architect

Similar Messages

Handling multichannel serial communication on FPGA

NI recently released cRIO modules for serial communication on RS232 and RS485/422. We need multiple RS232 channels for our RIO systems and previously the solution would have been to use a serial port server and then communicate with that using raw TCP/IP. Having the serial communication handled by RIO modules seems a bit more elegant though so I'm looking into using the RS232 module NI9870 instead.
NI has supplied an example on how to use the 9870 - a serial loopback on port 0. I've successfully modified this to be a general driver for a selectable port (added port selection and initialization), however I really need to code a solution that handles ALL the 4 channels in parallell. I'm not sure what would be the best way to do that though. DMA FIFOs seem to be the best option for host-target communication, however in this case there are 4 channels....and I may have multiple modules so at most it could be that I need to handle as much as 32 ports. The example uses interrupts for synchronization....which off course is also a limited resource. All in all I'll probably figure out a way to do this, however if anyone else have done something similar already it would be great to hear your views on this.
Coming from the Windows-programming world (this is the first FPGA work I've done) I was also hoping to make this driver as general as possible, maybe even be able to write a wrapper containing both VISA based serial functions and the FPGA host code. That way it could be transparent how the port is accessed.
This would require 1 code that would be able to handle a variety of module configurations (well, 1 to 8 NI9870 modules in the chassis), however that does not seem to be feasible(?). When you read or write to a port you cannot just refer loosely to it with a number e.g. - the read and writes are referenced to a specific port...this means that unlike in a Windows application where you can let the user just configure that he wants to use COM port num XX and the serial functions will accept that number regardless of whether the port exists or not (returning an error if it does not exist or is in use) - the FPGA code has to have all the items it will call pre-defined. If the chassis can have 16 ports on 4 9870 modules it does not seem possible to use the same FPGA code if the chassis currently only has 1 module...Is this the reality, or is it possible to create a more flexible solution?
If it turns out that the FPGA has to be reprogrammed if another serial module is added (or one is removed) it would seem much better to drop the modules and use a port server and tcp/ip instead...that way using new ports will only be a question of configuration (IP and port), not reprogramming...That may not be possible always (if you need the compact size and roughness only a single RIO chassis would offer), but in our case it is - it' just not as elegant hardware-wise.
MTO

Well, the multichannel experiment only wrote data, it did not read...(see attached VIs) however the concept can be used in both directions: Add a header to the FIFO data where the header tells the recipient what port the data is going to or comes from...Then use e.g. a state machine to read the FIFO, split the header and data, and route the data to the loop handling the port.
If you are going to read data you will get into one of the downsides to this namely that you will need to have a central communications manager that reads the incoming data and distributes it to the requesting VI. This way you can have more parallell access to both read and write, however the reads will have to be routed through this handler. How big a performance gain this would give is unknown though. You still only have one DMA FIFO for each direction so there is a limit to how parallell things can get, but logically this might get you closer than the NI example...
MTO
Attachments:
9870 MultichannelIO Experiment.zip ‏1002 KB

I w'd like to know if LabVIEW 6.0 Application Builder includes the daqdrv (for data acquisition) and serpdrv (for serial communication) support files by default.

Building an application to communicate to a device by serial port

Hi velou
The LabVIEW 6i Application Builder no longer requires daqdrv. Regardless of your Application Builder and LabVIEW version, you must always install the appropriate driver files on the target machine. For example, if your application communicates with a DAQ board and a GPIB board, then you must install NI-DAQ and NI-488.2 on your target machine. If you are using the VISA VI's for serial communication, than you have to install NI-VISA . If you are using the "old" serial VI's, than you have to include serpdrv separately.
Luca P.
Regards,
Luca

VISA Read function Read buffer problem in serial communication

Hi, I use VISA write and read function in serial communication app, the device continuously sends 0x00 if it is not receive a request from Labview program running on PC.
And the request sent by labview is programmable. I met a weird problem, each time the request changes, the VISA read buffer output port still shows the last request firstly, from second time, shows the right request.
It works like: Req code: ... 50, 51,51,51,50....; VISA Read buffer: ...50, 50, 51, 51, 51, 51, 50....
Please refer to the program.
Attachments:
readOne_test.vi ‏21 KB

How are you running this? You don't have a while loop around it. Is it part of a larger VI? Please don't tell me you are using the run continuously button.
You don't have any wait statement between you VISA Write and your bytes at port. So it is very likely the receive buffer is still empty since you didn't give your VI time to wait for the device to turn around and give a reply. If you read 0 bytes, your VISA read string will be empty. How does your decoder subVI (which you didn't include) handle an empty string?

Best error handling for visa calls?

We are using some handlers we've devloped for power supply handling (over GPIB). The power supplies are SCPI and use SCPI/GPIB commands. The handlers use the NI visa api's Read() and Write() functions to send the commands. They work fine, for the most part, and we've been using them for a number of years.
However, we're hearing reports that there may have been a few times that commands were not executed on the power supply and our handler did not report back any error.
So, I'm trying to update these handlers to add a little error checking to make them more robust and hopefully we'll catch this error if it happens again.
For error handling, I've come up with 3 solutions and tried all 3. I find some benefits and drawbacks with each and hoped I could get your opinions about error handling as I'm not overly familiar with some of the methods.
Method 1:
Set the Event Status Enable register to catch all events (or all that I care about).
Read status byte (STB?) after each command and check the event bit and then event status bit if event bit set.
Drawback1: I have one power supply that does not implement this correctly and a second type that appears to not be working correctly either.
Drawback2: Errors are generic. I'll know if I got, for example, a DDE (Device Dependant Error), but I won't know more detail than that.
Method 2:
After each command sent, read the error queue with the System:Error? query.
Drawback: It seems I get a lot of messages back in this method that aren't real errors. It's very "noisy" and I have no way to distinguish real errors from "noise" messages like "query interrupted" and such.
Method 3:
Check the return code of the Visa Read() and Write() commands. At first I didn't think this was very robust, but after seeing the list of errors here, I'm beginning to think that these might be more robust and detailed than Method 1. However, I'm not sure.
So is method 3 as robust as it looks, or is there a combination/comprimise I can make, or another method I did not mention which is best to trap errors from Visa Reads/Writes to these GPIB power supplies? Keep in mind that the handlers work for a number of different power supplies and its likely that some things may be implemented differently between supplies....so its best to stick with somethind standard that will work on all power supplies.

Hi KingTermite,
I hope you will got answer of the question and may be implemeted something .It was really a nice discussion .I am also facing the same issue where I am communicating with different instrument using GPIB communication and RS 232 too.
Can you share and discuss about the implementation of your initiative.
Best Regards
Regards:
Vaibhav Kanchan
Sr. Engineer
NI Certified LabVIEW Developer(CLD)
NI Certified TestStand Developer(CTD}

What are the differences between VISA and the old serial calls in regard to device communication?

Recently, I had to communicate with a piece of equipment, (a Yokogawa UM-330 Green Series Digital indicator). The device was configured to communicate using RS-485 protocol. I purchased a RS-485 to RS-232 converter in order to communicate with the device via COM 1 on my PC. When I attempted communication in Max, using VISA read and write commands, I could not get the device to communicate. I even attempted writing a stand-alone VI to establish communication. Still, no-dice. Finally, I resorted to using the old serial call VIs. This made the device jump up and say hello. What I really would like to know is, has anyone experienced problems like this when
attempting to communicate via seral with other devices using VISA, and if they have, what are the reasons for these problems? Is the problem specific to devices using RS-485? Or is the problem more device-specific?

We have been using serial devices for more than ten years (proprietary acquisition cards and third party devices) using a variety of languages (BASIC, CVI, LabView...). I always found that the main problem are correct configuration of the serial port and cabling: once these items are correct, it's easy to obtain some reply from your devices (maybe not so easy to obtain the CORRECT reply or to interpret it...).
I've used both old style VIs (vith LV 5) and VISA with success on the same devices: still I am a little confused about VISA. Maybe would be better some explanatory document by NI about VISA and serial communication.
Anyway, my approach is at present: don't bother about control panel and/or MAX configuration of the port: open the device and configure i
t as you need at the beginning of your application.
Next use simple VISA Write and VISA Read VIs.
Be sure to set the correct timeout: some devices are extremely long in replying (for example: an Infratek wattmeter takes as long as 45 seconds to send measures if you ask to it an harmonic analysis...!).
Proud to use LW/CVI from 3.1 on.
My contributions to the Developer Zone Community
If I have helped you, why not giving me a kudos?

VISA bug with serial communication on MAC !

Hello to you all again,
I have appreciated all feed back from you about a problem encountered with serial communication on the MAC (see earlier questions)
To situate the problem:
One can only read 63 bytes back from the serial port using VISA calls (without handshaking). With the old serial VIs you can read everything back. In addition the exact same VIs do not show this problem on windows platform.
I have now performed extensive tests with a loopback on the serial port and the problem still stand.
I attach two VIs to an answer to this question (for some obscure reason I can not attach them to the question?) which do the basic loopback, one uses VISA the other the old serial VIs. Please try them out o
n your computer (for Mac RS422 miniDIN you should connect pin 3 to 5 and 6 to 8 to do the loopback)(for windows RS232 DB9 connect pin 2 to 3) in loopback configuration (see also resource library).
Please post a message if the described problem also occurs on your MAC.
Thanks to all of you for your cooperation!!

here are the VIs a promised
Attachments:
serial_loopback_test.vi ‏65 KB
visa_loopback_test.vi ‏70 KB

When trying to test my serial port instrument I receive Visa error 1073807346, which means that they is not enough information for Visa to access or resource does not exist.

The error I am getting is on Visa open.

I found couple of knowledge base (KB) entries that talk about Visa error 1073807346. The best way to find knowledge bases (KB) is to goto ni.com >> Support >> Advanced Search (option 3) >> type in the keywords in the box "1073807346", you will get them.
Also refer, http://www.ni.com/support/labview/visa/default.htm. Hope this helps.

Serial communication error

hello,
when i try to run my application(serial communication simple data transfer using loop back), labview evaluaton 8.6 showing the erron as attached.I dont understand what went wrong, it was working fine earlier.
Thanks,
hari
Solved!
Go to Solution.
Attachments:
laberror.JPG ‏85 KB

Is that mean permission from NI? it was working fine, once i terminated the labview application abruptly when not responding since then i have this problem.
hari

Having issues with simple serial communication.

I followed a tutorial online to start learning basic serial communication. The tutorial involved shorting pins 1 and 3 on the Comm 1 port, and writing a simple program (attached). I edited the program a little, to show the varied results that I get when trying to write and read a simple phrase via serial port.
Could someone explain what causes the kind of result shown in "Serial Comm Example.png"? I believe it has to do with timing. Why would only parts of the phrase be transmitted?
Thanks,
Sarah
Solved!
Go to Solution.
Attachments:
Serial Comm Example.vi ‏30 KB
Serial Comm Example.png ‏139 KB

sarahzig wrote:
The tutorial involved shorting pins 1 and 3 on the Comm 1 port
Shouldn't that be pins 2 and 3? On a standard DB-9 serial port, pin 2 is the Recieve and pin 3 is the Transmit.
Now for your code...
1. Move the Configure Serial Port to be before the loop. You only need to configure the port once.
2. Close the port after the loop.
3. Handle your error after the close.
4. Stop your loop on an error or the stop button was pressed. You will need an OR in there.
5. No need for the Flush Buffer function. Remove it.
6. Using the Bytes At Port is a dangerous thing. It introduces all kinds of interesting race conditions. Instead, tell the VISA Read to read the number of bytes you expect to read.
6a. Alternatively, be sure to send an End Of Line character at the end of your sent data and set the number of bytes to read to something a lot more than you would ever expect to read. The VISA Read will stop reading when it a) sees the number of bytes it was told to read, b) sees the termination character (currently enabled and set to a Line Feed, which is part of the End Of Line), or c) the timeout happens. Whichever happens first.
7. With 6, the wait is no longer needed.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions

Report and Alert don't executed in the error handler with a JMS proxy service

Hi,
I'm working with OSB 11.1.1.4.0 and I'm facing a problem with the error handler of my JMS proxy service.
My error handler contains two main elements :
- a Report action
- an Alert with a JMS destination defined
When the business service failed the message remain in the queue. It's the expected behavior.
The problem is :
- the report is missing
- the alert is raised but missing in the JMS destination defined in the Alert setting.
I've noticed if I add a Reply with Failure or Success, Report and Alert are successfully executed.
Unfortunately the message don't remain in the JMS queue.
What can I do in order to have my report/alert done and the JMS transaction rollback in order to keep the message in the queue ?
I've already met this problem in the past with alsb v3 and my solution was to add Service Callout in the error handler in order to externalize these actions.
This solution is not convenient and I hope another solution is possible.

Inventorying workgroups can be difficult, especially when it comes to remote access and network security. Because workgroups are not centrally managed, some of the items discussed in this
wiki article on preparing your workgroup environment may require you to visit each machine individually.
For non-domain credentials, you do not use the <systemname>\<user> format, you simply enter the user name. Regarding how to enter the credentials, if you have an account that uses the same username and password on all machines and is an administrator
on all of those machines, then you can enter that in the All computers credentials page of the wizard. You can also do this if they are different user names. However, if some machines have an account with the same user name, such as Administrator,
but different passwords on each machine, you will need to use the Manually enter computer names discovery method, and then enter the information for each group or each machine.
As you can tell, workgroup environments can quickly negate any benefit that the agentless inventory nature of MAP provides.
Please remember to click "Mark as Answer" on the post that helps you, and to click
"Unmark as Answer" if a marked post does not actually answer your question. Please
VOTE as HELPFUL if the post helps you. This can be beneficial to other community members reading the thread.

Error handling in simulatenous loops

I am trying to design a good error handling system for a project I am working on, but I have run into a "design" problem. I thought it would be good to ask for some guidance here before I sit down and start create the error handling system.
I have more than one subVI started from one mainVI, each subVI with an individual while loop running (they all stop when I press the same stop button from the mainVI). Each while loop continously retrievews information from various serial devices. Each VISA call etc. can thus of course generate errors. I only want one error dialog box in my mainVI front panel displaying any error that happens.
How would I design this in a good way? As I see it, I would have to use the error dialog box in the mainVI as a global/functional global. Each subVI would then write to this global error dialog box. This could however cause race conditions where only the latest error gets displayed even if earlier errors happened. Appreciate some good advice here.
Solved!
Go to Solution.

First and foremost I would avoid using the sequence structure. LabVIEW is a data flow language and you should take advantage of that rather than forcing it to be a sequenctial language. Take a look various examples that ship with LabVIEW. You will want to definitely check out the examples for state machines and the producer consumer architectures. Your current code will not meet your needs of continually monitoring for errors since your "Error" queue is not in a parallel loop task.
I have attached a very quik example of a producer consumer architecture with an error processing loop. There are no real code details but this is a simple example of an approach to take for an application. This along with the above examples should give you a decent starting point.
Message Edited by Mark Yedinak on 10-05-2009 04:05 PM
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
Attachments:
Simple Application Architecture (8-6).vi ‏13 KB

VISA error BFFF003E USB-RS232

Hello, I try to communicate to a HP34401A DMM via RS232. I use a WhiteHeat USB-to-RS232 converter with 4 RS232 connectors. They are known as COM7 to COM10 (in NI-MAX ASRL4 to ASRL7). When I send a Basic I/O "*IDN?\n" I get the right answer but the error 0xBFFF003E occurs immediately. The LabView VISA write.VI also returns this error code. When I use a single USB-to-RS232 converter, everything works fine. Can anybody help me about this error code?

Don't remember the exact error, but I've seen some USB-232 converters return errors when you try to configure certain serial settings. Try checking to see if the VISA Configure Serial is returning an error. Another, perhaps not ideal, solution is just to ignore the error. If the communication is really working properly, there may just be something out of specification which is confusing VISA, you could always just ignore the error (call clear error only if the error code is equal to that error).
Regards,
Ryan K.

User-specified DAQ interruptions, instrument control through serial communication

I'm working on an instrument control program, and I've run into a structural problem that I cannot figure out.
The instrument in question is effectively a thermostat.
The program has two functions:
1.) Background sampling to record temperature in a log over time.
2.) Adjust temperature according to user input
The issue is that the instrument uses EIA-232 serial communication to talk to the PC.
This prohibits simultaneous execution. Attempting to send a command while the program is taking a sample will result in serial blockage errors.
So the program must interrupt background sampling until the specified command has been completed.
I can't figure out how to do this.
My best idea was to create a manual pause control. If the user wants to adjust the temperature, he hits a switch to pause the sampling, sends the appropriate command, then hits the switch again to reinitiate sampling. This method will suffice, but is not ideal.
Beyond that, I really have no idea how to prevent the two functions from running into each other.
Help structuring this program would be greatly appreciated,
Thank you

Look into Semaphores (icons with traffic light glyphs)
Set up a Semaphore resource to the COM port that is wired to two parallel structures.
One structure would do the background polling, the other would handle setting changes.
Prior to background poll, lock the resource, then unlock it after the poll. Likewise for the setting change command.
When a resource is locked, the other process cannot access it until it is unlocked. Be sure to dispose of the Semaphore when ending the program.
-AK2DM
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~
Attachments:
SempahoreExample.jpg ‏256 KB

Teststand error handling Option

Hi all,
I am looking for a way that when a step get error, Sequence will not be terminated but continue to run other steps.
I found no error handle option to fit my need as the below. Value 1 seems to be good but it terminated the sequence. Value 2 sumary test result validate as good which is not useful. is there any way I can change the error handle structure?
RTEOption_Abort–(Value: 3) Instructs the execution to abort the execution.
RTEOption_Continue–(Value: 1) Instructs the execution to process the error by propagating the error to the calling sequence, if one exists. If the current step group is Setup or Main, the execution jumps directly to the Cleanup step group.
RTEOption_Ignore–(Value: 2) Instructs the execution to ignore the error and continue normal execution.
RTEOption_Retry–(Value: 4) Instructs the execution to ignore the error and re-execute the step that caused the error condition. For the StationOptions.RTEOption property, the Execution.RTEOptionForThisExecution property, and the Thread.SetBatchRTEOption method, TestStand interprets the RTEOption_Retry value as RTEOption_Continue.
RTEOption_ShowDialog–(Value: 0) Instructs the execution to launch the Run-Time Error dialog box when an error occurs.
Purpose
Solved!
Go to Solution.

You could use the SequenceFilePostStepRuntimeError callback and handle errors if you need to do something custom.
An example ships with Teststand which will give you some pointers.
http://zone.ni.com/reference/en-XX/help/370052K-01/tssuppref/infotopics/callbacks_sequencefilepostst...
Beginner? Try LabVIEW Basics
Sharing bits of code? Try Snippets or LAVA Code Capture Tool
Have you tried Quick Drop?, Visit QD Community.

Visa error handling in serial communication

Similar Messages

Maybe you are looking for