Multi-user acess to cRIO

[BradPID]

Hi,

 

I need advice for architecture design for application where measurement from cRIO could be accesed by multiple user at the same time.

 

My first idea was tu use 'Remote Panel' but:

- GUI is composed of a few dialogs and only one user can control 'Remote Panel' which also means that only one user can launch dialogs on its computer.

-  The customer would like to transform signal to sound and listen to it. It is also unavaliable using Remote Panel

 

The second idea was to use 'Shared Variables' but:

- In order to hear the sound it has to be streamed to the user.

 

Curenet application works for one user using combination of 'Shared Variables' and 'Network Stream'.

 

The last idea is to publish all informations which needs to be published through 'Shared Variable' and implement special mechanism which will create seperate 'Network Stream' for each user who try to connect to cRIO.

 

I am concerned about managing many 'Network Streams' so maybe somebody here have a better idea.

 

Thank you for all responses.

[ShaunR]

Short answer - streaming to multiple clients with TCPIP (aka network streams) from a cRIO is problematic. If you can, use UDP and let the infrastructure "copy" the data (see the Multicast UDP examples).

[odoylerules]

I second Shaun's comment.  I have found that using multiple network streams to connect to different clients becomes extremely CPU dependent for crio's, especially if you need fast updates.   

 

I'm not 100% sure what you mean buy " transform signal to sound ".  I would probably recommend performing this action on the Host computer either way.  I would push the raw data to the host and then do your transformation on the host.  

 

What i would recommend would be to make a single network stream that handles all the "commands" that the host might need to send to the CRIO.  The benefit of this is that you would only be able to have one host connected at a time with this stream.  This also gives you a single point from which to issue commands so you don't have multiple people trying to control the crio at once.

 

As far as sharing data back out to multiple clients, shared variables do work well for this sort of thing.  They have their other downsides but this is probably a good place to start.  I would highly recommend that you only read data using shared variables and not write using them.  All your variables on your host would have their access mode set at "Read" and none as "write.  This once again prevents multiple people from issuing commands at once since you will have multiple clients connecting to the CRIO.

 

One other thing i might recommend is that the if you do use shared variables, that you set the one that give your your "Sound" raw data to be have network buffering.  Since it appears to be the critical component of your system, this should help with disconnects or network issues, to keep your data stream intact.  

 

Hope that helps

[BradPID]

First of all I thank you for all your responses. I had to test a few approaches so it took a while before I could come back to the discussion.

 

It seems that Shared Varaibles are the easiest mechanism to publish data without loosing information. When it comes to broadcasting bufferd data for multpile users Multicast UDP meets my needs. The transmistion is not lossless but the data is only for live listenning and is not logged anywhere. I have to think it over but it is most likely that this is the way how I am going to approach it.

 

The one thing has remained: remote control of a cRIO.

Most of the functionality should be controlled by a one user but there is a one command (signal number selection) which should be avaliable to any user. For sake of simplictly I can agree to not divide it for many classes of user and assume that any user can do everything, even stopping the system. However, I still don't know how to realize.

 

It is easy to think about it when we can use queues. I can imagine that many modules can send commands to the one module through a queue and only recipent module will execute the commands but how to implement the same mechanism throuth the network? I see that I can't have multpile writers endpoints for 'Network Streams'. I am considering using buffered shared variable with string or variant type (if possible). Maybe you have a better ideas which you would like to share with me?

[ShaunR]

The one thing has remained: remote control of a cRIO.

Most of the functionality should be controlled by a one user but there is a one command (signal number selection) which should be avaliable to any user.

 

Not needed for UDP. You just transmit different channels on different ports and let them connect to whichever they want to listen to.

Edited March 4, 2015 by ShaunR

[odoylerules]

If this is really command you feel is safe for anyone to send at anytime to the CRIO, have you considered handling this "message in a separate loop on the crio that maintains some crio state information.  Then you anyone can send the command at any time and if your CRIO is in a state that can process it, then process it, otherwise discard the message or queue it up for a later time.  

 

As far as implementing this i'm not 100% what to tell you.  In all my applications i specifically avoid multiple host that have the ability to send commands.  

 

I'm not sure if a networked buffered shared variable that you can write on multiple host works like you want or not.  Basically a network multi writer queue.  If it does, then it could be a decent route for your application. 

 

If i was going to do something like that i would probably set up a tcp/ip server on my crio and handle all "commands" using that.  It will accept multiple connections from different hosts.  You could then parse messages(commands) from different hosts based on their IP or connection sequence or a multitude of other things.  

 

If you haven't seen it yet, this library may help you out with making a TCP/IP server.  

 

http://www.ni.com/example/27739/en/  

 

I have used it before on a CRIO to handle commands.

[ned]

For multiuser access to an RT system such as a cRIO, I've used straight TCP (no shared variables or network streams). This isn't that much extra work, and gives you full control over the communications. There are lots of possible architectures; here's a brief description of one that I've used. The communication is handled in three separate loops.

The first loop, the simplest, just waits on a listener for new connections. When one arrives, it puts that new connection into a queue, and goes back to waiting.

The second loop handles all the incoming data. It continually loops through all open connections, checking if there's data (a command) on any of them. If there is, it packages that data into a message and puts it into a queue for the main program logic to handle. That message also includes a reference to the TCP connection that sent the command. This loop also dequeues new incoming connections from the first loop, and adds them to the array of active connections. If a connection is closed or inactive for a specified period of time, it removes that connection from the array.

The third loop sends data back to clients. It pulls command responses off a queue, and directs them to the appropriate TCP connection (because the response includes the TCP connection reference that was packaged with the command).

[BradPID]

 

Posted Yesterday, 04:04 PM

The one thing has remained: remote control of a cRIO.

Most of the functionality should be controlled by a one user but there is a one command (signal number selection) which should be avaliable to any user.

 

Not needed for UDP. You just transmit different channels on different ports and let them connect to whichever they want to listen to.

 

I didin't want to broadcast all chanels because of network bandwith. The data which I want to send is about 20k S/s and I assume that each sample has 4B (SGL). if I use about 50 chanels it turns out that I need bandwith of 4MB/s (32Mb/s). I haven't taken into account packets header etc, my calculation are valid estimation only for UDP as TCP has ACK mechanism and need more additional data. It turns out that It is possible to run it on 100Mbps local network but I would like to take so much bandwith. Here are my question: If nobody listens on specific chanel port, does the data  takes network bandwith?  The ideal situation would be if data were transmited only if somebody listen on the specific port. Then, if only on user is connected, it takes only 1/50 of the bandwitch which I have estimated. I don't know the details of the UDP but If what I have written here turns out to be true I think I will go this way.

 

 

When it comes to sending commands to cRIO the soultions with TCP/IP server looks very flexible and for me personally, it looks like the best solution. I have encountered the STM library on Advanced LabVIEW course and that time it was very boring for me. It is not anymore

 

Well, I have to test some approaches...

 

Lets assume that I realy would like to have communication on 'Network Streams' (the customer likes this approach and is familiar with it). Is this communication mechanism prepared to closing and reopening connection? I mean, I tried to run server like application and two client like applications. When I closed one client application it should let me to connect to the server like application from the second client like application. I could not do it and either I do something wrong or it is not prepared for it.

 

[odoylerules]

A tcp/ip server is going to be the most flexible, its just takes more to set up.  

 

If you do go with network streams have you seen this white paper?  

 

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

 

You have to set up your streams correctly otherwise you won't be able to connect.  Also, i believe if you have to shutdown the "server" stream and re-open it if you want to have a new endpoint connect to it.  

[ShaunR]

Here are my question: If nobody listens on specific chanel port, does the data  takes network bandwith?  The ideal situation would be if data were transmited only if somebody listen on the specific port. Then, if only on user is connected, it takes only 1/50 of the bandwitch which I have estimated. I don't know the details of the UDP but If what I have written here turns out to be true I think I will go this way.

Only to the router which hosts the Multi Cast Group. You put a multi cast router in between the source PC and the "real" network then the "real Newtork" doesn't see any traffic unless there is a listener. In this way with your 4MB.sec you can support 0-Network Bandwidth (Gbit?) streams with no variable impact on the cRIO (network determinism).

 

Lets assume that I realy would like to have communication on 'Network Streams' (the customer likes this approach and is familiar with it). Is this communication mechanism prepared to closing and reopening connection? I mean, I tried to run server like application and two client like applications. When I closed one client application it should let me to connect to the server like application from the second client like application. I could not do it and either I do something wrong or it is not prepared for it.

Ah well. If you are going for a full blown server (which is what you need to dynamically handle multiple simultaneous connections with TCPIP) I'll just throw another into the pot then.  How about streaming the audio so they can listen using the HTML5 player in their browsers? (websockets)

Edited March 5, 2015 by ShaunR

[BradPID]

Only to the router which hosts the Multi Cast Group. You put a multi cast router in between the source PC and the "real" network then the "real Newtork" doesn't see any traffic unless there is a listener. In this way with your 4MB.sec you can support 0-Network Bandwidth (Gbit?) streams with no variable impact on the cRIO (network determinism).

Do you mean literaly 'router', the phisical device? As far I understand it I can put router (don't have to be special industrial type) between cRIO and the trafic will be big only between router and cRIO. I have read some about it and I don't want to dwell in it here but it is very interesting. I see a router here as a device which handles dynamic connections. What happens if a computer start listening and disconect (intentionaly)? Will this connection be cleared to not produce traffic anymore?

 

 

Ah well. If you are going for a full blown server (which is what you need to dynamically handle multiple simultaneous connections with TCPIP) I'll just throw another into the pot then.  How about streaming the audio so they can listen using the HTML5 player in their browsers? (websockets)

I see this as a more flexible alternative to the Remote Panel. Probably I will use it someday but this project has a few additional features which I wouldn't like to do in a browser. I will have it in my mind in the next project.

[ShaunR]

Do you mean literaly 'router', the phisical device? As far I understand it I can put router (don't have to be special industrial type) between cRIO and the trafic will be big only between router and cRIO. I have read some about it and I don't want to dwell in it here but it is very interesting. I see a router here as a device which handles dynamic connections. What happens if a computer start listening and disconect (intentionaly)? Will this connection be cleared to not produce traffic anymore?

 

Yes. It really is "fire and forget". All the hard work is handled by the infrastructure and you can even offload any maintenance to the IT department who will probably insist on maintaining it fro you You just need a router that can handle multicast (almost all home routers, for example). Talk with your IT department and they will probably just give you an IP address then go and swap some patch leads in their secret cave.

 

I see this as a more flexible alternative to the Remote Panel. Probably I will use it someday but this project has a few additional features which I wouldn't like to do in a browser. I will have it in my mind in the next project.

Ah. But it is browsers as well as, not instead of . You can do everything with Websockets that you can do with network streams plus browsers and other languages understand it. You can think of it as the general standard for Network Streams rather than NI specific. However, I'm throwing a lot of technologies that are new to you here, so I understand the fallback position to good ol TCPIP.

[BradPID]

Yeah, there is a lot of information here. Now I have to digest and come up with the right solution. Than you all for your help.

[GoGators]

Might I make the suggestion.  For your command/control I have switched to entirely using Web Services.  For streaming of data you can either use the same web service (not really steaming but data on request), or TCP/IP.  I make this suggestion because Web Services offer a lot advantages.  

 

Advantages:  The absolute biggest one for you is connection management.  In multiuser applications where users can drop in and off a network building a multiconnection management TCP engine can be very tedious.  The web service manages ports and keeps user requests and responses organized for you.  Next you get free security if needed.  It has mechanisms for authentication and encryption.  The last big one is crossplatform.  You won't be locked into using LabVIEW on the client side.  Hell you could even test your application from a web browser.

 

Disadvantages:  In my testing you can only do 20 requests/sec.  That is for all users.  For command response that typically is not really a limitation.  For polling data off the cRIO it might be.  The amount of data throughput is actually quite high though.  So you can pump many MB of data though the web service.  The second biggest disadvantage is that the LV examples are atrocious.  We're working on that. In fact my team is working on a side project to make JSON-RPC to work.

[Jon Kokott]

I use websockets to do this.

 

This is the same code I presented at the CLA summit -- without the SSL encryption/authentication server.

 

At the summit I had about 50-75 clients at a given time messaging them all updates at 100 ms (packets were smaller than the TCP frame size, I didn't' really notice any kind of CPU spike at that point on my laptop)

WebSocket.zip

[ShaunR]

In fact my team is working on a side project to make JSON-RPC to work.

Tell me more! JSON-WSP too?

SOA is an area which deserves more limelight.

Edited March 11, 2015 by ShaunR

[GoGators]

Matt Pollock working for NI Sys Eng group did a presentation on JSON RPC in the CLA summit 2 weeks ago.  He showed the beginning of the JSON RPC example.  If we get some more time we can continue to put it together.  Just looked up JSON-WSP.  Essentially SOAP or some other RPC.  That could be cool but would require making an editor for the specification generator.  That could take a while but could be pretty slick.  The nice thing about JSON RPC is pretty simple.

[ShaunR]

Matt Pollock working for NI Sys Eng group did a presentation on JSON RPC in the CLA summit 2 weeks ago.  He showed the beginning of the JSON RPC example.  If we get some more time we can continue to put it together.  Just looked up JSON-WSP.  Essentially SOAP or some other RPC.  That could be cool but would require making an editor for the specification generator.  That could take a while but could be pretty slick.  The nice thing about JSON RPC is pretty simple.

 

That'd be great. I'm not privy to CLA orgies but if you could smuggle out some stuff, I'd be interested in seeing it. I'm looking for a replacement IPC between websocket connected service modules and been experimenting using JSON for that so I'd like to see where your work is heading

Edited March 13, 2015 by ShaunR

[Jon Kokott]

Not CLA restricted:

 

https://decibel.ni.com/content/docs/DOC-38927 

You'll have to be a CLA to get the power point, but thats all that is there, and a link to what I just posted.

Trying again... silly NI redirects....

 

https://decibel.ni.com/content/docs/DOC-38927

[steven88]

Make a single network stream that handles all the "commands" that the host might need to send to the CRIO.