03-10-2018 11:25 AM - edited 03-10-2018 11:39 AM
OK, here's a quick testbench that toggles between label and caption for all controls/indicators as fast as the computer allows:
On my laptop:
Defer Panel update=OFF: 600ms loop time!
Defer Panel update=ON: 30ms loop time! ---> 20x faster!
(This is downconverted from a newer version. See if it also works in your LabVIEW 2013)
And yes, you could try to just rewrite the caption iterating over one of two "arrays of captions" based on the language setting. Not sure if it make a difference.
(And yes, in the real code do this in a separate loop triggered by a value change, of course)
03-10-2018 11:31 AM
All that said, your method is ill adviced because it is not scalable. What if you want to support more than two languages a year from now? (e.g. English, Russian, German, French, Italian)
Use the built-in localization tools as I already said! 😄
03-10-2018 11:55 AM - edited 03-10-2018 12:02 PM
Thank you very much for your advice. But this is not a commercial product, it's in my house. I used English only for this forum. (if I have any questions, I will show my program, but in Russian it will not be clear .) In English you can help me 🙂
my results: 1,2sec and 77.3 ms
03-10-2018 12:24 PM
In any case, all properties only need to be written if they change. In your first image, you also constantly write many color and blinking properties with each iteration. These all belong inside case structures so they get skipped if the value is the same as before.
Again, LabVIEW is great doing things in parallel. In your case, these properties are only cosmetic and have nothing to do with the main purpose of the program (e.g. communicating with the instrument). All you need is a small separate loop as shown in the image (the other event case returns a true if stop is pressed, no terminal needed). Now the language change does not stall the main loop, but occurs in parallel.
(You might want to trigger the language event also once at startup if this is not an executable, because the state might be stale)
03-12-2018 10:43 AM
Once again many thanks to everyone, this method works for two languages perfectly.
now about the gremlin, I noticed that the iteration run time changes from 600 ms to 1.2 second and it depends on settings window run time position . when the maximum set is 600ms, why so I do not know.
03-12-2018 10:54 AM
Are you still not deferring panel updates?
How are you setting the run time position and what are the positions that cause the different times?
How are you measuring the timing? Does one position have more overlapping objects?
03-12-2018 11:53 AM
i did in my vi deferring panel updates.
Now I did the tests, and the time did not change when the window position changed. These are miracles. But last time (custom position) I had about 1.2 seconds, I changed to maximum and the time was 600ms.
I measuring the timing like in your vi above.
I have a several cosmetics objects.
03-12-2018 11:53 AM - edited 03-12-2018 11:56 AM
.
03-12-2018 12:06 PM
Why all the that duplicate code? Why all these local variables? What's the point of the "reinit all"? (Is that supposed to execute at the beginning, at the end, or at some random time?)
(Currently posting by phone, will look at it more later)
03-12-2018 12:40 PM - edited 03-12-2018 12:42 PM
It would be better if you attached your entire VI. Where does the code in the picture called cosmetic.png come into play? How often does that run? You are setting a lot of property nodes there. You should only need to write to a property mode in the situation where the values actually change.
How do you know your code takes 1.2 seconds? I don't see anything in your code that measures the time to execute.
In "Metod.png" you have a number of string indicators, but they don't have any labels. Do not hide labels on terminals in a block diagram. What are those string indicators for?