forum.cncdrive.com

While writing an Auto Zero macro, I discovered what I think is a bug. Probing does not seem to work if the feedrate is less than 1.
Run the following code from a button, and the second probe move does not occur, and Var #5063 is set to 0.
But if you change the second feedrate to 1 or greater, it runs fine. (Change F0.5 to F1)
Using Version 1.2029
UC300ETH with 5LPT motherboard.

Code: Select all

exec.Code("G90");
while(exec.IsMoving()){}

exec.Code("F15"); // Set First Probe Feedrate

exec.Code("G31 Z-6"); // Do First Probe move
while(exec.IsMoving()){}

double Znew = exec.Getvar(5063); // Read the touch point

exec.Code("G0 Z" + (Znew + .1)); // Retract
while(exec.IsMoving()){}

exec.Code("F0.5"); // Set Second Probe Feedrate

Znew = (AS3.Getfielddouble(228) - 1.25);

exec.Code("G31 Z" + Znew); // Do Second Probe move
while(exec.IsMoving()){}

Znew = exec.Getvar(5063); // Read the touch point

exec.Code("G0 Z" + Znew); // Move back to touch point in case of overshoot
while(exec.IsMoving()){}

Actually, it works if the feedrate is 0.6 or greater, so it appears that if the feedrate is 0.5 or less, it's being rounded down to 0 maybe?

Hi Gerry,

I've quickly tested this and debugged it down to the ProbeStart API call and the issue is reproducable here, it really does not work with F0.6 and lower.
The issue is clearly something in the API, maybe a number rounding or something like that, but on the C# part of the code the number is not rounded,
when the Feedrate sent to the API for the probing the value is still correct, not zero, but the API seems to skip the probing then, so it must be an API issue.
I will describe this issue to my collegue on Monday, so he can check and correct this problem in the API.

Found the problem, it is in the API, there is a condition check for the feed<0.01 and if so then the command is skipped.
This was because the old firmware of the UC100 did not support feed<0.01 for probing, the current firmware supports it, but it seems this condition check remained in the API accidentally.
And 0.01 because the API measures everything in Units/seconds, so 0.6units/min is 0.01units/sec.
We probably did not notice this because using millimeters units 0.6mm/min is very low, so we probably never programmed that low feedrate for the probing, but it is not that low with inches.
Anyways, this will be corrected in the next release.

Great, than I won't have to change my code.
While testing, I increased the FRO to speed up the testing process. I then found that the FRO was changing the probing speed, so I wrote some code to scale the feedrate based on the FRO value, so probing would always be done at the correct speed. This scaling was what set the feedrate to such a small value.
Thanks again for the excellent support.