Interaction between Web Service and Main Instance on cRIO target

[hfettig]

I am designing a control system that will run on a cRIO (or sbRIO). The Main Instance will run the control system and communicate with the Host PC, however, there will also be an iPod Touch based user interface that will communicate with the cRIO using a Web Service that is deployed on the cRIO.

Since the Web Service will have to modify some of the data used in the Main Instance I was wondering what the best way of exchanging data between these two application instances would be.

If this were two VIs in the same Application Instance I would use queues and notifiers but is that possible across instances?

I guess I could use network shared variables deployed on the cRIO but I was wondering if there was another method.

[GoGators]

Since the Web Service will have to modify some of the data used in the Main Instance I was wondering what the best way of exchanging data between these two application instances would be.

If this were two VIs in the same Application Instance I would use queues and notifiers but is that possible across instances?

I guess I could use network shared variables deployed on the cRIO but I was wondering if there was another method.

Great post by the way. I was trying to do this exact thing for my application. The way I ended up doing it was to open up a reference to the other application using VI server, then reading and writing to controls and indicators that way. You could also do it using TCP IP to localhost. Both of these are not great solutions, but they did work for me.

Ultimately the problem of WebServices on realtime targets is that it does make sense to have them in their own application instance. A control system does not typically act like a command-respond system. I think the restful server needs to be more tightly integrated with the rtexe, rather than separate. Might make a good idea market.

[hfettig]

The way I have designed my application now my seem a little convoluted but it serves multiple purposes:

• I have a main controller QMH (Queued Message Handler) on the RT, which keeps all the information needed by the control system.
• I have a TCP/IP Server loop which just sits there waiting for connections.
• When it gets a connection it spawns Worker task (another QMH) that takes the TCP data, formats it into the QMH Message type and puts it into the controller queue along with the name of its own queue.
• The controller QMH interprets the message, and puts the response onto the TCP Worker queue, which sends it via TCP/IP back to the client.

This allows for concurrent connections from multiple web services. In addition the TCP/IP interface can also be used to interact with the controller from the host PC. All through one simple interface.

[Rolf Kalbermatter]

Great post by the way. I was trying to do this exact thing for my application. The way I ended up doing it was to open up a reference to the other application using VI server, then reading and writing to controls and indicators that way. You could also do it using TCP IP to localhost. Both of these are not great solutions, but they did work for me.

Ultimately the problem of WebServices on realtime targets is that it does make sense to have them in their own application instance. A control system does not typically act like a command-respond system. I think the restful server needs to be more tightly integrated with the rtexe, rather than separate. Might make a good idea market.

I would feel quite unhappy to have a WebService inside my RT control application. It's advantage of easier communication with other parts of the RT program, seem to me outweighed manifold by the extra complexity that creeps into my RT process. IPC through shared variables or TCP/IP communication (my preference) may not seem so elegant at first but it is really not that complicated to implement, especially if you have created a template of this before

The way I have designed my application now my seem a little convoluted but it serves multiple purposes:

• I have a main controller QMH (Queued Message Handler) on the RT, which keeps all the information needed by the control system.
• I have a TCP/IP Server loop which just sits there waiting for connections.
• When it gets a connection it spawns Worker task (another QMH) that takes the TCP data, formats it into the QMH Message type and puts it into the controller queue along with the name of its own queue.
• The controller QMH interprets the message, and puts the response onto the TCP Worker queue, which sends it via TCP/IP back to the client.

This allows for concurrent connections from multiple web services. In addition the TCP/IP interface can also be used to interact with the controller from the host PC. All through one simple interface.

My RT system design looks a little different in details but quite the same in overall architecture. It originally stems in fact from the need to have an easy communication link to the host for monitoring some or all of the tag based variables. But I have added over time extra means to also communicate with the internal error reporting engine, to start, stop and restart the entire process, to update its tag configuration, and with a simple plugin mechanisme to add extra functionality when needed.

[GoGators]

I would feel quite unhappy to have a WebService inside my RT control application. It's advantage of easier communication with other parts of the RT program, seem to me outweighed manifold by the extra complexity that creeps into my RT process. IPC through shared variables or TCP/IP communication (my preference) may not seem so elegant at first but it is really not that complicated to implement, especially if you have created a template of this before

I guess the bonus of a webservice is it meets RESTful architecture, connection management, security, and a little help meeting internet standards (XML, JSON, etc.) Not being able to debug on RT, and separate application space lowers the advantage of connection management and RESTful (state management).

My RT system design looks a little different in details but quite the same in overall architecture. It originally stems in fact from the need to have an easy communication link to the host for monitoring some or all of the tag based variables. But I have added over time extra means to also communicate with the internal error reporting engine, to start, stop and restart the entire process, to update its tag configuration, and with a simple plugin mechanisme to add extra functionality when needed.

How do you manage your tags? I ask because I have been do a lot of that lately. Originally I got into webservices trying to make the communication layer for my tags a little better, and meet more standards.

[Rolf Kalbermatter]

How do you manage your tags? I ask because I have been do a lot of that lately. Originally I got into webservices trying to make the communication layer for my tags a little better, and meet more standards.

Well I do have a complete tag engine inside my RT app. It is basically a loop that communicates with the rest of the RT system through queues. Two queues for input and output to the IO servers, also a queue for application inputs to writeable tags, a buffer for the current value of all tags based on the internal index and another buffer for an extra calculation engine, that can calculate virtual tag values based on a user defined formula that depends on other tags. All these queues and buffers are so called intelligent global variables, and lots of care has been taken to make sure that as much of the parsing, calculations, preparations and everything is done once in the beginning of starting up the engine, so that CPU load is minimized during normal operation. This resulted in an engine that could easily run 200 tags on the lowest end Compact Fieldpoint controller, as long as the LabVIEW VI Server is not started.

In addition there is a TCP/IP Server that can retrieve and update any tag in the engine as well as update its runtime attributes such as scaling, limits, alarms etc. It also can update the tag configuration and shutdown or restart the entire engine. The tag configuration itself is done in a LabVIEW application on the host machine.

Yes it is a complicated design in some ways and one that has evolved over more than 10 years from a fairly extensive tag based datalogger engine on a desktop machine to a more or less fully fledged SCADA system that can also be deployed to an RT system. The only problem with it is that its components are fairly tightly coupled and I did not always write nice wrappers for the different functionality, so it is quite hard for someone else to go in there and make even smaller changes to it.

If you want to go in such a direction I would actually recommend you to look at the Design patterns NI has released through its System Engineering group. They have some very nice tools that do a lot into this same direction. If I would have to start again from scratch I would probably go with that eventhough not all components are available in LabVIEW source code. But at the time they released that stuff, my system was already developed and running for my needs and it has a few technical advantages and also the fact that I can go in and change whatever strikes my fancy for a new project is in extra bonus.

[GoGators]

If you want to go in such a direction I would actually recommend you to look at the Design patterns NI has released through its System Engineering group. They have some very nice tools that do a lot into this same direction. If I would have to start again from scratch I would probably go with that eventhough not all components are available in LabVIEW source code. But at the time they released that stuff, my system was already developed and running for my needs and it has a few technical advantages and also the fact that I can go in and change whatever strikes my fancy for a new project is in extra bonus.

I work in SE for NI. I was making a webservice based communication for the CVT (was going to call it webCCC), but since I don't think webservices are quite there I am putting it off. I had heard about someone who had done it with variants and variant attributes, and was fishing to see if anyone had posted something like that. Maybe for a different thread.