Slow Response from Embedded GUI

[erikdebest]

Good morning everyone,

this is my second post in this forum.

We are using 2 cRIO9035 with active embedded GUI at our client's site. The monitor is a 17" touchscreen connected to cRIO with the display port cable and mouse function for the touch. On the cRIO with the heavier software we are getting a slow response from the GUI: operator clicks something and it may take up to 2 seconds for the GUI to react, while on the other cRIO the reaction is instant. I have been monitoring the CPUs during normal operation of the machine: CPU 1 is at about 30% max, CPU 2 at about 10% (max).

I played with the cRIO and observed that "redrawing" the GUIs front panel consumes a lot of resources - conversely, when no updates are made the CPU load drops to single digit values.

I contacted the local NI office and we are dealing with it, but I thought it would be nice to have your input as well.

Some info:

- NI support told me that "redraw front panel" is the least important task within the cRIO. I understand that it should be less important than for example a timed loop, but I do also have other functionality in the software that is less important than a fast working GUI (less important tasks are, for example, sending data over TCP to a Windows to be logged in a Database),

- NI Support told me that after each write to an indicator or property node triggers a "redraw front panel". In some cases, I do have a complex GUI, a user event does indeed write to maybe 15 property nodes (properties like "visible", "enabled").

Suggestion by NI is to employ the "defer panel update" so that all values/property nodes are written before doing a redraw. I will implement it by the end of this week and I am hopeful that it will reduce the CPU load and by that improve the reaction time.

So, it is good to optimize code for reduced CPU and memory usage, but in the NI Embedded course I learned that NI recommends keeping CPU usage below 70%. I do think however, that with this 70% figure the GUI will be unusable.

So, the questions are:

- will I have to limit my CPU load to achieve a fast response from the GUI?

- are there ways to prioritize the Panel update (I have never seen a timed loop combined with the event structure, and it doesn't look right to do that)?

many thanks and best regards,
Erik

[MrJackHamilton]

Erik,

One thing to check is how many FP control and indicator references employed in the code, because there should be not more than about 3!. Tab controls, seem to noticably slow down the cRIO screens, in my experience.

This may seem a trivial thing, but I've seen every LabVIEW programmer go wild using control references once they discover how *neat* they are...Using control ref's and passing them down into the bowels of the code will bog down even a i5 Windows box.The reasons are complex and have a connection to FP graphical update, and 'entangling' your low-level routines with FP updates.

I don't run into these problems, and do a lot of cRIO code with nice GUI's. Don't I don't use control references...stay away from them.

Also, the CPU load is absolutely CRITICAL to watch as you develop and deploy your code!. Shame on NI for NOT MAKING THIS THIS DEFAULT POP-UP DISPLAY on all RT development. You HAVE to monitor the CPU load as you add tasks to your program. You're NOT programming on a i7 core with lots of memory and forgiveness. Embedded systems are limited in memory and processing power - if you run out of either - your applicaiton will hang or crash. You've got to write your code very lean - use shift registers and other mechanisms that re-used memory explicitly.

Regards

Jack Hamilton

[erikdebest]

Hi Jack, 

many thanks for your reply! - took me a while to see it though (no automatic messaging...)

Yes, I am trying to keep the GUI as simple as possible. I reprogrammed the code so it does less GUI updates: the CPU load went down and it reacts faster!

Cheers, 
Erik