Back
[14:17:26] <mozmck> Hmm, I think I found a bug in my simple run-from-line. If I hit stop in the middle of an arc, and then try to do RFL from another line, it seems to think I'm still doing an arc.
[14:33:31] <cradek> what does the another line have on it?
[14:36:15] <mozmck> G0
[14:36:46] <mozmck> I think I need to clear some state before I start an rfl - maybe the interp-list?
[14:38:42] <mozmck> If I start from an M5 it seems to clear whatever it is and work then.
[14:39:10] <cradek> oh hmm, so it has an explicit G0
[14:39:25] <mozmck> Yes.
[14:39:35] <cradek> I wondered if it was just XYZ words (where I'd expect to get arcs, maybe weird ones)
[14:40:20] <mozmck> no, I knew that was a problem and started on G0 Zxx line.
[14:41:07] <mozmck> I was assuming all the state would be cleared by an abort, but apparently not.
[14:41:40] <cradek> it's not clear to me what an abort should do
[14:41:53] <mozmck> me either.
[14:43:08] <mozmck> I'm also having problems with hal_glib events. It generates multiple events when it should only do one. The main thing for me is it often generates a file-loaded event when you hit stop, causing the gcode window and gremlin to re-load.
[14:43:54] <mozmck> I guess I can either fix it, or just not use hal_glib events for some things.
[14:47:22] <mozmck> looks like emcTaskAbort() should clear out everything
[14:48:12] <cradek> if you turn on task issue debug and RFL that G0, you should be able to see what the interpreter issues (is it a line or an arc)
[14:48:25] <cradek> seems like that would cut the problem space in half
[14:48:28] <mozmck> Oh, interesting: // without emcTaskPlanClose(), a new run command resumes at
[14:48:28] <mozmck> // aborted line-- feature that may be considered later
[14:48:51] <cradek> hmm your project just doubled in size? :-)
[14:48:57] <mozmck> That comment is from emcTaskAbort(). Then it calls emcTaskPlanClose()
[14:49:26] <mozmck> which is probably why I'm getting a re-load of the file :-(
[14:50:20] <mozmck> thanks for the debug tip - I'll do that. I've used the debugging for some of this already and it is quite helpful
[14:51:26] <mozmck> So I wonder if I can implement that "feature" of not closing the file on an abort? I can work around it I guess - it seems axis does it, but fixing it there might be better.
[14:52:17] <mozmck> Fixing it could break everything else though :-) Maybe it should be an ini option?
[14:54:41] <cradek> I sure don't know what the fallout would be
[14:57:56] <mozmck> I could just push it to 2.6 and see ;-)
[15:15:42] <cradek> heh, you'd have to say 2.5 to troll me with 100% effectiveness, since I'm not the 2.6 maintainer.
[16:15:47] <mozmck> Hmm, so it looks like the actual reason the file-loaded signal is getting sent is because the last file in the stat structure (which is updated about every 100ms) is the last external file subroutine that it had run.
[16:16:20] <mozmck> Seems like external file subroutines cause numbers of problems!
[17:45:40] <seb_kuzminsky> mozmck: what would/should happen if you're in G80 and you SRFL frmo a line with axis words but no G-word?
[18:09:27] <cradek> I would expect "Cannot use axis values without a g code that uses them"
[18:09:39] <cradek> because it should be the same as if I do that in mdi
[18:10:14] <cradek> am I missing something?
[18:17:24] <seb_kuzminsky> no, that sounds right
[18:17:50] <seb_kuzminsky> i think "it should do the same as it would if i typed it in mdi" is probably the right benchmark
[18:18:02] <seb_kuzminsky> i just wasnt thinking through it right, thanks
[18:19:16] <seb_kuzminsky> in other news, there's a strangeness in debian stretch that causes tons of errors like this:
[18:19:22] <seb_kuzminsky> Internal error: Could not assign #<��v�>
[18:20:31] <seb_kuzminsky> and when you start Axis it says "'utf8' codec can't decode byte 0xff in position 39: invalid start byte" (in a little lower-right error message popup)
[18:21:02] <seb_kuzminsky> apparently a python problem of some sort
[18:21:08] <cradek> that smells familiar
[18:21:28] <seb_kuzminsky> all the binaries i checked are correctly linked to python2.7, through the system also has python3.mumble installed
[18:24:25] <cradek> do you have 2a5ab77c9?
[19:29:52] <seb_kuzminsky> cradek: nope, i'll try with that one, thanks
[21:45:34] <seb_kuzminsky> cradek: that fixed it
[21:45:40] <seb_kuzminsky> i'll cherrypick it to 2.6
[21:48:11] <cradek> amazing
[21:48:27] <cradek> jepler is the king of commit messages
[21:49:24] <seb_kuzminsky> i'm amazed you remembered seeing it go by 6 months ago
[21:49:45] <seb_kuzminsky> good night