Back
[00:03:11] <alex_joni> jepler:
http://www.peters-cnc-ecke.de/forumupload/uploadFiles/11515_156_axis.zip
[00:03:43] <alex_joni> minor changes to axis 2.2.3 (Ctrl-End allows touch off for all axes, in the currently selected coordinate system)
[00:35:54] <jepler> alex_joni: thanks for letting me know. I don't object if you want to refine it and put it on TRUNK. I notice that it will at least have problems on machines with missing axes (e.g. lathe, xyzbc, xyuv).
[00:36:15] <jepler> also, "global system" in that function is wrong to have
[04:59:02] <jmkasunich> cradek: lets talk about TLO in here
[04:59:11] <jmkasunich> at least about this possible bug
[04:59:22] <cradek> ok
[04:59:42] <jmkasunich> does the fact that G49 is showing in the codes display indicate anything?
[05:00:34] <jmkasunich> ok, entered G49, and the display went back to normal
[05:00:47] <jmkasunich> G0Z0 makes the DRO read zero
[05:01:20] <cradek> I think the codes always display g43 or g49
[05:01:30] <cradek> (I never look at those)
[05:01:41] <jmkasunich> G43H3 = DRO reads 0.789 (the table entry is -0.789 for that tool)
[05:02:21] <cradek> that seems right
[05:03:30] <jmkasunich> going from MDI to manual and back doesn't change the active code, but going from MDI to manual, touching off, and going back, changes the active code to G49
[05:03:41] <jmkasunich> I think its that cursed "reset the intep on mode change" thing
[05:04:21] <cradek> huh, that's not the problem I expected
[05:05:17] <jmkasunich> the behavior matches what you'd expect if the moves are not using TLO, and the DRO is using TLO
[05:05:50] <jmkasunich> it moves where the non-TLO command would make it move, which is consistent with the displayed G49
[05:06:06] <cradek> so switching modes changes the dro by unapplying tlo?
[05:07:08] <jmkasunich> I think it somehow unapplies TLO from the interp, but it remains applied in the DRO
[05:07:33] <cradek> ok, maybe that's the particular curse
[05:07:53] <jmkasunich> when its in that state and I issue a G49 the DRO fixes itself
[05:08:00] <cradek> (I sure don't care for those modes)
[05:08:17] <cradek> so the stat buffer does not represent the actual state of the interp
[05:08:32] <jmkasunich> the DRO is using the stat buffer?
[05:08:39] <cradek> yes TLO is in the stat
[05:08:42] <jmkasunich> or is the current codes display using the stat buffer
[05:08:55] <cradek> AXIS monkeys up the DRO and moves the axes according to that
[05:09:13] <cradek> well current codes are also in stat; they must not change together?
[05:09:29] <jmkasunich> the interp behavior is consistent with the codes in the code display
[05:09:34] <jmkasunich> the DRO behavior is not
[05:09:45] <cradek> ok
[05:09:56] <cradek> and unfortunately the interp behavior is not the one we want
[05:10:18] <jmkasunich> I bet the interp behavior is because the interp gets reset when you change modes
[05:10:45] <jmkasunich> I agree tho - if TLO is on when you switch to manual, you'd like it to remain on after you switch back
[05:11:17] <jmkasunich> wait - if I switch to manual and back without touching off, it stays in G43. that says its not the mode switch reset
[05:11:25] <jmkasunich> (I think - lemme try a few things)
[05:11:59] <cradek> there is a bugreport on sf. when you make sense of it will you make sure the bugreport is right?
[05:12:32] <jmkasunich> IOW, you don't want to think about it right now?
[05:12:35] <jmkasunich> (it is getting late)
[05:12:44] <cradek> well I fear fixing it will involve more than just me
[05:12:56] <cradek> maybe even alex + jepler + me
[05:13:20] <cradek> a clear description (which may already be there) would be very good
[05:13:24] <jmkasunich> I just confirmed that going to manual, jogging, starting the spindle, etc, and then going back to MDI does NOT drop it out of G43 into G49
[05:13:41] <jmkasunich> but going to manual and touching off, when you go back to MDI it is in G49
[05:13:44] <cradek> bizarre
[05:14:33] <jmkasunich> what does touch off actually do?
[05:14:47] <cradek> I was just looking
[05:15:00] <jmkasunich> this is the bug report you are talking about, right:
https://sourceforge.net/tracker/index.php?func=detail&aid=1825638&group_id=6744&atid=106744
[05:16:15] <cradek> switches to mdi, sends the G10, switches back to manual
[05:16:22] <cradek> I think that's it
[05:16:45] <cradek> yes that's the one
[05:16:49] <jmkasunich> two mode changes.....
[05:18:24] <jmkasunich> the G10 is non-trivial to figure out, isn't it? (If I want to do the same process manually, by hitting F3, jogging around (normal operations for touch off), hitting F5, entering the G10, hitting F3 (the touch off operation, with return to manual)
[05:18:39] <cradek> yeah it's a pain
[05:19:00] <cradek> pos = [(a-b) for a, b in zip(s.position , s.tool_offset)]
[05:19:12] <cradek> ^ tlo is involved in building the g10 command
[05:20:06] <jmkasunich> it would be interesting to know exactly when G43 turns to G49
[05:20:30] <cradek> mdi a G10 command and check that
[05:20:39] <jmkasunich> does it happen on the G10, or on the switch from MDI to manual that is part of the touch off, or on the switch from manual to MDI that I have to do to check the current codes
[05:20:44] <cradek> G10 L2 P1 Z9
[05:20:52] <jmkasunich> the Z value is a no-care?
[05:20:56] <cradek> yeah
[05:21:07] <jmkasunich> ok - I thought I had to compute something
[05:21:14] <cradek> well who cares what offset you get
[05:21:34] <cradek> this means Z=0 is 9" from machine origin Z
[05:22:05] <jmkasunich> remains in G43 mode
[05:22:17] <jmkasunich> display reads -9.455
[05:23:33] <cradek> I'm puzzled as to what resets it then
[05:23:45] <cradek> maybe turn on Task Issue debug
[05:24:08] <jmkasunich> that means a restart of EMC, right?
[05:24:14] <cradek> no
[05:24:23] <cradek> set debug level in the gui
[05:24:44] <cradek> (well if you have your stdout somewhere)
[05:25:24] <jmkasunich> found the settings
[05:25:30] <jmkasunich> and yes, I started from a terminal
[05:26:57] <cradek> I sure don't know when those 'active codes' get updated
[05:27:06] <cradek> this is all a bit on the mysterious side for me
[05:28:07] <cradek> could also be partly the time of day
[05:28:35] <jmkasunich> touch off issues 14 commands
[05:28:58] <jmkasunich> I could open an IRC client on that box, and paste them
[05:29:05] <jmkasunich> or we could go to sleep and work on this tomorrow
[05:29:12] <cradek> let's pick option 2
[05:29:17] <jmkasunich> good choice
[05:29:26] <jmkasunich> tomorrow alex might be around, and jeff
[05:29:26] <cradek> me being on a machine that can run emc would have to help too
[05:29:46] <jmkasunich> I bet you will be able to reproduce it
[05:29:52] <cradek> However, if a G00 move command is issued through the MDI the machine moves
[05:29:52] <cradek> to coordinates as if the G43 tool offset compensation is still active.
[05:30:09] <cradek> ^ this is an interesting part of that report
[05:30:18] <jmkasunich> I think he has it backwards
[05:30:23] <cradek> otherwise I think it matches your experience
[05:30:51] <cradek> this problem smells bad
[05:31:09] <cradek> but let's nail it tomorrow
[05:31:15] <jmkasunich> yeah
[05:31:17] <jmkasunich> goodnight
[05:31:24] <cradek> goodnight
[13:22:08] <jepler> yucky bug
[13:25:03] <micges> logger_dev: bookmark
[13:25:03] <micges> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-02-02.txt
[13:58:45] <micges> cradek: around ?
[13:59:01] <micges> I have some notes about G49/G10 issues
[14:08:15] <alex_joni> micges: pastebin
[14:09:59] <micges> in my memory :)
[14:10:03] <micges> well
[14:11:58] <micges> when I was programming tool measurement I was having problem that display position was different as it should be
[14:13:23] <micges> my workaround on touch off procedure is to:
[14:13:36] <micges> g49
[14:13:56] <micges> then read s.position
[14:14:09] <alex_joni> micges: in my experience it's always better to write things down, as you do you think about expressing it, and you can express it clearer
[14:15:06] <micges> good idea
[14:15:25] <micges> I have no experience about irc and such things
[14:16:26] <micges> Ill wait for cradek and try to explain him problem
[14:24:22] <alex_joni> micges: I suggested you try to write it down in a couple of lines and put it on pastebin, then cradek can read it when he's around
[17:59:03] <jmkasunich> cradek: jepler: alex_joni: who wants to fix the TLO/Touchoff bug? ;-)
[18:09:56] <micges> bbl
[18:53:13] <cradek> jmkasunich: apparently nobody
[19:00:05] <jmkasunich> :-(
[19:00:46] <cradek> maybe if we stall, you will fix it
[19:01:00] <jmkasunich> not bloody likely
[19:01:08] <jmkasunich> thats an area of the code that I don't understand at all
[19:01:25] <cradek> if you know what area the problem is in, you're one step ahead of me
[19:01:25] <jmkasunich> I'm happy to help however I can, running tests, brainstorming, etc
[19:01:45] <jmkasunich> the area is "axis" (and its interaction with other things)
[19:02:03] <jmkasunich> I know approximatey 0.01% of axis
[19:02:18] <cradek> so, the gui and maybe everything it's hooked to :-)
[19:02:26] <jmkasunich> gui, task, and interp
[19:02:42] <jmkasunich> I'm confident the problem is not in motion, hal, or rtapi ;-)
[19:02:58] <jepler> no, it's probahbly task/interp
[19:03:01] <jepler> argh now I said something
[19:03:52] <cradek> yay, now that someone has "fixed" a bunch of const stuff, I get new warnings about discarding consts
[19:04:17] <jmkasunich> lots? or just a few?
[19:04:33] <cradek> lots of a few warnings
[19:04:39] <cradek> throughout hal stuff
[19:04:53] <cradek> mostly halrmt.c
[19:04:58] <jmkasunich> what system are you compiling?
[19:05:05] <cradek> trunk/dapper/sim
[19:05:12] <jmkasunich> just looked at the dapper farm slot, no warnings
[19:05:21] <jmkasunich> not sim tho
[19:05:33] <cradek> hal/utils/halrmt.c:298: warning: passing argument 1 of 'sockWriteError' discards qualifiers from pointer target type
[19:05:59] <jmkasunich> you are freshly updated?
[19:06:11] <cradek> yes
[19:06:45] <cradek> I'll clean and make a full log
[19:07:01] <jepler> here too
[19:07:15] <jmkasunich> wtf? it was building clean when I committed it
[19:07:33] <jmkasunich> doing a make clean now - this box is dapper sim
[19:08:27] <jmkasunich> ok, I got two in halcmd, and a modest bunch in halrmt (couple dozen)
[19:08:50] <cradek> wow, your machine is much faster than mine
[19:08:58] <jmkasunich> I did most (or all) of that const work on a RT box, wonder if halrmt builds differently on sim
[19:09:16] <jmkasunich> I was doing the build before I told you I was
[19:09:19] <jmkasunich> but yes, its fast ;-)
[19:09:56] <cradek> ok I'm moving on - I don't care about consts
[19:10:22] <jepler> I fixed
[19:10:22] <jepler> I fixeI commit?
[19:10:31] <jepler> I fixed -- should I commit?
[19:10:40] <jmkasunich> fixed the const stuff, or the TLO bug?
[19:10:49] <jepler> const stuff of cours
[19:10:53] <cradek> dang
[19:10:55] <jepler> something trivial
[19:11:00] <jmkasunich> by all means
[19:11:10] <jmkasunich> I was going to tackle those - I want clean builds
[19:11:59] <jmkasunich> ah - for some reason when I was working on it I thought sockWriteError was a system API, not a function that we defined
[19:12:07] <jmkasunich> I'll fix the remaining 2 in halcmd
[19:13:19] <jmkasunich> * jmkasunich kicks CIA-21
[19:13:26] <CIA-21> ow
[19:14:33] <cradek> I'm going to go to my actual machine - it's hard to understand without seeing the axis position
[19:15:54] <jmkasunich> last two warnings fixed
[19:19:04] <jepler> bbl
[19:25:14] <cradek> jmkasunich: I don't see the bug
[19:25:35] <cradek> (on trunk - I wonder if that matters)
[19:28:40] <cradek> I lied - I was testing 2.2.2
[19:28:52] <cradek> what version are you using?
[19:29:05] <jmkasunich> 2.2.2 I think, lemme double check
[19:29:31] <jmkasunich> yep - haven't updated yet
[19:29:52] <CIA-21> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/halrmt.c: const annotations
[19:29:52] <CIA-21> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/utils/halcmd_commands.c: fix const warnings
[19:30:04] <jmkasunich> * jmkasunich hugs CIA-21
[19:30:05] <CIA-21> * CIA-21 hugs jmkasunich
[19:30:07] <cradek> both trunk and 2.2.2 work as I expect
[19:30:14] <cradek> I wonder what's going on
[19:30:21] <jmkasunich> lemme connect to IRC from there and walk thru it step by step
[19:30:45] <cradek> I'm on a lathe but that seems unlikely to matter
[19:31:09] <jmk-st> ok
[19:31:21] <cradek> let me say what I'm doing, and you can try it too
[19:31:27] <cradek> home
[19:31:32] <cradek> mdi g43h9
[19:31:49] <cradek> f3
[19:32:01] <cradek> jog Z to be near something
[19:32:15] <cradek> hit End, Enter
[19:32:25] <cradek> Z dro goes to 0
[19:32:30] <cradek> f5
[19:32:35] <cradek> g0z0
[19:32:41] <cradek> there is no motion
[19:32:46] <cradek> g49
[19:32:53] <cradek> dro changes and cone moves
[19:32:58] <cradek> g0z0
[19:33:00] <cradek> there is motion
[19:33:11] <jmk-st> slowdown
[19:33:22] <cradek> that's all, take your time
[19:34:07] <jmkasunich> the screen on there is too small to see more than a few lines of the IRC window and the axis window at the same time, and both keyboard and mouse substitute suck....
[19:34:39] <cradek> I have a much smaller machine and much bigger monitor :-)
[19:35:41] <jmkasunich> "hit end, enter"
[19:35:51] <jmkasunich> thats the same as clicking on touch off Z, then enter?
[19:36:01] <cradek> yes
[19:36:01] <jmkasunich> (I have no end key - mini kbd
[19:36:13] <cradek> but I wanted to say exactly what I was doing
[19:37:44] <jmkasunich> understood
[19:37:44] <jmkasunich> OI'
[19:37:56] <jmkasunich> I've duplicated your steps, but our results diverge
[19:38:03] <cradek> interesting
[19:38:07] <cradek> where?
[19:38:19] <jmkasunich> when I hit touch-off, enter, Z dro goes to zero, like yours
[19:38:23] <jmkasunich> F5
[19:38:25] <jmkasunich> G0Z0
[19:38:28] <jmkasunich> I get movement
[19:38:38] <cradek> ok
[19:38:41] <jmkasunich> and the DRO indicates a non-zero value after the move is complete
[19:39:08] <cradek> on a lathe or mill config?
[19:39:13] <jmkasunich> mill
[19:39:29] <jmkasunich> I can pastebin my ini file - my hal is probably not important
[19:39:42] <jmkasunich> and I can pastebin my tool table
[19:40:20] <cradek> I'm trying the same steps in mill
[19:40:29] <jmkasunich> you were in lathe?
[19:40:53] <cradek> yes
[19:41:13] <cradek> I get your (wrong) results on sim/axis (mill)
[19:41:33] <cradek> that is extremely surprising
[19:41:42] <cradek> do you have a lathe config you can try?
[19:42:11] <jmkasunich> have yes
[19:42:23] <jmkasunich> not crazy about trying it right now, since I'm touched off on a part
[19:42:33] <jmkasunich> http://www.pastebin.ca/889229
[19:42:37] <jmkasunich> ini and tool table, if needed
[19:42:58] <jmkasunich> it seems to me like tool length offset along Z would not be used in lathe
[19:43:10] <jmkasunich> lathe mode offsets are completely different aren't they?
[19:43:19] <cradek> both X,Z are used
[19:43:23] <cradek> other than that they work the same
[19:44:25] <jmkasunich> I thought lathe had multiple different modes depending on what corner your tools are facing, and angles and such
[19:44:41] <cradek> yes but that's for radius comp, not tlo
[19:44:49] <cradek> tlo is just like mill, except there's an x and z offset
[19:44:55] <jmkasunich> ok
[19:45:15] <jmkasunich> I obviously don't know offsetting on the lathe - I assumed that lathe had "radius" offsets only
[19:45:31] <jmkasunich> where radius becomes tool-shape, since its not round
[19:45:48] <cradek> you need Z because the tools change left-to-right
[19:46:00] <cradek> boring bar is an extreme case
[19:46:17] <jmkasunich> the offsets determind the location of the circle that represents the tooltip radius, right?
[19:46:29] <cradek> no
[19:46:30] <jmkasunich> and then radius/shape comp handles it from there
[19:46:40] <cradek> the offsets determine the tool's "controlled point"
[19:46:55] <cradek> which is in various places on the tool according to the tool shape/orientation
[19:47:01] <cradek> (sometimes it's outside the tool)
[19:47:04] <jmkasunich> oh, ok
[19:47:21] <jmkasunich> anyway, not relevant at the moment - I'll have to learn lathe comp eventually
[19:47:36] <jmkasunich> but mill comp is simpler
[19:47:44] <cradek> I'm shocked that they work differently
[19:47:46] <jmkasunich> TLO is Z only, radius is XY only, no interaction
[19:48:01] <cradek> I always did this on lathe, so I figured that bug report was just in error
[19:48:31] <cradek> in fact it makes me think I haven't yet found the actual pattern
[19:49:35] <jmkasunich> although you normally don't look at the active g-code display, in this case I think its quite usefull
[19:50:07] <jmkasunich> it indicates that the interp winds up in G49, and the move that happens when it shouldn't is EXACTLY the move you'd get if you were in G49
[19:50:30] <jmkasunich> but the DRO is still in G43, so it displays something other than zero after a G0Z0
[19:50:58] <jmkasunich> if you issue a G49, DRO and interp get back in sync
[19:51:05] <jmkasunich> (with no TLO)
[19:51:26] <jmkasunich> likewise, if you issue a G43 (after the bug happens), interp and DRO get back in sync, with the proper TLO in effect
[19:52:13] <cradek> http://pastebin.ca/889236
[19:52:34] <cradek> here are my steps again
[19:52:49] <jmkasunich> this is in mill mode?
[19:52:49] <cradek> first do you agree this is the right behavior and a sufficient test?
[19:53:00] <cradek> this is what I typed earlier - lathe
[19:53:49] <jmkasunich> yes, I believe so
[19:54:02] <cradek> after step 08 (pastebin line numbers) I see G43 in the active-g-codes list
[19:54:04] <jmkasunich> minor nitpick - when you say "cone moves", on my screen the program moves
[19:54:25] <cradek> ohhhhhhhh
[19:54:31] <jmkasunich> in mill mode, after step 8 I see G49
[19:54:37] <cradek> here is a major difference - in lathe mode, no program is loaded in the interp
[19:54:47] <cradek> BING: clue 1
[19:54:55] <jmkasunich> lol
[19:55:02] <jmkasunich> and I thought it was just a nitpick
[19:56:14] <cradek> loading a program does change the behavior to be wrong
[19:56:33] <jmkasunich> in lathe mode?
[19:56:39] <cradek> at step 08 I see g49, and at step 09 I get motion
[19:56:41] <cradek> yes in lathe mode
[19:56:52] <jmkasunich> so one bit of astonishment goes away
[19:56:56] <cradek> yes
[19:57:46] <cradek> wonder if this is another synchronization problem with the two interpreters
[19:57:56] <jmkasunich> two interps?
[19:58:08] <jmkasunich> AXIS is running an independent interp for the preview?
[19:58:11] <cradek> yes
[19:58:26] <jmkasunich> does the DRO come from the independent interp?
[19:58:31] <cradek> the internal interp reloads the program so you see it move
[19:58:45] <cradek> the DRO comes almost directly from the stat buffer
[19:59:53] <cradek> here's officially where I feel lost
[20:00:00] <jmkasunich> damn
[20:00:30] <jmkasunich> we gotta get jeff and/or alex involved
[20:00:33] <cradek> jeff
[20:00:41] <jmkasunich> we can replicate it, which is a big step forward
[20:01:59] <cradek> I'm taking out the file reload after touch-off, I bet that "fixes" it
[20:02:48] <jmkasunich> at the expense of breaking something else tho? or is this just an experiment?
[20:03:05] <cradek> experiment
[20:03:32] <cradek> yes it's the reload that nukes the TLO
[20:03:57] <cradek> instead of doing a touch-off, do a reload, you'll see the same thing
[20:05:13] <cradek> c.reset_interpreter(); c.wait_complete()
[20:06:02] <cradek> but which interpreter is "c" you might ask
[20:09:39] <jmkasunich> lemme guess.... the wrong one?
[20:10:26] <cradek> no clue
[20:10:34] <cradek> but taking out that line fixes the tlo thing
[20:12:52] <cradek> (wonder what it breaks)
[20:13:38] <jmkasunich> the preview display probably
[20:13:40] <cradek> I'm going to go make some coffee - maybe jepler will show up and help
[20:14:10] <jmkasunich> I'm gonna try to make the part that I started last night
[20:14:40] <cradek> fwiw that reset_interpreter was there in revision 1.1 of axis.py
[20:14:54] <jmkasunich> IOW, don't remove it lightly
[20:15:09] <cradek> well, it only predates the emc2+axis merge
[20:15:10] <jmkasunich> and also "people must not use TLO and touch-off together much"
[20:15:23] <cradek> true
[20:16:13] <cradek> I guess I don't - I call my most commonly first-used tool (the one that faces and turns) TLO=0
[20:16:48] <jmkasunich> so the bug is happening for you, but the difference between the two positions is zero
[20:16:51] <cradek> I always make a facing cut with it using jogs, then without moving, set the touch-off
[20:17:12] <cradek> yes I think you are right
[20:17:51] <cradek> maybe - depends if I'm in G43H1 (TLO=0) or G49 (TLO not set)
[20:18:15] <cradek> probably I'm usually in G49, so the bug doesn't happen
[20:18:34] <cradek> bbl
[21:31:04] <jmkasunich> well, I just had my first crash
[21:31:34] <jmkasunich> 5/16" endmill, 2500 RPM, rapid down into the head of the 1/4" SHCS that is holding the work
[21:32:22] <jmkasunich> strangely, the PC rebooted
[21:34:26] <cradek> ouch
[21:36:51] <jmkasunich> I'm pretty certain it was an offsets thing
[21:37:42] <cradek> bug in you, or the software, or both?
[21:38:18] <jmkasunich> not sure yet, and the reboot will prevent any forensics
[21:38:34] <cradek> wonder what caused that - surely not a coincidence
[21:38:53] <jmkasunich> I think the heavy load on the motor dipped the line enough to force a reboot
[21:39:25] <jmkasunich> milling hardened steel cap screws at 48IPM isn't easy
[21:39:44] <cradek> hurt anything but the screw and endmill?
[21:40:30] <jmkasunich> don't think so
[21:40:51] <jmkasunich> I haven't been able to get the screw out yet - the head is mangled and the allen wrench won't go in
[21:41:04] <jmkasunich> need to restart emc and move the table so I can get vise grips on it
[21:41:12] <jmkasunich> (I moved Z up by turning the pulley)
[21:41:37] <cradek> I have a nasty fix for tlo+touchoff
[21:41:58] <cradek> not sure if it's the right approach or not (just save TLO and reprogram it after the reset)
[21:45:11] <cradek> but, if I just take out the reset, it works equally well
[21:45:15] <cradek> I wonder why that's there.
[21:49:27] <jmkasunich> question for jepler?
[21:51:00] <cradek> I like this fix better - I'm going to check it in on trunk
[21:53:00] <cradek> I think the reset was only there to make sure the var file is written. but, switching modes does that too, and it doesn't destroy all these important settings
[21:53:58] <jmkasunich> sounds like a good fix
[21:54:16] <jmkasunich> that will fix some other things too, won't it? like spindle turning off when you do a touch-off?
[21:55:55] <cradek> good question. I don't think it will fix that particular one, but it will fix others (that maybe haven't bothered anyone yet)
[21:56:01] <CIA-21> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[21:56:01] <CIA-21> EMC: try not resetting the interp before when reloading the file. This
[21:56:01] <CIA-21> EMC: fixes SF#1825638 as well as other things like loss of the G20/G21
[21:56:01] <CIA-21> EMC: setting and other modal things from MDI.
[21:56:05] <cradek> mdi g20/g21 is a good example
[21:58:30] <jmkasunich> * jmkasunich tries again to make his part
[21:58:42] <jmkasunich> I'm really confused about what happened there
[21:58:47] <jmkasunich> it wasn't a TLO issue
[21:58:58] <jmkasunich> the tool came down about a half inch from where it was supposed to
[21:59:19] <jmkasunich> oh
[21:59:20] <jmkasunich> dumbass
[21:59:23] <jmkasunich> I know why
[21:59:32] <jmkasunich> because thats how I wrote the fscking program
[21:59:53] <cradek> oops
[22:00:00] <jmkasunich> my X touch-off was bogus, because I forgot that the edge of the part isn't at X=0
[22:00:30] <jmkasunich> the part is one section of an assembly, drawn in cad
[22:00:47] <jmkasunich> the drawing has all the parts at their proper relative positions
[22:00:54] <jmkasunich> so CAD 0,0 isn't part 0,0
[22:03:01] <cradek> that's why we need the AXIS-preview-to-laser-light-show that outlines the gcode on the workpiece
[22:03:53] <jmkasunich> that would be nice
[22:03:54] <cradek> (in all seriousness, I use the cone on the screen like that - jog it to various points in the program)
[22:07:52] <jmkasunich> I just did what I forgot to do yesterday when I wrote the program
[22:08:02] <jmkasunich> added comments at the top saying how it should be touched off
[22:09:06] <jmkasunich> I think I'm gonna be a wuss and break for dinner now
[22:11:02] <cradek> ok, I tested this change, if you could try it too that would be great
[22:11:37] <cradek> it's a backport candidate if we all (especially jepler) seem to like it
[22:30:44] <alex_joni> * alex_joni usually likes fixes
[22:30:48] <alex_joni> so this is no difference
[22:30:58] <alex_joni> but what I really mean, is that I'm no help with this one..