after aborting a program an extra move is executed by the interpreter. the extra move goes straight from the position the machine stopped on abort to the position indicated by the last line read by the interpreter. Tested it on a real machine, tested it also on the sim configuration (rack toolchange) that comes with the 2.6.1 and 2.6.2 version and the issue persists.
what I found so far:
altered the source code for version 2.7.0_pre0
in file: rs274_pre.cc - line 2411-2418 commented out (//char cmd[LINELEN];
and returned status = -1
now everything works ok except on_abort is not executed any more
I'm not able to reproduce this buggy behavior.
I tried v2.6.2 and the tip of the 2.6 branch (866190de), on a Wheezy VM running our RTAI kernel. Both behaved the same.
I start sim/axis/remap/rack-toolchange/racktoolchange.ini, home the machine, turn the max velocity down to 200-300 mm/min (so i'll have time to react), and start the auto-loaded program.
I tried hitting Escape in Axis at various points of the program, and in all cases i observed it behaved correctly: it would immediately stop the motion it was on, and then not perform any surprise motions. The DTG in the DRO stopped at the place it was supposed to (showing the remaining distance of the aborted move).
I turned [EMC]DEBUG up to 0x7fffffff and captured a trace of it doing the right thing (attached). The Abort is on line 695.
Alexandru, could you please provide a recipe for reproducing the buggy behavior you're observing? Include the version of linuxcnc you're testing, the platform you're testing on, the steps you take to reproduce the behavior, and the expected and observed results.
Thanks!
Hi Sebastian,
I tried version: 2.7.0_pre0, 2.6.2 and 2.6.1 on both ubuntu 10.04 and debian (linuxcnc image that can be downloaded from linuxcnc.org). In all cases, the auto loaded program works fine. I noticed a faulty behavior on abort when you load big programs, let's say 5.000 - 10.000 lines of G Code which is not uncommon for many finishing operations and the abort occures while the interpreter has not yet read the entire program. The interpreter reads several hundreds of lines of G Code ahead. At the moment a abort is issued the machine stops for some seconds at the abort position and than continues the move to the point (x,Y,Z) indicated by the last line read by the interpreter.
This bug appears only when an abort program is configured in the .ini file. if the abort sequence is left out from the ini file, everything works well.
I have digged a little bit in the source code and found a way to avoid the bug by not configuring an abort.ngc file. so the lines of code named in my previous post are ignored. Unfortunately I had little time in the last weeks to dig further in the source code.
I will come back in 20 minutes with debugging logs
a nice day!
alex
program attached
debug logs attached