slide bars slow EVERYTHING, I dont understand!!!!!

[aias]

Well, I will post my rediculous code then... Let us see if we can investigate it further,. To be honest I'm just a newbie in Labview, but I like to solder some things )

[Mark_Yedinak]

I haven't looked at the code however I did want to mention that it is a good practice to separate the user interface from the processing code. This can be accomplished in various different ways and it is not immediately obvious to new LabVIEW programmers. However this is one way to begin to isolate performance issues as well as provide the ability to utilize parallel processing and tasks. If I do have time I will try to look at the code.

[aias]

---

@Mark Yedinak wrote:

I haven't looked at the code however I did want to mention that it is a good practice to separate the user interface from the processing code. This can be accomplished in various different ways and it is not immediately obvious to new LabVIEW programmers. However this is one way to begin to isolate performance issues as well as provide the ability to utilize parallel processing and tasks. If I do have time I will try to look at the code.

---

Oke, thanks. I'll be here then.

[Norbert_B]

Looking into the VI i have to confess that i am not able to understand the code. There is much room for improvement and you should definetly incorporate some style guides. Given the following excerpt from your code:

makes me wonder if you are using some weird font types.

Just to sum up the most important points for a complete refactoring of the application:

1.) Change to a proper architecture. This will get rid of many race conditions you currently have in your code. You can work with State Machine, or as suggested by Mark, with a Producer/Consumer. The later architecture will split up UI and algorithm most often improving responsability of the application.

2.) Do not use property nodes 'value' for writing values to controls/indicators. The execution of those is round about 1000 times slower (depending on hardware/software environment/application) than writing to the terminal. There is only one exception to do that with a property node but that is not applicable here.

3.) Remove variables. Most variables are not needed if working properly with shift registers/feedback nodes. Variables induce a high risk of running into race conditions and therfore should be used with extreme caution.

4.) Clean up the code. Currently, the code is nearly unreadable due to overlaps of elements, unreadable text, overuse of locals and property nodes, bad wire layout (e.g. backwards wires), meaningless or missing labels (as far as readable) and last but not least the code is bigger than a single screen resolution of 1440x900 can display.

5.) Only update elements whose value changed. Currently, each iteration of your loop is writing values to nearly every indicator even if the value is the same as the last iteration. This will force LV to redraw the entire front panel each time resulting in a great slow down of the execution. Overlapping controls are an additional source for redrawing issues.

hope this helps,

Norbert

[Lucither]

---

Is the code shown an indication of how the rest of the code is wired?

---

There are plenty of structures inside, but they all have different conditions and are executed efficiently, and no, they are not wired from the constants, that was just a test.

---

Hmmmmm, maybe i have the wrong definition for efficiently??? 

[GerdW]

Hi Norbert,

on your font problem:

Aisa is using a cyrillic font (most probably on a cyrillic Windows environment), so the "weird labels" are reasonable and a problem of your own LabVIEW environment.

But I also wonder about the mixture of latin and cyrillic fonts in the user interface with some English "Speed" labels next to cyrillic "Timer" and Pause" indicators...

[Norbert_B]

Gerd,

i think that you are correct with that assumption. But still even if the text ist displayed properly as asian symbols, i assume that the labels will still overlap other block diagram elements.......

Norbert

[altenbach]

Yes, there are a lot pf problems with the current (unmodified) code, but I don't understand the original problem of slowness. On my 4 year old Laptop (core2duo) I can easily reach a loop rate of <50ms, so maybe something else is wrong on your machine.

You did not attach the typdefs, and they seem mutiliated? What are these fragments that cause the size of the typedefs to be so much bigger than needed? Is that intentional?

[aias]

---

@Norbert B wrote:

Looking into the VI i have to confess that i am not able to understand the code. There is much room for improvement and you should definetly incorporate some style guides. Given the following excerpt from your code:

---

I will look out that, but I admit that file was messy, because too much things very eventually added.

---

 

1.) Change to a proper architecture. This will get rid of many race conditions you currently have in your code. You can work with State Machine, or as suggested by Mark, with a Producer/Consumer. The later architecture will split up UI and algorithm most often improving responsability of the application.

---

Ehmm, how do I do it? :womanmad:

---

makes me wonder if you are using some weird font types.

---

No, actually it was cyrillyc, I just revised this now, hope you can read now.

---

2.) Do not use property nodes 'value' for writing values to controls/indicators. The execution of those is round about 1000 times slower (depending on hardware/software environment/application) than writing to the terminal. There is only one exception to do that with a property node but that is not applicable here.

---

Done.

---

 

3.) Remove variables. Most variables are not needed if working properly with shift registers/feedback nodes. Variables induce a high risk of running into race conditions and therfore should be used with extreme caution.

---

Done, but I could remove only 3 variables.

---

4.) Clean up the code. Currently, the code is nearly unreadable due to overlaps of elements, unreadable text, overuse of locals and property nodes, bad wire layout (e.g. backwards wires), meaningless or missing labels (as far as readable) and last but not least the code is bigger than a single screen resolution of 1440x900 can display.

---

Did some cleaning as well. The size is the same though.

---

5.) Only update elements whose value changed. Currently, each iteration of your loop is writing values to nearly every indicator even if the value is the same as the last iteration. This will force LV to redraw the entire front panel each time resulting in a great slow down of the execution. Overlapping controls are an additional source for redrawing issues.

---

How could I do it efficiently? Only my graph updates every 5 sec, but I cannot apply this method for other controls.

---

hope this helps,

Norbert

---

Thanks, well It did help, thanks. I will attach the revised and readable version, it should be all clear now. Have a look. The performance really did become better, I think, it seems to be doing more cycles now. However, the animation of water pipes is still very sloppy and choppy, I think that is the only issue now.

PC, I hope you found out how to start it, it is second button below the graph, but you need to enter some values there beside.

[aias]

---

@altenbach wrote:

Yes, there are a lot pf problems with the current (unmodified) code, but I don't understand the original problem of slowness. On my 4 year old Laptop (core2duo) I can easily reach a loop rate of <50ms, so maybe something else is wrong on your machine.

You did not attach the typdefs, and they seem mutiliated? What are these fragments that cause the size of the typedefs to be so much bigger than needed? Is that intentional?

---

Well it gets better, but these pipes are still choppy. What do you mean for typedefs by being mutilated? Yeah, well some of them are large, I have revised couple of them, but the rest I can do nothing with, because they are using time calculation, and that is only double it seems.