Setvar and Getvar Race Condition

[DanStory]

I have noticed when I set a number a variables (via exec.Setvar) and read them out later (via exec.Getvar) they are stale values. Seems like exec.Setvar is asynchronous and I have not found a way to block execution until the vars have been written; and no Thread.Sleep or exec.Wait is not acceptable answers as it is still not assurance/guarantee the write actually did finished with in some arbitrary time frame and yet still a race.

SetGetVarRace.png (22.56 KiB) Viewed 4359 times

Even with a exec.IsMoving loop, there is still a chance (see `Counter: 23; #2000 Var:22`)

SetGetVarRace_IsMoving.png (18.13 KiB) Viewed 4359 times

Test Macro

Code: Select all

// Setvar and Getvar race condition

for(var i=0; i<10; i++){
    Counter++;

    exec.Setvar((double)Counter, 2000);

    // while(exec.IsMoving()){}

    var value = exec.Getvar(2000);

    exec.AddStatusmessage("Counter: " + Counter + "; #2000 Var:" + value);
}

#Events

static public int Counter = 0;


[cncdrive]

The Setvar is a motion syncronous command which is because the command is inserted into the motion queue and so it executes only when the previous commands in the buffer got exacuted.

In your case there is no motion in your macro, but because the Setvar is motion syncronous it works like a motion command, even if the motion buffer is empty the Setvar command is put into the queue and as soon that happens the exec.Ismoving() function return value becomes True and when the command got executed then the exec.Ismoving() function return value becomes False.
So, the solution for your problem is already in your macro, you have to use the while(exec.IsMoving()){} check after setting your #var(s) and before reading them out.

The other solution is to get the value from the software side variable table, like:

exec.AddStatusmessage("Counter: " + Counter + "; #2000 Var:" + exec.ivars[varnumber]);

The exec.ivars[] array acts syncronously, so it gets set immediately when you calling the exec.Setvar function, but the downside of doing this is that if the variable is set in a g-code program and is in the motion queue then the exec.ivars variable will already have the new value before it actually executed in the motion queue.

The UCCNC software syncronises the exec.Ivars[] array using the exec.Getvar() function on all the exec.ivars variables in a loop on software stop after the motion queue went empty.

So, this is the limitation of the motion being buffered.
But if you understand how it works then it is no more a problem though.
I think my description is clear enough to let you understand.

[DanStory]

you have to use the while(exec.IsMoving()){} check after setting your #var(s) and before reading them out.

If you look at the second screenshot, you will see (it was ran with the IsMoving uncommented) there was a still a race condition on "Counter 23" line.

I originally ran into this bug/issue with a much more complex scenario and macro, where vars are being set, actual motion is commanded and waited for (IsMoving loop) and then reread at the end of the macro with stale data. I will create a gcode and macro example to capture my use case and scenario better.

I think my description is clear enough to let you understand.

Thanks for the lengthly explanation btw helps me understand the inner workings

[cncdrive]

I see now. And ran it a few times and could reproduce it. About 1 out of 200 times in avarage it happens on my computer that one value isn't update in time.
So, really there is some kind of issue with this in the motion control API.
We will debug it soon.