VI laggy

[jmcall10]

Hi, I am rather new to LabView however having fun trying new things.

I recently worked on a mcb2300 board and found that the VI was laggy.

For example if I had a dial on the VI then anytime I went to change the dial value, it would lag or jump around slightly.

Has anyone came across this and if so is it native due to communication between labview and the hardware? or is there something I am missing that I could use to sort this.

Regards,

jmcall10

[SteveChandler]

You should check for and respond to user input in a tight loop and send commands to a processig loop. Typically the UI loop will be an event structure that sends information to another loop such as a hardware loop that might be slow. This keeps the UI responsive. A "laggy" UI is an indication that the event structure is doing too much.

[jmcall10]

Ok what u are saying makes perfect sense but not sure how to address it. Basically my whole program is on one while loop. How would i incorporate ur suggestion?

Regards,

Jmcall10

[SteveChandler]

Look for "Producer Consumer" design pattern here on the forums. There is an example that ships with LabVIEW. File/New/From Template/Frameworks/Design Patterns/Producer Consumer Design Pattern(Events)

Basically it does just what I was saying. There are at least two loops. One processes user events and sends commands to a consumer loop which does the heavy processing.

[jmcall10]

Excellent! I shall have a look over next few days. I shall see if i can get it to work accordingly.

Thanks a lot.

Jmcall10

[altenbach]

You get laggy UI responses if you do one or more of the following:

• Have polling loops without any small wait statements
• Set the toplevel VI to one of the higher priorities (high priorities will starve the UI in favor of processing)
• Run any drivers in the UI thread.
• etc.

Also have a look at the links in my reply here.

Open the task manager. What is the typical CPU use when you run the program?

Is it pegged at 100%? Does the memory increase constantly?

Since you are new with LabVIEW, it might be beneficial if you could show us your code.

[Yamaeda]

This is a very common problem in the beginning if you do a polling loop without wait. CPU will spin at 100% and everything will be slow. You dont need to check your controls 4 billion times a second. 😉

This is what's called starving. Is that what's happening?

/Y

[SteveChandler]

---

@jmcall10 wrote:
Excellent! I shall have a look over next few days. I shall see if i can get it to work accordingly.

Thanks a lot.

Jmcall10

---

First of all I made the assumption that you had an event structure which may not be true at all. Secondly I said "tight loop" with a misconception of what that means.

To me it meant that you have a loop doing very little or doing one specific thing (like containing an event structure). But a tight loop is not a good thing at all. It means the same thing as a "greedy loop" which can only be described as Bart Simpson repeatedly asking "Are we there yet?" "Are we there yet?"....

It is definitely a more likely possibility that you do have a tight loop than an event structure. What I was getting at is that if you use an event structure then everything is completely blocked until the code in the event case has completed. You cannot interact with the front panel. If you are communicating with hardware in the event structure and the hardware takes a long time to respond you will see laggy behavior. That can be turned off by deselecting "Defer Front Panel Updates" but if you ever find yourself doing that then you are probably doing something wrong.