Exposing REST API for an instrument driver

[carlod80]

I have developed a .lvlib driver for an instrument, which is interfaced to the control PC through UDP over ethernet connection. Now I would like to develop a RESTful API that allows to control the instrument either on localhost, either on a remote computer via simple HTTP requests. As far as I understand (comments are very welcome!), the way to go is to create a WebService inside the same project of the .lvlib driver, and create the relevant web resources.

The problem I'm facing concerns the UDP connection to the instrument itself: I cannot open a connection to the instrument through an HTTP Request, because as soon as the VI completes execution, the connection ID gets "garbage collected" and becomes invalid. Therefore, I'm thinking of using a Startup VI of the WebService in order to initialize the connection to the instrument when the WebService is started (and close it upon shutdown). In this way, I can keep the connection "alive" inside the main loop of this VI.

And here comes the core of my question: which is the proper way to make the connection ID available to all the HTTP Requests? Initially I was thinking of a Global Variable, but somehow I don't like it. Another way would be a Single Process Shared Variable living inside the .lvlib (which is what I am trying - see below).

I would welcome any suggestions/comments on any of these aspects, and especially my core question. 

This is how I structured my project at the moment:

Notice:

• the MAB driver.lvlib
• the MAB WebService
• the Socket IDs Single Process Shared Variable

[JamesSouv]

Hello,

In your request, you mentioned "Connection ID..."

the connection ID of what do you mean?
Here is a suggestion with a detailed example on how to keep the connection alive:

http://www.ni.com/white-paper/2710/en/

Hope this could help you further in your project.

Kind Regards,

James.

[carlod80]

I mean the connection ID (or LabVIEW refnum) of the UDP connection to the instrument.

Thanks for your link, but I know how to keep a connection alive within a single VI. The problem arises with the HTTP request VIs in the WebService, which naturally terminate at the end of each request.

[Sam_Sharp]

Use the Web Service Startup VI to 'launch' a VI which sits in the background and stays in memory. This VI does the UDP communications to your instrument and the individual HTTP request VIs communicate with that (e.g. via a message queue).

[carlod80]

Thanks Sam, that's a helpful suggestion! So you would use a queue to communicate from the HTTP Request VIs to the Startup VI, but you would also need another queue the other way round to send data from the instrument to the Request VIs, is that what you have in mind?

Just out of curiosity: why do you think the Shared Variable approach is not good? Can you see drawbacks and/or things that can go wrong?

[Sam_Sharp]

It doesn't really matter, whatever works for you. Shared variables can be prone to race conditions.

I would probably use queues for sending commands (since they are lossless) but if you're reading parameters from the device, shared variables might be appropriate for storing them (since you're only interested in the most recent values, plus it allows you to access them externally).