Not perhaps, but definately.
This change (in release note) in version 1.2103 is causing the probing variables to not update nin that latest test release:
- The internal variables (#vars) interpretation had a limitation (the same limitation which Mach3 also has) in it's working due to the motion buffering, that the #vars has to be advance calculated, so the external query of the vars did not give the proper timed value if there was a looking ahead in the g-code. The #vars value displayed was always what it was lastly calculated including the looking ahead. So, for example attaching a #var to an analog output and changing the value line by line could not work unless if there was a wait code after each value change which blocked the looking ahead. An example code to show this issue:
G0 X0
#1 = 1
G0 X1
#1 = 2
In this example the #1 value queried with the Getvar function or if it was attached to an analog output showed value 2 even while the G0 X1 code was being executed, because the software was looking ahead and already calculated the #1 to have value 2.
The working of this was now changed, the #vars are now pushed into the motion buffer and now the queries show the values in syncron with the g-code execution.
We forgot to convert the probing routine to make it compatible with the new way of handling the #vars.