LabVIEW
Failed global variable update?
Solved!
@michele.santucci wrote:
Why?
I mean.. I need to have a sequence with just one case and in such case the order is left to right?
While without any sequence the order was reversed.... ????
The position on the block diagram has no impact on in which order something executes, only the wires and relations between blocks. Do you think Numeric 3 will finish before Numeric 2? Do you think moving Numeric 2 to the left would change that?
@Yamaeda ha scritto:
@michele.santucci wrote:
Why?
I mean.. I need to have a sequence with just one case and in such case the order is left to right?
While without any sequence the order was reversed.... ????
The position on the block diagram has no impact on in which order something executes, only the wires and relations between blocks. Do you think Numeric 3 will finish before Numeric 2? Do you think moving Numeric 2 to the left would change that?
NO.
I'm stating that in my first screenshot Load Config.vi was on the left of Get Boards.vi block and this caused the race condition because evaluation of BOARDS_PATH global variable was executed before Get Boards.vi ... and this lead to my issue.
To fix this I put Load Config.vi and Get Boards.vi into separate frames of a sequence ... then Paolo replied .. the first frame is useless.. for me this mean anything in the sequence should be put inside only one frame .. probably he was meaning to put the first frame out of the sequence.
@michele.santucci wrote:
No, but if you could make a cluster out of it, that would be better. Best would be to organize your global into a typedef'd cluster of parameters. That way if you need to add a new parameter, you add it to the typedef and everything gets updated all over the place.
This's the perfect world where the code is always wrote correct the first time by an experienced coder.
This's not the case. The code already exists and uses 100 sparse global variables.
Actually, it wouldn't be that terribly difficult if the parameters are all on one global VI. Take all the parameters, dump them into a cluster, typedef it, then everywhere there needs to be a change will be broken and then you just unbundle the correct one. Tedious, yes, but ultimately it is safe because it will break everywhere you have to fix it, and the result is something infinitely easier to manage.
