1.2103 Probing issue

[ger21]

When doing X and Y axis probing in 1.2103, Vars 5061 and 5062 are returning 0 after the probe trips.
It was working fine in 1.202.

I didn't test any other axis, so I don't know if its all of the vars (5061-5066)?

[cncdrive]

Ah, that is very possible, because the vars handling was fully changed as described in the release notes and I do not see any notes that if we changed the probing code to follow that.
So, it seems the probing was not converted and it makes sense why it now returns 0 values for all.
I will check this out soon and will make the required modifications to make it work properly again.

[cncdrive]

I've checked and corrected this problem. It got broken in the latest release because of the ivars syncronisation upgrade, we forgot that it also influences the probing, so the probe coordiantes did not update in the vars syncronisation routine. Will be OK again in the next test release.

[A_Camera]

I've checked and corrected this problem. It got broken in the latest release because of the ivars syncronisation upgrade, we forgot that it also influences the probing, so the probe coordiantes did not update in the vars syncronisation routine. Will be OK again in the next test release.

Perhaps that's the explanation of why one of my probe screen user reported problems as well on the Hungarian CNC forum https://forum.hobbycnc.hu/topic.php?topic=218. I am still on 1.2047 so I haven't seen it before, but I am using the #5061, #5062 and #5063 so this is probably the reason why probing is not working.

[cncdrive]

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.