LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using the same VISA-device in several subprograms in the same main program.

I am making a program in which I am planning to use the same VISA device (the serial port) in several subprogram in a kind of sequence (not a sequence structure, but rather a data dependency sequence). Is there some kind of precaution I should take in order to make this work?
0 Kudos
Message 1 of 13
(3,408 Views)
Create one subprogram that handles all calls to the serial port. And have the other subprograms interface that subprogram. In that case only one subprogram has real access to the resource.
Regards,
André (CLA, CLED)
Message 2 of 13
(3,396 Views)

Consider looking at some of the action engine threads.  I use this architecture to protect resources all the time.  Essentially a functional global which will hold the visa session in a shift register and has an enumearted access mode such as initialize read, write, close device reset ...

The functional global will help control access to the device.

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
Message 3 of 13
(3,381 Views)

I have read up on action engines, and as far as I understand it works a bit like object oriented programming. In this case I would be havein the 'object' VISA with the 'methods' VISA.read() and VISA.write(). This seems very nice.

 

What I don't understand is how you actually create an action engine, it seems to be just a loop within a case-structure. How does it know it's an action engine?

0 Kudos
Message 4 of 13
(3,361 Views)

It doesn't have to. "action engine" is just a name someone thought of. The main principle is the use of uninitialised shift registers to store data/references. The first call to the action engine should execute a case with initialisation code, "init" case. E.g. init COM port and store the VISA reference in a shift register. Important is not to wire anything to the shift register outside the while loop, otherwise it will use that value everytime you call the action engine. The next case could be "read" which will read data from the COM port using VISA read.

 

Sidenote: I would suggest to open the COM port, read from and/or  write to it and Close it after each call. Don't keep the VISA session open if usage is incidental.

Message Edited by andre.buurman@carya on 02-06-2009 11:44 AM
Regards,
André (CLA, CLED)
0 Kudos
Message 5 of 13
(3,356 Views)

So what you are telling me is that an action engine is a while loop with an uninitialized shift register, containing a case structure with an initialize case? And which should also in this particular application contain cases for read and write?

 

Reading/writing to the serial port cannot be considered to be incidential, it's more or less the only thing this program is supposed to do.

0 Kudos
Message 6 of 13
(3,347 Views)

Yes, but an initialise case is not mandatory. Only in your case I would call it so.

 

Since its not incidental. Open the COM port once and close when the application finishes.

Regards,
André (CLA, CLED)
0 Kudos
Message 7 of 13
(3,345 Views)
You recommend an initialize case in this application? Would this be the same as an open case?
0 Kudos
Message 8 of 13
(3,342 Views)
Its just the name you want to give it. Use something descriptive for each action and you'll be OK.
Regards,
André (CLA, CLED)
0 Kudos
Message 9 of 13
(3,332 Views)

Tzench wrote:

I have read up on action engines, and as far as I understand it works a bit like object oriented programming. In this case I would be havein the 'object' VISA with the 'methods' VISA.read() and VISA.write(). This seems very nice.

 

What I don't understand is how you actually create an action engine, it seems to be just a loop within a case-structure. How does it know it's an action engine?


If you have not seen it yet you may want to review my Nugget on Action Engines.

 

As in OOP you want to abstract away the details of the widgets you are interfacing with. So I would create actions like Init, Get Update, Write Boolean Output, rather than having actions that focus on the interface. Of course the "Init" case would have a VISA open in your situation but that operation should be abstracted away. By using the "higher level" actions you would theoretically be able to modify your action engine some time the future to use diffent interfaces (DAQ parallel port, a networked machine).

 

If there info that is required to keep track of what is being control (Private data like the VISA ref) keep all of this data inside the AE either in SR's or clusters in SR's.

 

Have fun!

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 10 of 13
(3,321 Views)