LabVIEW
Windows based front panel for RT application configuration
The problem here is really that you do not have the same code executing when you do a remote debug session as when you run the RT application standalone. In the first case the code gets compiled with debug settings and all and deployed to the RAM of the realtime device and then started from there, from within the development environment on your host. The executable code is hooked up and connected to a copy of the panel on your host. As you mention this works remarkably well but it has several implications. For one the code as executed on the RT target is anything but running realtime. It's good enough to work in most cases fine, but the whole remote hooking does have impact on the code execution. And that impact can be significant although you often don't notice as the whole idea of such an execution is to debug your code with breakpoints, single stepping, highlight execution and what else, which disturbs the realtime behaviour way beyond what the remote hooking could ever cause on its own. So the realtime behaviour of such an application is certainly less than it could be in a real compiled and installed RT app. The simple fact of having to include the front panels will have already some impact, hooking into this to get all the data transfered to your host an even (much) bigger one. Such an application is definitely less realtime than a fully deployed app, no matter what you do or don't do.
When you deploy the compiled rtexe to the target it gets compiled as a standalone executable with most of these premises removed. It then is copied physically to the storage media on the target and launched from there. Hooking into it after the fact is a lot more complicated and failure sensitive, and for the most part not really possible because most of the debugging code is removed, and the link to the source code on your host completely lost. While it's theoretically possible to allow for a project to hook into a remote executable compiled with enough debug information including diagram and all front panels kept intact, it's also a pretty complicated challenge to present to the user a simple to use experience if anything in this process goes wrong, such as an (even minor) mismatch between your local code and the deployed code. So it is mostly a usability issue. When you debug your code you work in the LabVIEW development environment and expect to be bothered with such issues, but when you develop such an application and let it run by others they do not expect such problems and will throw their hands up in the air if it would happen.
In fact I think it is possible to hook into an rtexe that was compiled with the diagram code intact and debugging enabled, but not from a simple LabVIEW executable but from a project within the deployment environment. But that is hardly the experience you would want to give to an end user, aside from the fact that you need the development environment installed on his computer.
Basically it comes down to the fact that the code to hook into remote apps over the network is part of the LabVIEW development environment and has specifically been exposed through the project framework. There might be a possibility to use that through VI server in your own application but it is almost certainly only executable in the development environment and therefore would require a full LabVIEW installation anyhow. And even if the interface is exposed through public VI server methods it's going to be messy to use in your own application. Most likely a lot messier than implementing your own inter-application message methods.
