Methods for transferring data from LV Web Service to Application?

[Sam_Sharp]

What methods have people found most useful for transferring data from LabVIEW Web Services and their main application instance? I have a project using LV RT and I'd like to be able to send data to the RT target via HTTP requests.

I found surprisingly little information about different methods available / best practices for this and it's not something I've tried to do before - I mostly use Web Services for hosting static content which uses my WebSockets library.

These are the methods that I know about:

- Shared Variables: The only information from NI I could find about how to do this was to create two shared variables, one for the RT, one for the Web Service and alias them. This seems ridiculous and is only useful for 'tag' data.

- File: Write the data to a file inside the web service and read it out in the application. This would require polling the file/folder for the data.

- TCP/UDP: Write a TCP/UDP handler in the application which listens for incoming connections and then create the connection and send the data inside the web service VI.

- VI Server: I saw a presentation here which talks about using VI Server (slide 8), but when I tried to obtain a named queue inside the VI (using open application instance / open vi reference to the application on port 4000), I get error 1100 (no queue found with that name) from the published web service, it doesn't seem to complain about not being able to connect to the application instance. Running the VI locally or from the debug server works. See the attached project (LV2013) for what I tried.

So, the question is - why doesn't my VI Server method work when it should (according to that presentation, I couldn't find the mentioned examples) and which methods have people used and had success with? I was hoping the last method would prove to be successful as it means I can push the data directly into an existing queue handler, would be a fairly lightweight solution and means I wouldn't need to write a custom file/network handler.

[Sam_Sharp · Accepted solution]

Ok - after more playing - I hadn't wired 'localhost' to the open application instance VI which I thought defaulted to 'localhost' rather than 'this application instance'. I then got the 'VI Server Access is denied' and added * to the exported VIs list and it worked.

Still interested to hear others' methods / thoughts / successes though.

[mgreen]

I have been experimenting with this the last few weeks. I have a real time application running on a cRIO with a web server. What I have done is create a UDP transceiver on both the web server and the RT Application. I was concerned about UDP messages being dropped and switched over to network streams. Specifically, I used the JKI Network Streams available from the package manager. 

I like this implementation, because it stops me from having to poll the server for new data from the RT Application. The network streams also verify the connection and is lossless. 

[Bob_Schor]

I've not used the JKI implementation of Network Streams (didn't even know there was such a "thing"), but I've been using the "native" LabVIEW Network Streams for "Message" passing between Host and Target (one Stream for each direction), with additional Streams for the Target to pass Data Streams back to the Host.  Worked like a charm.  Sounds like the Original Post involved streaming Data Streams (from Web Services) from Host to Target -- just another Network Stream ...

Bob Schor

[mgreen]

Glad this thread is alive again...I'm sure there may be some new thoughts on this topic!

JKI basically made a network stream driver. I'd been building my own network streams class that handles disconnects. JKI has already done it, and it's nice to have it available from the JKI Tools Pallette on the block diagram.

What I gathered was they needed a way to 'push' data from the web server. In my first iterations, I polled the server with a GET request and compared the timestamp of the data stored on the server with my previous GET request.  If the time was later, I parsed the data and disseminated it to my other processes. However, I found this to be a lot of work and a lot of polling the server...especially, if I had more than one host application accessing the server. 

Another useful feature of not polling the server was that whenever a POST was received from the host, I queued that data with a message to be sent over the Network Stream.  When My RT Application saw this message, it could be used to trigger an event if desired.