Back
[13:17:50] <cradek> micges_work1: I agree that reverting 74ce25a makes the bug go away.
[13:18:18] <micges_work1> hi cradek
[13:18:31] <cradek> hi
[13:18:45] <cradek> crazy bug
[13:18:57] <micges_work1> yes
[13:19:20] <micges_work1> another one Is that emc don't unhome joint after estop but does it after machine off
[13:19:29] <micges_work1> after external estop
[13:20:38] <cradek> are you talking about when VOLATILE_HOME for an axis is true?
[13:21:29] <cradek> (I did not remember whether that was ever finished)
[13:21:43] <micges_work1> yes I finshed it
[13:21:53] <cradek> maybe not :-)
[13:22:24] <cradek> either way, that is a much less serious bug
[13:22:33] <cradek> thanks for working on both of them
[13:23:22] <micges_work1> cradek: this is fix for above volatile home bug:
http://www.pastebin.ca/1861786
[13:23:49] <cradek> that looks believable
[13:24:47] <micges_work1> it works, tested on real stepgen machine
[13:24:55] <cradek> cool
[13:26:26] <SWPadnos> is there a problem with gitweb and viewing commits?
[13:27:02] <SWPadnos> I searched for 74ce25a, and the search found the commit "make socket addresses reusable"
[13:27:22] <SWPadnos> which doesn't seem like it should be the one to screw up stepgens after abort
[13:28:29] <cradek> http://git.linuxcnc.org/gitweb?p=emc2.git;a=commit;h=74ce25ac44d72ba18c5a229ef813cae0377bc26b
[13:28:49] <cradek> gitweb sucks
[13:28:56] <SWPadnos> ok, good to know :)
[13:29:30] <cradek> here's how I did it: I flailed around clicking on things until I was at any commit, then edited the URL
[13:29:37] <SWPadnos> heh
[13:29:41] <cradek> as far as I can tell, that's how you use gitweb
[13:29:53] <SWPadnos> does it work with a partial commit ID?
[13:30:02] <cradek> don't get all silly now
[13:30:07] <SWPadnos> ok, it does
[13:31:03] <cradek> hey I have an idea for a great new feature. they should make it so you can select "commit" as the thing to search for, then put the commit id in the "search" field, and then it'd show you that commit
[13:31:52] <SWPadnos> wow. I think we're really on the same page here. I had the same idea when I was looking at the drop-down selector that said "commit", and the text entry field next to it
[13:32:13] <cradek> it's a synergy of ideas!
[13:32:28] <SWPadnos> soon we'll redefine the marketplace or something
[13:36:47] <alex_joni> heh
[13:36:57] <alex_joni> lets go for a wheel or something
[14:56:27] <JT-Work_> JT-Work_ is now known as JT-Work
[15:04:30] <JT-Work_> JT-Work_ is now known as JT-Work
[16:04:59] <JT-Work_> JT-Work_ is now known as JT-Work
[17:08:12] <CIA-2> EMC: 03micges 07v2.4_branch * r67944f4933b7 10/src/emc/task/emctaskmain.cc: Unhome VOLATILE_HOME joints also after external estop
[17:08:17] <CIA-2> EMC: 03micges 07v2.4_branch * r06b93f6f250d 10/ (13 files in 13 dirs): Revert "make sure that canon path control mode is equal motion path control mode"
[17:51:58] <cradek> micges: did you understand why it made the machine move some seemingly random way?
[17:52:53] <micges> I was not searching it
[17:53:17] <micges> I can spend some time this evening to seek it
[17:53:31] <micges> look for*
[17:53:36] <cradek> it worries me because it seems very strange
[17:55:16] <SWPadnos> off the cuff, it seemed like it might be a race condition where the motion mode should be set to NONE (however that's spelled), but Interp::synch ends up changing it back to a running state after the abort
[17:55:31] <SWPadnos> but that seems like it would be much harder to hit
[17:59:03] <micges> could be
[20:25:47] <micges> cradek: log from 'going someewhere' bug:
http://www.pastebin.ca/1862294
[20:28:43] <cradek> weird. do you know where the extra LINEAR_MOVE comes from?
[20:29:34] <micges> from program
[20:30:18] <micges> after stop running line is set for line that was executed after abort
[20:32:44] <micges> while running program current_line is about 2060 and after escape it's set to ~3060 and gcode from that line in program is executed
[20:33:31] <micges> something messy with readahead in task (again)