Back
[18:49:17] <cradek> offs
[18:49:21] <cradek> reload tool table in AXIS is broken again
[18:49:40] <jepler> what.
[18:49:48] <cradek> start up, home, mdi T1 M6 (with T1 having nonzero diameter in the tool table), cylinder appears
[18:49:58] <cradek> file/reload tool table
[18:50:06] <cradek> status line goes to 'no tool' and cone comes back
[18:50:37] <cradek> v2.4.5-494-g6f29079 (current git master)
[18:51:01] <jepler> sim/axis?
[18:51:04] <cradek> yes
[18:53:16] <jepler> broken on v2.4_branch too, so I actually care about this
[18:53:24] <cradek> what the hell
[18:55:25] <jepler> $ git log --oneline -1 origin/v2.4_branch src/emc/iotask/
[18:55:25] <jepler> c57f2d2 Fix current tool information after reloading table
[18:55:30] <jepler> my fix must just have been broken?
[18:56:29] <cradek> but we tested that stuff so hard
[18:57:04] <SWPadnos> Dewey Garrett's changes affect Interp::init_tool_parameters
[18:57:12] <SWPadnos> http://git.linuxcnc.org/?p=emc2.git;a=commitdiff;h=0b8474a
[18:57:46] <cradek> jepler: did you get there with bisect or are you guessing that's it?
[18:59:01] <jepler> cradek: no, I'm not saying that's the commit that broke it
[18:59:15] <cradek> sure seems like a description of the same problem
[18:59:16] <jepler> I'm saying that's the commit that was supposed to fix it
[18:59:41] <jepler> I notice reload_tool_number ends up calling load_tool(0); not sure if that's right or bogus..
[19:00:05] <cradek> good question.
[19:00:13] <jepler> anyway, I'm testing next at that commit
[19:00:50] <jepler> looks like it's broken bac at c57
[19:00:50] <cradek> btw, even after AXIS is in that state, interp/motion is correct
[19:04:07] <jepler> small blessings..
[19:05:30] <cradek> I'm wrong
[19:05:34] <cradek> I think motion is wrong
[19:07:18] <cradek> that is very not good
[19:10:47] <jepler> I looked in my irc logs and didn't spot any discussion of that commit
[19:10:54] <jepler> were we in meatspace or something?
[19:11:25] <cradek> the last time I remember us working on that was when we were drinking too much coffee in the hippie grocery store in god-knows-what city
[19:11:45] <jepler> emc-devel-2010-08-12.log:21:35 <CIA-5> EMC: jepler v2.4_branch * rc57f2d242e75 /src/emc/iotask/ioControl.cc: Fix current tool information after reloading table
[19:11:46] <cradek> so yeah, that was meatspace
[19:12:02] <cradek> no idea if I'm thinking of 2010-08 though
[19:12:05] <jepler> this 21:35 is my local time..
[19:12:26] <jepler> workshop wasn't in august..
[19:12:35] <cradek> yeah, and this would have been morning or at least afternoon
[19:13:20] <jepler> can you test random tc at c57f2d242e75 and c57f2d242e75^?
[19:14:00] <cradek> I doubt I can test anything at all with any confidence
[19:14:24] <jepler> for nonrandom it looks like starting at tool 0 is boooooogus, because pocket 0 will match toolno, but on nonrandom load_tool(0) is "magic T0 = pocket 0 = no tool"
[19:15:22] <cradek> which of your nons was an accident?
[19:15:45] <cradek> the first I assume
[19:15:50] <jepler> ... but on random load_tool(0) is magic ...
[19:16:02] <cradek> on random, tool #0 is not special
[19:16:02] <jepler> er, maybe all of them were?
[19:16:03] <jepler> let me back up
[19:16:09] <cradek> ?REDO FROM START
[19:16:14] <jepler> thank you
[19:17:15] <jepler> if only I had Microsoft Office 2012 to help me organize my thoughts about this...
[19:17:37] <jepler> or maybe Visual Studio 2103#
[19:18:44] <jepler> ok, you were right
[19:18:57] <jepler> except now I'm thinking that random_toolchanger doesn't need to do *anything*
[19:19:22] <jepler> this is all about 'is the stuff in pocket 0 right after reload', and that's a special case for nonrandom
[19:19:49] <jepler> the old bug was "I edit the tool table but nothing really changes until I also reload the tool"(?)
[19:20:22] <jepler> but reload_tool_number is wrong because it starts at pocket 0, which matches the currently loaded tool number, but hits the "magic no tool" case in load_tool
[19:20:37] <jepler> so maybe the fix is this?
[19:20:37] <jepler> void reload_tool_number(int toolno) {
[19:20:37] <jepler> - for(int i=0; i<CANON_POCKETS_MAX; i++) {
[19:20:37] <jepler> + if(random_toolchanger) return; // doesn't need special handling here
[19:20:37] <jepler> + for(int i=1; i<CANON_POCKETS_MAX; i++) {
[19:22:09] <SWPadnos> hmmm. I may be over (or under) simplifying things, but isn't there some variable that actually holds the tool number of the loaded tool?
[19:22:44] <cradek> yes, probably about eight of them, in various processes
[19:23:14] <SWPadnos> (no sleep and two triple-shot Cafe Americanos can lead to simultaneoud over- and understatements)
[19:23:16] <SWPadnos> heh
[19:23:26] <cradek> jepler: that change looks promising to me
[19:23:53] <cradek> I'm ashamed that I made nonrandom need a lot of special-case code that it previously didn't
[19:24:12] <SWPadnos> I guess I was going to suggest saving that number, reloading the table, and then updating "all the other stuff" once the table is reloaded. I guess that's probably what's already (presumably) being done in the current design
[19:24:14] <cradek> the whole tool table swirl needs a rewrite
[19:24:27] <SWPadnos> well, at least fest is arriving soon :)
[19:25:15] <SWPadnos> hmmm. this sucks. the terminal strips on the new 7I37TA are different from the old ones
[19:25:26] <jepler> SWPadnos: argh!
[19:25:28] <SWPadnos> and I forgot to order a motherboard for my 3x20
[19:25:30] <SWPadnos> yeah
[19:26:03] <jepler> cradek: let me ax you this scenario. T1M6 / G43 / edit tool table and change T1's offset / reload tool table
[19:26:05] <SWPadnos> new plugs can plug into old boards, but the plugs that are already installed in equipment can't plug into new boards, like when one dies and needs to be changed fast ...
[19:26:07] <jepler> expected behavior?
[19:26:55] <SWPadnos> my take: same thing as just after the T1M6 - in need of an entry move
[19:27:23] <SWPadnos> there is the special case where the diameter of the loaded tool doesn't change though
[19:27:54] <cradek> jepler: expected behavior is that length doesn't change until next G43
[19:28:05] <jepler> cradek: oh, phew!
[19:28:24] <SWPadnos> oh length. back to the coffee pot then!
[19:28:26] <cradek> same if you foolishly are in mdi mode with G41 etc active
[19:28:47] <cradek> god forbid
[19:43:14] <CIA-31> EMC: 03jepler 07v2.4_branch * ra317d6196a60 10/src/emc/iotask/ioControl.cc: Fix current tool information after reloading table
[19:43:45] <psha> * psha very happy of commit dff6b25 switch from dh_python (deprecated) to dh_pysupport
[19:47:40] <psha> btw are Shift-PageUp/Down working on keypad?
[19:47:54] <psha> or how it's correctly named
[19:48:03] <psha> i mean right part of keyboard under numlock
[19:49:47] <psha> Shift+KP_Up/down/etc are working fine but Shift+KP_Prior/Next are not working at all...
[20:08:45] <qq-> psha, but link was about "Git's original tagline was "the stupid content tracker". Git-annex inverts that, by managing files with git, without checking their contents into git. ..Not a little data, but terabytes spread amoung multiple archival drives, file servers, laptops, and portable USB drives. In situations too complex for unison or rsync to be of much use.""
[23:41:43] <skunkKandT> couple questions... (locking rotories) we have figured out that 1 rotation of the shaft is 5 degrees. 5 degrees is the index of the coupling. (good) now - there is no switch that for homing - so I am thinking a home to index only. Here is my thoughts....
[23:46:29] <skunkKandT> I am thinking that I want to physically set the index pulse so it is in the middle of the slack/middle setting on the coupling (locked down). now - I am also thinking that for homing I will not lift it (if that is possible) What I am thinking if it is possible is have the homing sequence go one direction until it takes the lash up in the gear train. Now I would measure that by maybe...
[23:46:30] <skunkKandT> ...following error or pid output (if that made sense). that would trip the trip the 'homing switch' (virtual by following error or pid output or...) then it would search for the index the opposite direction.