LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

optimization of code replacing constant with timer

G'day. I am working on it and the suggestion seems to work well. thank you very much again!

If you find any other "timing" related code wich should be optimized please let me know. theses things are hard to find for me because you need to dive a little deeper in how to avoid timing or race conditions.

2024-05-16 11_42_01-Pressure.jpg

 i am still a bit worried about this coding-part from the beginning (or other parts you experts you would tag as critical and should be fixed). i somehow dont trust this section on my posted picture and maybe it causes some timing/sync issues as well.any suggestions are welcome and will helpof course.

0 Kudos
Message 21 of 38
(320 Views)

sorry i forgit to mention what my idea was. i just read a little bit about "notifiers" that sounds interesting to me to use it.

0 Kudos
Message 22 of 38
(310 Views)

Hi Herrmann,

 

I only have LabVIEW 2020 on my computer, so I can't open "201019_TCCLeakDownLatenciesEjectMod_override_button_mod_002.vi" that seems to have all the "fun" stuff.

Maybe you could save this VI for a previous version and post it here ?

 

Small request, to save baby seals: please put some Wait function in loops like this one :

PinguX_0-1715854824531.png

PinguX_1-1715854864970.png

 

 

Message 23 of 38
(307 Views)

yes sure. i saved it in 2015 format.i hope that is ok for your version.

with these 50ms in loops that should "slow" down the speed a little bit i guess and it is not neccessary to let them run in full speed right?

 

0 Kudos
Message 24 of 38
(295 Views)

Exactly (for the 50ms).

 

Looking at the big VI, there are bunches of things that can be improved (or should be).

 

For example, regarding this part :

PinguX_0-1715862839686.png

 

First step : clean up.

Some operations are "constant", so it can be externalize in an init procedure. Some local variable are duplicated, ...

 

Example of clean up :

PinguX_1-1715863095419.png

This allows to quickly see where potential problems may arise.

 

In this case, there is a race condition between the two "Tool change cycling" booleans. Each of them impacts the other.

 

Second step : patching.

Moving the local variables (those in writing access) in the case structure at the end of the loop resolve the race condition.

PinguX_2-1715863760923.png

 

Third step : improve.

Constantly monitoring value of controls on the Front Panel is an old-fashioned method, nowadays we usually use event structure to perform actions only once a value has changed.

PinguX_3-1715864038302.png

 

Repeat those three steps for every part of the code, improving gradually as you learn new stuff in LabVIEW.

 

First step will help you overcome and master the code, as well as smoothing reading the data flow for later on.

Second step will patch residual bugs.

Third step will improve scalability of the program, facilitating future upgrades, optimizing performances as well.

 

There is no magic here, you need to learn and practice. The "NI Example Finder" will be your friend for next months.

Some content I may recommend you to look after :

- event structure

- FIFO, notifier

- state machine

- producer/consumer method

- mastering timing

 

Good luck, have fun. 😜

Message 25 of 38
(278 Views)

@Herrmann-s wrote:

2024-05-16 11_42_01-Pressure.jpg

 i am still a bit worried about this coding-part from the beginning (or other parts you experts you would tag as critical and should be fixed). i somehow dont trust this section on my posted picture and maybe it causes some timing/sync issues as well.any suggestions are welcome and will helpof course.


Basically, if you have Local Variables you have potential Race conditions. A Local Variable is a bad choice of name, it's a Local Data Copy. Knowing that and looking at your picture you can see that "TCC w/o tool holder" (and "with") exists as both Control and Local Copy, thus you can't be sure if the Local Copy is updated before or after it's read to be used in the property. Just wire from the Control.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 26 of 38
(273 Views)

you guys are great! thats a fantastic task and challenge! 

few days ago i was standing in front of a hill and had no idea where to start climbing.

now i can start fixing the code and try to understand. thank you

0 Kudos
Message 27 of 38
(237 Views)

Third step : improve.

Constantly monitoring value of controls on the Front Panel is an old-fashioned method, nowadays we usually use event structure to perform actions only once a value has changed.

Herrmanns_0-1715933041603.png

 

this is a tough one 😉

Message 28 of 38
(225 Views)

@Herrmann-s wrote:

Third step : improve.

Constantly monitoring value of controls on the Front Panel is an old-fashioned method, nowadays we usually use event structure to perform actions only once a value has changed.

Herrmanns_0-1715933041603.png

 

this is a tough one 😉


Yes, refactoring the code is always a pretty big job. Make sure you have and use a SCC like Git or Subversion for all changes so you don't f**k things up. 🙂
It'll be worth it from maintenance, navigation and error finding aspects of the code though.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 29 of 38
(205 Views)

my colleague just gave me an another hint related to this ominous 10 constant.

he told me that this 10 is some sort of a unknown timing of the loop

this timing should be a "real" time  (not realtime 😉 )

 

i hope my english and or my explanation is good enough for the experts to extract the real message 😄 sorry for that.

0 Kudos
Message 30 of 38
(186 Views)