Tool offsets issue, cannot start program[video question]

Henk wrote:

Hi. Are you running a cam generated program? I didn't see any gcode above.

I noticed that your z axis max limit is 0. In my experience, when this is 0, and your program contains lines like "G53 G0 Z0" as a retract move, it causes errors similar to these.

Replacing those lines with G53 G0 Z-5 for example eliminates these errors (in my case at least)

For this reason, I always set the maximum limit for z in the ini file to something slightly larger than 0. Even 0.1 usually prevents this issue.
 

Thanks nice idea.

I don't think I have a move command in machine coords though (G53).

The sample I was trying to execute is

As my analysis of the problem was somewhat off I link a better explanation of the situation here:
forum.linuxcnc.org/20-g-code/44244-g43-1...axis?start=20#282062

[edit]
For future reference:
Limit checking in the AXIS gui is useful because it checks for limit violations in the entire gcode and can detect soft limit errors before the code is 'run'. In contrast the 'milltask' interpreter will only check for limit violations up to the next queuebuster (eg toolchange) so a long program may run for hours and then fail with a softlimit error after some tool change far along in the gcode.
It is important to note that AXIS calculates the limits when the Gcode is _loaded/reloaded_ and uses the tool offsets active _at this time_. Hence if the user issues a change to the tool offset values (eg a toolchange in MDI) _after_ loading/reloading the gcode the calculation may not be up to date and produce a false error message.
For this purpose a 're-check' option has been added to the error popup window in LinuxCNC version 2.9 which will reload the gcode and thus recalculate soft limit violations using the current tool offset values:

 



 

Just FYI, lately I just ignore the warning, as there is not any actual out of limit parts anywhere in my code.

My code runs fine, does not trigger any limit. I don't understand what kind of check is happening by axis. But since the program runs correctly the check must be somehow wrong.


In the meantime, I am having a look at the thread you shared.