Windows based front panel for RT application configuration

[MichaelWestwood]

Hi,

I'm quite new to Realtime and I feel like I am missing something glaringly obvious,

I realise RT devices are intended to run "headless" but the truth is almost any system requires user access to configuration settings at the very least.  When developing the application in the development environment on windows there is a front panel available where one can change settings, see indicators,etc. The complete  communication infrastructure exists to exchange all of this data between the RT system and Labview devel environment. This even works remarkably efficiently when using Vision with two imagers on the RT system. I would expect to be able to automatically build and deploy a windows exe which provides the same functionality, yet it seems the options are either to completely recreate this interface myself using shared variables or some other protocol, or use a web interface which is much slower and less efficient than when developing and also far more finicky to implement in terms of settings, browser plugins,etc. My latest experience is that the html file loads in the browser but there is no front panel (implying the web server is running,etc), its just blank...no error...nothing

Is this really the way it is?

Thanks,

Mike

[Bob_Schor]

Yes, that is the way it is.  RT systems are designed to be "Set It and Forget It" -- they autostart their downloaded code when they are turned on, and away they go.  If you do need to configure them on a per-run basis, you generally develop a Host "front-end" to manage this, as the Host has access to files, keyboards, mice, displays, etc.  When we start our RT system going, it basically waits for the Host to contact it, provide it with Configuration data (including names and number of analog channels, sampling rate, etc), then the Host says "Go", and it goes.  

Bob Schor

[MichaelWestwood]

Hi.

I get that, but as an example with a vision system the tool positions need to be set up and settings changed, possibly fine tuned during production. It may be necessary to add a new configuration setup for a new part to be inspected. This is trivial if there is a machine with labview full development system installed but seems unecessarily time consuming to build an interface to allow this on a production system. All variables must be exchanged between the realtime system and a windows exe. What puzzles me is that this is transparent when developing but that underlying data exchange method is not available to a deployed windows exe.

By contrast when using something like a Cognex Insight camera, this is easily achieved and so the system can be deployed and handed over to the plant engineers to maintain. With RT they would have to have a development license

Mike

[Bob_Schor]

I'm not sure what "camera adjustments" you need to make (on the Windows PC side).  If it is stuff that you can do in LabVIEW directly, then you can create a LabVIEW Executable on the PC and deploy it to any Windows PC.  You might need a Vision Run-Time license for a separate Windows PC (depending on what you are doing with the Camera), but if you can do it all with executables, then you can (in principle) run the Host code from any suitable PC and get it to communicate settings to the RT Target.

Bob Schor

[natasftw]

Just setup a network stream to send messages to the RT from the Host or something similar.

[MichaelWestwood]

I know there are any number of ways of communicating between the RT system and a PC which will allow this, but what frustrates me is that this has been done by NI for use when developing, done better than I would, and apparently very efficiently. It is totally transparent. Why do I have to replicate it?

I feel like I'm losing my mind....that I'm the only person who sees this as obvious omission. 

What am I missing?

In my years of experience of communication between any electronic devices the level of complexity involved in implimenting a reliable protocol suitable for industrial applications is always higher than expected (as I found with my first use of network streams recently). Also the the potential for bugs and the difficulty in debugging increases in the same way. To me the "Just" in the last post sets off alarm bells, I have fallen into that trap many times before and spent days rather than the hours I expected getting it to work. 

Mike 

[jwscs]

do you have a specific question? regarding network streams for example.

[deceased]

I tend to use TCP for this, set up some typedef clusters in the project for the data you need to communicate. Then bundle/unbundle the data out of the TCP comms at the PC and RT.

The best approach really depends on the architecture, you need to ensure that your communications to the PC do not effect the determinism of the RT system.

Deceased

[jwscs]

any specific reason, why you didn't use the network streams?

[MichaelWestwood]

I do have a specfic question:

Why is the communication methoid Labview uses to communicate and provide a remote front panel to a realtime application in the development environment not available to me?