ideas for speeding up front panel

[GerdW]

Hi bmishoe,

your code looks a little bit Rube-Goldbergish, but nothing  completely wrong…

- How long does that notifier take to deliver a new value?

- you can resize IndexArray to output more than one value, and you don't need to wire indices when you start from index 0…

- you only need one tunnel into the inner case structure for the very same value

- instead of converting that integer to boolean array and back you might just "AND 0x0000FFFF", followed by ToU16…

- when you want to wire a TRUE to that "ready" local variable you should do that…

[bmishoe]

- How long does that notifier take to deliver a new value?

After the user makes the selection of what regs they want to see, a subpanel gets loaded with all the indicators (i.e. the page I uploaded yesterday) and a single "process" command is issued by the notifier.  In other words, the notifier delivers a 'process' value at the beginning, and a 'stop' value at the end, and nothing in between.

- you only need one tunnel into the inner case structure for the very same value

this is an artifact of how VI scripting created this case structure.  For some reason, the first 3-4 entries have discrete tunnels, and then after that they all use the same tunnel.

- when you want to wire a TRUE to that "ready" local variable you should do that

yeah tell me about it...I searched for a day to find a way to instance a TRUE constant in VI scripting, but could only ever find FALSE.  I know that sounds odd, and perhaps I missed something obvious, but for real, I looked everywhere and could only find FALSE.

[bmishoe]

OK, so I think I found the culprit and learned something in the process...

In my program, you can't see it but each control/indicator has a (hidden) label with a UID in the form of RxFy#z.  xyz serve as indices into a 3D array that has all the relevant info for all the controls/indicators on the page.  Each time the user interacts with a control, an event is triggered and a SubVI runs.  Into this SubVI comes a reference to the control the user clicked on, which allows me to extract its label, which I then use to index said array.

I determined it was this indexing function that was the culprit, but I need it in there because each control is unique.  In any case - I found that by replacing a single "index array" function (where I wire both the page and the row) with 2 index function (1 accesses the page, the next one the row) that it sped it up dramatically.

Is this a known benefit?

[dkfire]

How many more property nodes are you using on the references of your controls and indicators? 

Also a Loop-up table like that could be made with Variant Attributes.

https://forums.ni.com/t5/LabVIEW-Development-Best/Using-Variant-Attributes-for-High-Performance-Look...

[wiebe@CARYA]

---

@bmishoe wrote:

I have done some researching and it seems that the main recommendation for solving this problem (apart from reducing the number of controls) would be to use the defer FP updates property...but in my case, I don't think that's playing a role here, because as I mentioned earlier, I'm not connected to a card. 

---

Not connected to a card? Not sure I get that.

Defer Panel Updates would be useful, as it makes the "value" property nodes not synchronize with the refresh rate of the screen. Try updating an indicator in a for loop 100000 times, with a property node... Then try again but turn Defer Panel Updates on before the for loop (and off afterwards).

[Yamaeda]

---

@bmishoe wrote:

I determined it was this indexing function that was the culprit, but I need it in there because each control is unique.  In any case - I found that by replacing a single "index array" function (where I wire both the page and the row) with 2 index function (1 accesses the page, the next one the row) that it sped it up dramatically.

Is this a known benefit?

---

That sounds very strange. The mentioned variant method is really good. Something like this:

/Y

[GerdW]

Hi bmishoe,

why do you need 7 string functions to parse the control label? Why not use ScanFromString with "R%1sF%d#%d"!?

I would also go with a LUT using variant attributes!

In my program, you can't see it but

Didn't we ask for code - for several times?

[wiebe@CARYA]

---

@bmishoe wrote:

OK, so I think I found the culprit and learned something in the process...

In my program, you can't see it but each control/indicator has a (hidden) label with a UID in the form of RxFy#z.  xyz serve as indices into a 3D array that has all the relevant info for all the controls/indicators on the page.  Each time the user interacts with a control, an event is triggered and a SubVI runs.  Into this SubVI comes a reference to the control the user clicked on, which allows me to extract its label, which I then use to index said array.

---

Scan From String would be a cleaner way to get x, y and z from RxFy#z...

---

@bmishoe wrote:

I determined it was this indexing function that was the culprit, but I need it in there because each control is unique.  In any case - I found that by replacing a single "index array" function (where I wire both the page and the row) with 2 index function (1 accesses the page, the next one the row) that it sped it up dramatically.

Is this a known benefit?

---

That is totally unexpected. I'd bet on the exact opposite. Are you sure you tested under the exact same conditions? (All sub VI's FP's closed, saved after the changes, same data, etc.)

[Yamaeda]

---

@GerdW wrote:

why do you need 7 string functions to parse the control label? Why not use ScanFromString with "R%1sF%d#%d"!?

I would also go with a LUT using variant attributes!

---

That looks like a censored curse word, which in general is how i feel about regular expressions! (though they can be magical at times)

/Y

[GerdW]

Hi Yamaeda,

That looks like a censored curse word

It's not me who invented this "RxFy#z" naming scheme…