![[Home]](/chips.gif)
History of LineNumbers
UpdateThe "motion id zero" anomaly is found and fixed: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=cfd174ad104f85ca82f8f5bebde4ecdf83575a92 and here: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=18d437822cf1b9a4694dacb0564201410e456a6b . This means that any motion id (which is also used as a line number feedback for the GUIs) can be used except the special value(s) described in motion.h . It turns out that the collective subconscious must have known about this for a long time, and worked around it several times. Unfortunately these workarounds had several cascading side effects. Now that the real cause is found and fixed, the path is open to several repairs and imrpovements, which are: * the negative MDI linenumber workaround in task can be removed. This means that feedback from MDI oword sub calls (eg 'o<sub> call') will now report the correct line number in sub.ngc. It remains to be done to signal to the GUI's that the source context has changed (eg from MDI string to sub.ngc) and cause it to display the proper context, but this is straightforward. This means that post-repair no legit linenumber generated from interp will ever by negative. * the interpreter can now be used as the single source of linenumber information. This means that the interp_list.set_line_number() workarounds from task can be removed. * the assumption "negative linenumber equals MDI mode" has to be cleaned up. command.c:240: reportError(_("%s move in MDI would exceed joint %d's positive limit"), command.c:250: reportError(_("%s move in MDI would exceed joint %d's negative limit"), control.c:404: reportError(_("Probe tripped during non-probe MDI command.")); While technically these will now report the proper linenumber, the test for id >= 0 and the corresponding MDI error message can now be removed to report the actual line number like in auto mode. |