CRIO Front Panel Efficiency

[Arnie1]

Hello,

I have an RT application running on a 9014 cRIO. The main VI has an extensive front-panel that was developed to help with testing and debugging. What I would like to know, if someone can help, is:

a.)  When the application is compiled and deployed as a Start-Up application onthe cRIO, does the original front-panel carry any overheads in reducing performance, or are all the front-panel objects stripped-off during compilation and deployment? In which case, is there any disadvantage in leaving the front-panel objects on the VI?

b.) When the application is run from Labview with the front-panel VI diplayed on the connected PC, what is the method of data-transfer between the front-panel diplayed on the PC and the RT code? i see that there is an increase from 18% CPU to about 22% CPU, when the front-panel is active.

Thanks

A.

[Hillman]

Hi A,

Thanks for your post and I hope your well. These are good questions,

a) The user interface (front panel) runs in a seperate (invisable) thread - which will take up processor time and usage. It is recommended to keep front panels to a minimum if not being used. For example, if you have a windows host - this PC should plot a graph - and not the cRIO as well. This is the same princple for the FPGA front panel too. However, during prototyping it is obviously handy to user the front panel of the cRIO VI. 

b)  The best method of communication between the RT and Windows PC, is to rebuild the front panel on the windows Machine - rather than just opening up the RT Front panel - because the communcation is all handed for you - but isnt always effeicent. I would use TCP-IP, in the easiet forum - shared variables to stream data back to the Windows Host PC.

Please let me know what you think,

Kind Regards,

James. 

[RER]

Dear Arnie, 

I absolutely agree with everything Hillman has stated. Furthermore, following Hillmans advice is good programming practice. However, I have an additional couple of snippets of info for you. 

a. When the application is compiled and deployed as a Start-Up application on the cRIO, does the original front-panel carry any overheads in reducing performance?

The code executing on the RT Target does not have a front panel. So could this look at it as "stripping" the front panel controls away.

So essentially, there is no real benefit to removing the FP objects, as no front panel is loaded into memory of the cRIO controller. 

b. The communications method is colloquially referred to as front panel communications. It invisible to the developer, and is very easy to use. It is perfect for prototyping & debugging your RT code - as it still give you access to execution highlighting. 

However, it should not be used as a comms method for your deployed applications. It is processor intensive, and prevents your code working in "real time". As Hillman mentioned, TCP-IP in a low priority loop would be ideal.

Message Edited by RER on 12-04-2008 11:33 AM

[rex1030]

Agreeing with everyone's answer to your first question, opening up the VIs front panel on your PC can really bog down your RT application a lot and should not be used as the method you intend to use to communicate with your application (except for debugging of course). You should look into the example VIs for RT applications. This hostPC - RTsystem architecture where the cRIO is communicating with the PC via shared variables is explained pretty well. You will notice if you use the new project wizard and select RT Application that this architecture is sort of setup already. The example VIs really helped me understand this and it's really important.