LabVIEW
Failed global variable update?
Solved!
@michele.santucci ha scritto:
I know it's ugly but this way it will work:
To be precise, the first frame is useless.
@michele.santucci wrote:
Hallo,
I think I'm having a problem with global variables.
I have a big number of global variables defined into parameters.vi.
Among these parameters I have BOARDS_PATH, this variable is the folder where I have to look for some xml files.
BOARDS_PATH value is changed by Load_Config.vi that reads values from .ini file and set BOARDS_PATH variable
(among the others).
BOARDS_PATH is used by Get_Boards.vi to create an array (Boards) of values I will use to look for specific board profile.
This's the main vi section where Load_Config and Get_Boards are called.
Load_Config.vi do something like this, the stacked sequence is repeated for each possibile entry in the .ini
file (there's a better solution?).
If I debug the main vi global values are correctly set BOARDS_PATH is consistent.
If I run the main vi without debugging it or if I compile it and run the binary then BOARDS_PATH is left at the default value (without any visible error).
So, to elaborate a little on drjdpowell's post, dataflow rules are simply "a node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution". Following this guideline, you can see that Load_Config.vi will not let Get_Boards.vi execute until it is done, BUT there is nothing in the rules that mention when the BOARDS_PATH global read should supply the value to Get_Boards.vi. And, indeed, the global is read before Load_Config.vi can supply a value for the the BOARDS_PATH global. Usually. But if you force the VI to execute differently - e.g., by turning on/off debugging, adding probes, using highlight execution, etc, that could - and in this case DOES - change when the global is actually read.
So when he says to put the global read and the Get_Boards.vi in a sequence structure, the sequence is a node, and the stuff inside the sequence will not execute until all the inputs are satisfied - i.e., the error wire that runs through it if you've done it right - supplies the sequence structure with a value, and then the global be read, and be guaranteed to be read, after Load_Config.vi stuffs a value into the global. It becomes much clearer if you put the stuff in a subVI instead of a sequence structure.
@michele.santucci wrote:
@drjdpowell ha scritto:
In your screenshot, you have written code to read the global variable first.
You're guessing it or stating it?
Load_Config.vi .. the write of global variables is wrote BEFORE (left) the reading of such variable (right) ...
If you're stating that LabView will perform reading before writing besides their left right order ok I got this ...
Please see my explanation. it should pretty much explain what he is saying.
Hi Michele,
@michele.santucci wrote:
You're guessing it or stating it?
Load_Config.vi .. the write of global variables is wrote BEFORE (left) the reading of such variable (right) ...
If you're stating that LabView will perform reading before writing besides their left right order ok I got this ...
DrJD is STATING!
The global variable has no dependencies to other code in your image and so DATAFLOW dictates "it can be read at any time" - and will be read most probably before the subVI left of it has been executed!
Again: you should ALWAYS say "THINK DATAFLOW!" when encountering race condition problems…
@michele.santucci wrote:
I got your hint but as you can see there are 22 more parameters loaded into Load_Config... and any of this params could be subject to the same issue... should this suggest to have 23 outputs wires running out of Load_Config ?
Maybe a cluster or an array ...
If only I was not refactoring this code maybe this could be a viable approach.
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.
@michele.santucci wrote:
@drjdpowell ha scritto:
In your screenshot, you have written code to read the global variable first.
You're guessing it or stating it?
Load_Config.vi .. the write of global variables is wrote BEFORE (left) the reading of such variable (right) ...
If you're stating that LabView will perform reading before writing besides their left right order ok I got this ...
It's funny, because he is both guessing AND stating, and they are NOT mutually exclusive.
Hi Michele,
@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.... ????
Please repeat: THINK DATAFLOW!
With the sequence frame there is clear DATAFLOW: everything before the frame is executed BEFORE execution/dataflow will enter INTO the frame. As the global will be inside the frame the read will only occure once the frame is entered…
Repeat again: THINK DATAFLOW!
("left to right" is only recommended for block diagram style, but it DOES NOT define dataflow or execution order!)
