LabVIEW
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.
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.
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 :
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 :
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 :
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.
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.
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. 😜
@Herrmann-s wrote:
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.
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.
this is a tough one 😉
@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.
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.
