LabVIEW
labview execution speed
Your VI is simply reading values that the Arduino spits out.
The speed is limited by the Wait for Multiple function, and the speed of the data coming from the Arduino.
So, increate the speed of the data coming form the Arduino.
Also, that's not really considered good programming. Wires are bended, sequence structures, duplicate code... You're making all the rooky mistakes. I hope you're doing some (free) courses while you're making this.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
duplicate code... You're making all the rooky mistakes. I hope you're doing some (free) courses while you're making this.
For example, the following could probably replaced by one single "scan from string". How does the incoming string look like?
The way you are coding this is full of booby traps and completely unnecessary operations (e.g. replacing the period with a comma then scan it using the system decimal point seems pointless and dangerous because it makes assumptions about localization. 🐵
@altenbach wrote:For example, the following could probably replaced by one single "scan from string". How does the incoming string look like?
Just as a direct replacement...
Yes, that's what I had in mind, but it will of course not solve the speed problem. 😉
(For an even simpler drop-in replacement, we can connect the various indicators directly to the scan outputs. No need to bundle. Still, the cluster is a good idea in general)
@altenbach wrote:
(For an even simpler drop-in replacement, we can connect the various indicators directly to the scan outputs. No need to bundle. Still, the cluster is a good idea in general)
I started writing that code to act as a subVI. Based on that, the cluster makes a lot more sense.
@crossrulz wrote:
@altenbach wrote:For example, the following could probably replaced by one single "scan from string". How does the incoming string look like?
Just as a direct replacement...
Careful!
No, it's not an exact replacement!
The original solution works for inputs regardless the used separator. So both 1,5 and 1.5 get parsed correctly. The replacement fails when commas are used.
Not that you should depend on that, but I've seen this replacement go wrong in inherited projects. It's was direct consequence of not having a good strategy for decimal points.
wiebe@CARYA wrote:
The original solution works for inputs regardless the used separator. So both 1,5 and 1.5 get parsed correctly. The replacement fails when commas are used.
No, the instrument string is not localized and always has a period as decimal delimiter.
The original solution replaces all periods with comma and then parses it forcing a localized delimiter, which will not correctly work if the localization is a period. It will fail and drop all decimals in most parts of the world!
Tim's solution correctly parses the input irrespective of decimal delimiter localization. It will correctly work everywhere!
@altenbach wrote:
wiebe@CARYA wrote:
The original solution works for inputs regardless the used separator. So both 1,5 and 1.5 get parsed correctly. The replacement fails when commas are used.No, the instrument string is not localized and always has a period as decimal delimiter.
The instrument string?
I missed the part where that strings comes from an instrument. It could be somewhere, I skimmed over most text.
EDIT: Ah, the Arduino... But that means custom code, which means anything goes. But probably '.''s are used, as OP replaces them.
@altenbach wrote:
The original solution replaces all periods with comma and then parses it forcing a localized delimiter, which will not correctly work if the localization is a period. It will fail and drop all decimals in most parts of the world!
Ah, yes, my reasoning would have been correct if it was replacing ',' with '.', and then didn't use the system setting.
Still, be very careful with replacements like that. Better yet, avoid being in that situation.
@altenbach wrote:
Tim's solution correctly parses the input irrespective of decimal delimiter localization.
Only if you're sure that the strings use '.' separators. Not sure how you can see that from the code.
Now of course one should make sure that at least a known separator is used. But with customers, you can't always make sure.
@altenbach wrote:
It will correctly work everywhere!
Not if the input uses ',' as separator.
Anyway, I'll find some other yaks to shave.
