Add console to Linux based cRIO

[CyGa]

Hi !

With the linux-based cRIOs the console ("Write To Monitor" ; as intended before working with VxWorks/PharLaps OS) disappeared.

It's only possible to have strings pushed to the RS ports or in a (not managed) file.

As many cRIOs are connected to the network, it would be nice to have the "Write To Monitor" console access through Ethernet port.

The idea would be also to keep the global functionnalities of this console : see the strings in the cRIO webpage (of course), but also keep strings in a managed file (max number of logs in a file, ...) to have a 'buffered' access to strings sent to the console...

In brief, bring us back the 'Console' !! 

[MSTB]

Yes that would be great ! I feel the same frustration about the "disappearance" of that service... :'(

[ScotSalmon]

We've gotten this request a couple of times now, it makes a lot of sense. Can you clarify whether you specifically want the "WIF console" which would make it like VxWorks cRIO's where your options are serial or the web interface? Another option we could look into would be ways to get console messages on an ssh connection. Assuming "all of the above" is not an option (maybe it is, but if you had to pick) would console messages on ssh be better, worse, or equivalent to the WIF console? Are there specific console messages you care more about? It might be easier, for example, to redirect only the RT Debug String "Write to monitor" output, versus showing all console output such as boot messages. Some in-between options exist, for example, redirecting all LV output ("Welcome to LV", LV error messages, etc.).

[CyGa]

Hi ScotSalmon,

I don't care if the console can be seen in a web browser or through a specific client with ssh connection. I just want to see strings that I push with 'Output Debug String (write to moniotr)'.

The best would be to only see 'Output Debug String' strings in a web browser (ease of use, everybody as a browser installed on its computer), and be able to see more messages (such as boot messages, etc...) using a specific client (like Putty for example or any other client).

About security, I guess that it is not necessary to apply SSH encryption to 'Output Debug String', because these are strings I intentionnaly want to output from my cRIO. Or give the option to choose between SSH and 'clear' communication from 'Output Debug String' VI could be a good idea... But this security option is not something I strongly need.

Just to let you know, I made a very simple webpage to create my own webconsole. I push strings through WebSocket (masked data, securized communication through WSS:\\ ) from my cRIO to any computer asking for a connection.

The webpage is 3Ko big and WebSocket allows pushing strings quite fast and very efficently (efficient on cRIO and on computers). So if I made it, I think that a team of professionnal can do it even better and deliver a very useful tool to end-users. 

[JoshuaP]

I really like your usage of WebSockets.  It is a great technology that enables asynchronous communication with very little overhead on the target.

[rolfk]

I would add an option to the DebugOutput function to also send as a syslog message.

[metux]

WS adds a *HUGE* overhead and latency.

The proper protocol for TCP. (which btw is also used for WS).

[JoshuaP]

"WS adds a *HUGE* overhead and latency.

The proper protocol for TCP. (which btw is also used for WS)."

WebSockets only adds a few milliseconds of overhead and has the benefit that you can view the output in a web interface hosted directly from the target.  The additional latency and overhead would be more than acceptable for viewing a simple console.

[metux]

A few ms latency can mean *a lot* for measurement and control (actually, in that case SCTP instead of TCP would be much better).

OTOH, I still haven't found out why WS (which even is incompatible w/ SPY/HTTP2) has been invented in the first place. Just extending CONNECT method for URL endpoints would also have done the job - js scripts then could directly operate on TCP/SCTP sockets (oh, and js still lacks support for binary data) ...

[CyGa]

If you insert your activity monitoring into you control loop, then you should rewrite your code...

On my side a create a specific thread which catches events from my control loop. And then this specific thread is in charge to send the data through websocket. So I don't really care about *HUGE* overhead...

Websockets are easy to use and easy to trap from any client (web browser of others).