Back
[02:56:21] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/task/ (taskintf.cc emctaskmain.cc emctask.cc):
[02:56:21] <CIA-40> EMC: to allow run-from-line to work better, let the user set the spindle
[02:56:21] <CIA-40> EMC: and coolant and TLO how it's needed, using either manual or MDI, and
[02:56:21] <CIA-40> EMC: then don't mess it up when changing modes and resuming the program.
[02:56:32] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/nml_intf/emc.hh:
[02:56:32] <CIA-40> EMC: to allow run-from-line to work better, let the user set the spindle
[02:56:32] <CIA-40> EMC: and coolant and TLO how it's needed, using either manual or MDI, and
[02:56:32] <CIA-40> EMC: then don't mess it up when changing modes and resuming the program.
[03:00:31] <cradek> wonder what are the chances I got that all right...
[03:01:01] <SWPadnos> how many lines did you change?
[03:01:25] <cradek> dozens in task
[03:01:43] <SWPadnos> P(correct)=1/(dozens) ;)
[03:02:04] <cradek> ack
[03:06:41] <jmkasunich> times a constant
[03:07:38] <SWPadnos> for EMC_TASK_STATE_ESTOP, shouldn't emcIoAbort also be called?
[03:07:45] <SWPadnos> (emctask.cc)
[03:10:14] <SWPadnos> hmmm. and maybe in the last changed spot too, in emcTaskUpdate
[03:10:39] <cradek> it is ...?
[03:10:56] <cradek> line 233
[03:11:18] <SWPadnos> @@ -482,7 +482,7 @@ int emcTaskUpdate(EMC_TASK_STAT * stat)
[03:11:20] <SWPadnos>
[03:11:21] <SWPadnos> if(oldstate == EMC_TASK_STATE_ON && oldstate != stat->state) {
[03:11:23] <SWPadnos> emcTaskAbort();
[03:11:24] <SWPadnos> - emcSpindleAbort(1);
[03:11:26] <SWPadnos> + emcSpindleAbort();
[03:11:28] <SWPadnos> }
[03:11:29] <SWPadnos>
[03:11:30] <SWPadnos> // execState set in main
[03:11:43] <SWPadnos> basically everywhere else there was an smcSpindleAbort(1), it was replaced with spindle and IO abort calls
[03:12:14] <cradek> tell me around which line you think is wrong?
[03:12:30] <cradek> because I'm lost
[03:12:43] <SWPadnos> 225 and 484 maybe?
[03:12:48] <SWPadnos> emctask.cc
[03:12:59] <cradek> see line 233
[03:13:40] <cradek> and at 484, emcTaskAbort calls emcIoAbort first thing
[03:13:51] <cradek> twisty maze of passages...
[03:14:09] <cradek> oh, no it doesn't
[03:14:09] <SWPadnos> ok, the IOAbort is just later in that case
[03:14:10] <cradek> hmmm
[03:14:13] <SWPadnos> heh
[03:14:27] <cradek> there's an effing copy of it called canterp
[03:15:17] <SWPadnos> yeah, I don't see the motion abort in TaskAbort
[03:15:24] <SWPadnos> err - s/motion/io/
[03:15:49] <cradek> see the other emcTaskAbort...
[03:16:16] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/task/emctask.cc: missed this one
[03:17:21] <SWPadnos> uh, yeah. that seems nice and confusing
[03:17:32] <SWPadnos> canterp that is
[03:17:48] <cradek> I have nfc what that is or why it matters
[03:18:05] <cradek> I can't imagine it needs a copy of task code in it, but who knows
[03:18:17] <SWPadnos> yeah. I was starting to wonder that myself
[03:18:23] <SWPadnos> then I wondered why I haven't gone to bed yet :)
[03:18:38] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: allow command line arguments to filters
[03:19:49] <cradek> well me too.
[10:37:14] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/src/hal/classicladder/classicladder_gtk.c: adjustment to rung window :)
[11:16:43] <micges> how many entries screw comp file can have ?
[11:19:41] <BigJohnT> I think I saw that in the manual somewhere...
[11:27:58] <micges> max value is 256
[11:33:23] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/nc_files/probe-hole.ngc: remove text not needed
[11:42:22] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/examples/gcode.lyx: add hole probe example
[12:07:42] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Master_User.lyx: minor edit
[12:07:55] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/examples/gcode.lyx: minor edit
[12:36:51] <jepler> ooh bigjohnt is editing source files now
[13:11:36] <skunkworks> logger_dev: bookmark
[13:11:36] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-10-09.txt
[13:34:22] <alex_joni> heh
[13:41:41] <skunkworks> heh?
[13:43:15] <alex_joni> about jepler's comment
[13:43:22] <alex_joni> 15:30 < jepler> ooh bigjohnt is editing source files now
[13:44:27] <SWPadnos> he only did that be cause he has a low-res monitr :)
[13:44:30] <SWPadnos> +o
[14:53:36] <jepler> how do you RFL in tkemc?
[14:54:43] <cradek> it's inside file/edit
[14:55:00] <jepler> oh
[14:55:03] <jepler> found it
[15:02:52] <cradek> it works at least somewhat...
[15:03:05] <cradek> I got motion from the line above the one I chose though - not sure what that was about
[15:05:07] <BigJohnT> cradek: does the spindle and coolant changes for start from line need any explanation in the manual?
[15:05:36] <jepler> BigJohnT: I'm trying to get cradek to write a manual section on run-from-line
[15:05:50] <cradek> BigJohnT: I think the manual should say how to use program resume. you have to be smart about the machine state when you resume, and also you have to be smart about picking a good place to start, and I don't think any of that is in the manual yet
[15:06:13] <BigJohnT> I'm sure it is not in the manual
[15:06:24] <jepler> BigJohnT: I also looked for any section on this topic, and didn't find anything
[15:06:34] <cradek> I've thought about these issues a lot lately, and jepler is right that I should write something
[15:06:52] <jepler> I think there should be a new file in the "gui" section that discusses these things that apply to all of the GUIs
[15:06:56] <jepler> oops, meeting -- bbl
[15:07:15] <BigJohnT> if you want to just e mail me the info I can add it to the manual cradek
[15:07:27] <cradek> thanks, I appreciate that
[15:07:52] <BigJohnT> np, btw the goldwing got 40mpg on the last tank :)
[15:08:05] <cradek> I'm not sure I have the inspiration to do it right away... it will be interesting to see what comes up on the list when people try the new stuff
[15:08:23] <cradek> cool. how do you like it?
[15:08:31] <BigJohnT> love it :)
[15:09:00] <BigJohnT> it was 45°F this morning and all I needed was a jacket to be comfortable
[15:09:38] <BigJohnT> the heater is nice
[15:09:46] <cradek> does the fairing go down to your ankles? I had a bike like that and it was sure nice in the cold.
[15:10:00] <cradek> what kind of heater?
[15:10:10] <BigJohnT> yes, it goes all the way down and under the motor
[15:10:25] <cradek> it's nice to keep the wind off
[15:10:36] <cradek> my bike does not even have a windshield - it gets cold very fast
[15:10:37] <BigJohnT> heat from the engine, I have heat controls where I can have hot or cool air
[15:10:50] <cradek> heh, neat
[15:11:04] <cradek> I used to warm my gloves on the cylinder heads at stops...
[15:11:16] <cradek> but now I just drive my car! :-)
[15:13:34] <BigJohnT> is there anything besides coolant and spindle that can be turned on from mdi and will stay on with a run from line?
[15:25:52] <cradek> spindle, tool offset, loaded tool
[15:28:13] <jepler> digital inputs, analog inputs, and probing all get dummy or meaningless values with RFL
[15:33:14] <BigJohnT> so you can load a tool store a new offset then continue a program...
[15:34:44] <cradek> yes I think so
[15:36:13] <cradek> yuck, I still don't like this
[15:36:25] <cradek> N1 G1 X9 Y9
[15:36:31] <cradek> N2 G0 Z1
[15:36:41] <cradek> say N2 is a move to safety height
[15:37:20] <cradek> if I rfl N2 and the algorithm is (as currently) throw out motion from lines < N2, the first move I get is a move to X9 Y9 Z1, not a move from wherever I am straight up to Z1 as I expect
[15:39:21] <BigJohnT> i'm running 300 parts with a 120 second cycle so i'll drift back and forth to read
[15:41:51] <BigJohnT> that is what I was seeing a while back when I was trying to understand run from line
[15:48:51] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: eliminate "can't do that (EMC_TRAJ_SET_TELEOP_ENABLE) in auto mode with the interpreter idle" error when aborting during a fast move
[15:50:36] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: arg, remove debug messages
[15:52:37] <cradek> now I'm back to what I think is the right answer - just start executing at the specified line
[15:58:07] <BigJohnT> that makes more sense :)
[15:58:36] <cradek> well yes and no - I don't know if people will like it either
[15:58:46] <cradek> say you start on N1 in my example above
[15:59:08] <cradek> you will get "Cannot do g1 with zero feed rate" error because there is no F word
[15:59:25] <cradek> so you would have to do "F10" in MDI first, then it would do what you want
[16:04:58] <BigJohnT> if your setting other things in the mdi the F should not be a problem
[16:05:21] <cradek> that's what I think too
[16:05:31] <cradek> I'm having a hard time selling the idea to jepler
[16:05:55] <cradek> and if I can't sell it to him I doubt I can sell it to all the users
[16:06:38] <BigJohnT> LOL, or if an Fnn is in force don't wipe it out
[16:06:49] <cradek> but I now see there's a more fundamental problem with throwing out motions at the task level, which is something I hadn't noticed before.
[16:07:22] <cradek> BigJohnT: since the interpreter reads ahead, what's "in force" at the gcode level has nothing to do with the motion that's currently happening
[16:10:45] <BigJohnT> ok
[16:13:31] <BigJohnT> so feed rate will be just like spindle and coolant you have to "set" it from the mdi before rfl
[16:14:58] <cradek> in my proposed scheme, yes. also you would have to set g91, g93, g95, g21, g96, g18, anything else that's not the default
[16:15:31] <cradek> you could make the gcode "more restart-friendly" by putting those modal codes in places you might want to restart
[16:16:11] <BigJohnT> could this be somehow used with a manual tool change to allow you to jog around and then proceed once the tool is changed?
[16:16:14] <cradek> the docs that came with my HNC (paper tape based system) suggested this and calls those "safe restart" locations
[16:17:07] <cradek> BigJohnT: yes you could jog, and then continue at a safe entry point like an entry move from above the work
[16:19:50] <BigJohnT> I seem to see a lot of chatter about wanting to do that on cnczone
[16:20:48] <cradek> yeah.
[16:21:45] <BigJohnT> so with a planned stop you just have the restart line set any thing first...
[16:21:58] <cradek> yes
[16:22:05] <cradek> actually that would work pretty well today.
[16:22:21] <cradek> after a tool change you always have spindle on, safe entry moves, etc., anyway
[16:22:43] <cradek> with jeff's change where it remembers the executing line, it's easier to find the right place to restart - I like that
[16:26:10] <BigJohnT> cool
[16:30:48] <BigJohnT> so I see two reasons for restarting, 1 I hit the e-stop and 2 I planned to stop so I could change my tool to a different one... did I miss anything?
[16:31:24] <cradek> sure, planning to stop for other reasons
[16:31:27] <cradek> to measure something
[16:31:30] <cradek> to clear chips
[16:31:40] <cradek> to take a leak
[16:32:18] <BigJohnT> same difference if planned you put what is needed in the code to properly start back up right?
[16:33:13] <cradek> yeah I guess so
[16:34:17] <cradek> but say I have this code
[16:34:22] <BigJohnT> can you use a M code to pause the program now then restart?
[16:34:33] <cradek> G83 X.. Y.. R.. Q.. F..
[16:34:34] <cradek> X2
[16:34:34] <cradek> X3
[16:34:35] <cradek> X4
[16:34:37] <alex_joni> M2 or such I think
[16:34:51] <cradek> and I want to stop after the third hole and then restart
[16:35:14] <cradek> using my scheme I'm not even sure you can get into G83 mode with all those words set, without actually doing a hole
[16:35:17] <alex_joni> X4 won't mean anything by itself
[16:35:38] <cradek> if you were in G1 world, you could MDI G1 F10 and then rfl at X4
[16:35:45] <cradek> if in G83 world, maybe not so
[16:36:10] <cradek> "all axes missing with motion code" when I try g83 r.1 q.1 f3
[16:36:12] <alex_joni> that reminds me of the modal codes diff thingie
[16:36:27] <cradek> but 'g1 f3' works (no motion)
[16:36:36] <alex_joni> generate a line of modal codes that would be active if the program would actually run to here
[16:36:37] <cradek> maybe that (g83) could be fixed
[16:36:41] <alex_joni> and present that to the user..
[16:36:57] <alex_joni> the user can then copy/paste that to MDI
[16:37:31] <alex_joni> (doesn't fix the G83 thing you just said.. but would maybe improve user experience)
[16:38:12] <cradek> I guess I want functionality before I care about user experience
[16:39:41] <cradek> if G83 r.. q.. f.. is accepted (and sets those words but performs no motion) I think this problem is fixed (with my proposed rfl change)
[16:41:33] <BigJohnT> so you set a g83... from mdi and rfl at x3 if that's where you left off when your bit broke...
[16:41:46] <cradek> yes that would be the procedure
[16:42:00] <cradek> also S1000 M3 G90 G20 G17 or whatever else you need
[16:42:10] <cradek> ... if they are not the default
[16:42:48] <BigJohnT> that makes sense to me
[16:42:49] <cradek> or, if I want my code to be restart-friendly, I could put R.. Q.. F.. G17 G90 in all those lines
[16:43:05] <cradek> it's not like it will make the punch tape longer
[16:43:16] <BigJohnT> dang 120 second cycle times don't give me much time to chat
[16:43:20] <cradek> ha
[16:43:29] <cradek> GBTW!
[16:44:38] <alex_joni> gbtw?
[16:45:07] <BigJohnT> hey i'm getting my workout running back and forth
[16:45:09] <alex_joni> "Go blow the walrus."
[16:45:11] <BigJohnT> get back to work
[16:45:14] <alex_joni> :-P
[17:01:43] <BigJohnT> yea, my new welder is here :)
[18:07:21] <alex_joni> BigJohnT: cool
[18:16:19] <BigJohnT> miller 212 w/spoolgun
[18:29:20] <BigJohnT> it is quite a challenge to make and eat a sandwich in under 120 seconds :)
[19:04:35] <CIA-40> EMC: 03swpadnos 07TRUNK * 10emc2/src/emc/motion/control.c:
[19:04:35] <CIA-40> EMC: This should fix backlash correction when the error in both directions
[19:04:35] <CIA-40> EMC: have the same sign
[19:05:11] <cradek> holy cow, a commit from SWPadnos!
[19:05:17] <SWPLinux> heh
[19:05:20] <cradek> and yay, thanks for fixing that
[19:05:24] <SWPLinux> can someone else test please?
[19:05:37] <cradek> * cradek whistles
[19:05:40] <SWPLinux> it's even simple enough to backport to 2.2
[19:05:52] <SWPLinux> (simple enough for me to backport ;) )
[19:06:09] <cradek> nice
[19:07:40] <skunkworks> :)
[19:07:42] <SWPLinux> as soon as someone else confirms that this fixes the problem, I'll commit the change to 2.2
[19:16:35] <SWPLinux> does emcmodule.cc provide access to #variables?
[19:17:23] <SWPLinux> (doessomething else?)
[19:18:05] <SWPLinux> I was just lamenting the fact that we have no variable editor (while testing backlash using an nc file which used a variable)
[19:18:12] <cradek> emcmodule.cc is a python interface to nml
[19:18:22] <cradek> it doesn't have anything to do with internal interpreter state
[19:18:28] <SWPLinux> ok
[19:18:50] <SWPLinux> I think we've discussed making a uniform interface to variables, which NML isn't
[19:19:06] <SWPLinux> oh well. that's too much for this afternoon :)
[19:19:12] <cradek> you can set them with mdi
[19:19:46] <SWPLinux> I wanted to look at one, but I don't recall the correct MSG syntax to print values
[19:19:52] <SWPLinux> (I wanted to look more than edit)
[19:20:03] <cradek> to display them, you'd have to make a canon call whenever one changes, then queue that up with the motions and do something smart with the information later
[19:20:35] <cradek> http://www.linuxcnc.org/docs/devel/html/gcode.html
[19:20:57] <SWPLinux> or do something dumb like make them part of emcstatus or another (new) NML channel
[19:21:19] <cradek> I think you probably don't want the readahead values
[19:21:27] <cradek> it would not be very useful
[19:21:44] <cradek> (like the "active gcodes" readout)
[19:21:56] <SWPLinux> hmmm. yeah, we run into the same problems with machine vs. interpreter state
[19:22:31] <cradek> the queueing is always a problem
[19:22:44] <SWPLinux> maybe there should be two status channels - one for the machine and one for the interp
[19:22:55] <SWPLinux> machine being RT/motion
[19:23:55] <cradek> something to keep in mind for the great task rewrite
[19:24:07] <SWPLinux> yep
[19:24:15] <SWPLinux> EMC3
[19:24:18] <skunkworks> when the next revolution comes? ;)
[19:24:27] <SWPLinux> maybe the revolution after next
[19:24:39] <SWPLinux> wouldn't want to be too hasty
[19:25:08] <cradek> keep the motion controller, otherwise start over?
[19:25:24] <SWPLinux> something like that
[19:25:31] <SWPLinux> maybe dump the motion controller too ;)
[19:25:34] <SWPLinux> what the heck
[19:26:31] <cradek> good thing it's currently all working - if not, I sure wouldn't want to write it all
[19:26:47] <SWPLinux> heh
[19:27:22] <SWPLinux> I guess there are enhancements that could be made - more to allow support for loosely-coupled hardware rather than real TP changes
[19:27:49] <SWPLinux> there are probably other areas too
[19:28:15] <SWPLinux> oh right - jerk and snap limiting, real joint constraints ...
[19:28:47] <cradek> oh I didn't say it was done, I said it's working
[19:28:52] <SWPLinux> heh
[19:29:12] <SWPLinux> well, most of the system works, even though it's not done
[19:29:49] <SWPLinux> it would be interesting to have some support for a fourth axis that sometimes acts as a spindle (A=lathe/indexer)
[19:30:21] <SWPLinux> it's a relatively simple HAL setup, but I don't know how feedback fits in (since it would grow a lot in spindle mode)
[19:30:59] <SWPLinux> hmmm. maybe I can add index-like reset to stepgen in the next half hour
[19:37:22] <SWPLinux> I wonder what happens if you simply reverse motion when in cutter comp mode
[19:37:41] <SWPLinux> G41 / X3 / X4 / X3
[19:38:24] <SWPLinux> on one hand, it could make a nice half-circle
[19:38:34] <SWPLinux> on the other, it could be considered a concave corner
[19:53:14] <cradek> it will go around to the other side
[19:53:27] <cradek> I think
[20:30:54] <alex_joni> SWPadnos: that sure was a long commit :P
[20:48:03] <cradek> that's my kind of bugfix
[20:55:49] <alex_joni> yeah, and I'm sure that's lots of work behind a one-liner bugfix..