Method to verify VISA resource is ready for writing.

[neltnerb]

Dear Forum, I have a piece of equipment which I am connecting to LabView via serial. The Instrument Assistant is of course totally useless and fails for inexplicable reasons, but everything works perfectly in hyperterminal.

When I try to adapt the "Basic Serial Write and Read.vi" example to my application, the implementation is very straightforward. However, it fails to work despite working in hyperterminal. After a little bit of investigation, I have determined that the problem is that after "VISA Configure Serial Port" the port is not *actually* available for writing quite yet, most likely because this is a very old computer.

By inserting a delay between the "VISA Configure Serial Port" and the "VISA Write" I am able to get the program to work as expected 100% of the time. However, this is a very bad solution because on an end user's computer (which may be far better than this one) such a long delay may be completely unnecessary and cause poor performance. Particularly because this piece of equipment has 8 analog inputs, 8 analog outputs, 4 Relays, 20 24VDC outputs, 8 DIOs, and 3 passthrough RS232 ports so it will be communicating a lot of data.

Is there a function that I can use to *guarantee* that the COM port is actually ready for writing? If I could do this, then it might return almost immediately on a fast computer, while still allowing plenty of time for slower computers to finish opening the port. It may well be something happening on the windows driver side of the port open command.

This is LabView 8.20 running on a Windows XP in VirtualBox on Linux host server. Please don't just tell me that I should not be using Virtualized Windows, I'm sure this problem happens for people with old hardware as well as that is the only significant difference in terms of serial API. The virtualized instance is just likely to be slower dealing with hardware than it would be otherwise.

[ben64]

I haven't tried but maybe you can use the Find VISA Ressource VI from the VISA Advanced palette to poll the available ressources until the expected one appear in the outputted find list. You can also use the expression input and the return count to filter a specific ressource (look at the help on this function.

Ben64

[Dennis_Knutson]

---

@ben64 wrote:

I haven't tried but maybe you can use the Find VISA Ressource VI from the VISA Advanced palette to poll the available ressources until the expected one appear in the outputted find list. You can also use the expression input and the return count to filter a specific ressource (look at the help on this function.

Ben64

---

That won't work. If the VISA Resource was not available then the VISA Configure Serial Port would fail. And it sounds like the problem is with a delay after configuring the settings. The find resources basically just reads the visaconf.ini file anyway.

I'm not sure there is any way to test the port is ready other than doing a write/read in a loop until you get an expected output.

[neltnerb]

I am trying to write an instrument driver that another person could use without too much work, ideally without being intimately familiar with LabView.

Do you think it would be sensible to an end user to have a VI that "initializes the device" (and does nothing other than run the serial configuration and return the VISA resource) and one that "closes the device" (and does nothing other than VISA close) along with a collection of independent operations which do not include the VISA serial configure or VISA close? I think that would basically solve the problem so long as I build in a second delay after VISA serial configure. Best, Brian

[Dennis_Knutson]

You would be going against the standard, if that matters for you. The standard 'initialize' function sets the com port and then does an optional ID query and an optional reset. The standard close function is exactly like you describe as is the rest of the instrument functions.

[neltnerb]

I would prefer to match standard designs as much as possible. Would the difference simply be adding the ability to return the device ID and reset it? I'm not sure those particular functions exist for my firmware -- if the firmware was broken to the point where it needed a reset I'd probably have to power cycle it as the LabView software doesn't have direct access to the reset lines on the electronics. Or do you mean resetting to some known configuration only?

[Dennis_Knutson · Accepted solution]

You can get information on creating a driver from the Instrument Driver Network.

If your instrument does not return an ID and you cannot do a reset, then obviously your initialize function would not have code for that. Having code that sets the instrument to some default setup is common.

I'm not sure how this driver is going to be used. Do you want it NI certified. Is the driver to be distributed outside your company? It sounds like the problem with your com port is unique to your pc and setup. How often would this show up for other users?

[neltnerb]

Thanks for the link to the Instrument Driver information, that sounds like exactly what I should be using. I will code to that specification as much as possible then. (It's surprisingly hard to find good guidelines for APIs!)

I would like to provide it to other users, so it would be neat to get it NI certified. However, since this is mostly being done for internal use at a new instrumentation startup, I doubt I could afford it. At present I expect 90% of instruments to be installed to operate my own equipment, but if I sell equipment or standalone control boards people might want to have the ability to directly change the behavior of the system.

I imagine that the problem with the com port is unique to my setup, but seems like something worth managing around where possible. I am 99% sure this would never show up if I ported the code to another remotely modern computer.

[neltnerb]

I used this instrument developer tool to make all of my driver, and all of the parts seem to work like a charm now that there is a separate "initialize" VI to handle starting everything. Seems to work very nicely, even integrates into my "Instrument I/O" panel.

Problem now is that none of the Build instructions I can come up with seem to do something sane with the project. It produces install files that contain all the project files and library as specified in the install directory, but because the stuff isn't put into the right labview path it's not found by LabView. This is a pretty stupid problem, so I imagine I'm just missing something obvious.

Surely there is a way to import a library into labview short of an end-user having to manually copy the directory into /Program Files/Labview 8.2/inst.whatever/whatever. That's just not user friendly at all. I will ask though in a new topic as I think my question in this post is now answered. Thanks!

[Yamaeda]

---

@neltnerb wrote:

By inserting a delay between the "VISA Configure Serial Port" and the "VISA Write" I am able to get the program to work as expected 100% of the time. However, this is a very bad solution because on an end user's computer (which may be far better than this one) such a long delay may be completely unnecessary and cause poor performance. Particularly because this piece of equipment has 8 analog inputs, 8 analog outputs, 4 Relays, 20 24VDC outputs, 8 DIOs, and 3 passthrough RS232 ports so it will be communicating a lot of data.

---

This shouldn't be an issue, you open Visa resource and configure it at the start of the program and leave it open until you close the program  when you close the resource. A 100ms delay should be sufficient and only happens once. If you open, configure and close the resource every loop you'll run into lots of strange behaviour.

/Y