Back
[00:49:36] <cradek> I still haven't needed to learn that trick...
[00:52:11] <cradek> I like how I can have private development that I can push/pull around and interact with as branches
[02:28:23] <skunkworks> http://juve.ro/blog-files/puma/puma-tux2.jpg
[02:29:16] <skunkworks> shouldn't the cone in the preview be pointed the arm?
[02:29:27] <skunkworks> lets try that again
[02:29:35] <cradek> ?REDO FROM START
[02:29:57] <skunkworks> shouldn't the cone in the preview be pointed the same as the end joint?
[02:30:02] <skunkworks> or close to it?
[02:30:07] <cradek> but yeah, I wonder if a different GEOMETRY setting would fix it?
[02:30:55] <skunkworks> I have only played with it a little bit but the cone doesn't make sense to me most of the time. (but that might just be me)
[02:30:57] <skunkworks> ;)
[02:31:05] <cradek> huh, you have all of ABC - wonder what that means
[02:31:16] <cradek> obviously I'm not going to be any help
[02:31:36] <skunkworks> heh - it is 6 joints - should give you 6 degrees of freedom
[02:32:15] <skunkworks> press redo or back
[02:32:19] <skunkworks> ;)
[02:34:43] <skunkworks> ^ come on now - that is a TI99/4a reference...
[02:37:22] <cradek> huh, I don't remember it
[02:37:26] <cradek> I never actually owned one of those things
[02:37:37] <skunkworks> really? I thought you liked parsec?
[02:37:38] <cradek> but I played parsec, and that's what they were good for
[02:37:44] <skunkworks> heh
[02:37:58] <skunkworks> in most games - that was the prompt after you lost..
[02:39:31] <skunkworks> frozen sweet cherries are the best thing ever..
[02:40:03] <skunkworks> cradek: did you get the oiling straitened out?
[02:40:04] <cradek> no, risotto with asparagus
[02:40:16] <cradek> (no I don't know why I want that right now)
[02:40:24] <cradek> but man would it be good
[02:40:33] <skunkworks> heh
[02:40:34] <cradek> yes I think the lube system is fully working now
[02:40:54] <cradek> I bet it has not run long enough to fill all its lines, but the nozzles are all flowing
[02:41:05] <cradek> I need to get a gallon of lube - I'm out
[02:41:20] <cradek> stuart says I should use "triway" instead of vactra2
[02:41:30] <skunkworks> one of our favorite dishes right now it baked salmon over sweet pototatos/onion and asparagus
[02:41:35] <cradek> it's a synthetic with detergent that's not supposed to plug the nozzles
[02:41:58] <skunkworks> neat
[02:42:13] <cradek> without the fish that sounds delicious! but can I have risotto too?
[02:42:20] <skunkworks> ;)
[02:42:45] <cradek> you have to put the parmesan and butter in at the end, you know
[02:43:11] <skunkworks> I think that makes most everthing taste good
[02:43:19] <cradek> I bet you're right
[02:45:41] <cradek> jeff and I cut arcspiral on jr last night - another nice test
[02:46:01] <skunkworks> we made baked zuccini fries recently also - egg/bread crumbs/parmesan
[02:46:02] <cradek> I'm still not happy with the Y amp's tuning - it just isn't as smooth as the other two
[02:46:14] <cradek> (velocity loop - tuning on the amp, not emc)
[02:46:25] <skunkworks> did you switch it out - to see if it travels?
[02:46:48] <cradek> no, unfortunately it's a lot of work
[02:46:53] <skunkworks> yeck
[02:47:28] <cradek> it doesn't help that I don't have good information for the amps - I've just had to figure most of it out
[02:47:53] <skunkworks> seems you did pretty good ;) from what I hear
[02:47:54] <cradek> there are jumpers that add or remove series caps for, uh, some tuning parameter
[02:47:58] <skunkworks> heh
[02:48:06] <cradek> I think it's velocity loop gain
[02:48:27] <cradek> but it seems to interact with a knob, maybe moving a resonance point around? hard to tell exactly.
[02:48:49] <skunkworks> you will figure it out
[02:49:06] <cradek> some is obvious - tach input gain, balance, etc
[02:50:28] <skunkworks> hmm - now on to the red rasberries. The will go bad if I don't eat them....
[02:50:53] <cradek> poor you, with such a burden
[02:51:02] <skunkworks> well - what can I do?
[02:54:25] <skunkworks> (I think csa's are the best thing ever.)
[02:57:51] <cradek> yep, they're pretty neat
[02:58:07] <cradek> we're growing enough this year that we didn't sign up though - I miss getting the oddball stuff
[02:58:41] <skunkworks> that is great
[02:59:06] <skunkworks> we are going to have a ton of tomatoes and mother hubbord squash
[02:59:43] <cradek> making all our own bread now too
[02:59:57] <cradek> the problem with the csa is when it ends, it's so hard to go back to "normal" food
[03:00:04] <skunkworks> wow - cool - do you have your own yeast starter?
[03:00:18] <cradek> uh what did we used to eat ?? let's open this ... can of beans
[03:00:27] <skunkworks> heh - yah
[03:00:51] <skunkworks> we have a local coop that usually has some pretty good produce.
[03:01:02] <cradek> bill makes it - it's yeasted, not sourdough - but he does a slow rise, sometimes for days, which gives it a deep flavor like some sourdoughs have
[03:01:30] <skunkworks> mmmm. We try not to eat bread... (I miss it)
[03:01:37] <cradek> latest one has walnuts and honey in it - wow it's good
[03:01:44] <cradek> uh-oh, I'll stop talking about it then
[03:01:49] <skunkworks> heh
[03:01:59] <cradek> bread is a primary food around here
[03:02:18] <cradek> I really can't imagine following a diet without it
[03:02:22] <skunkworks> heh
[03:02:43] <skunkworks> it seems to convert to fat instantaniously here
[03:03:03] <cradek> there's worse things than being fat and happy
[03:03:35] <cradek> I just noticed jr was shipped here 1 month ago
[03:03:48] <cradek> that's a pretty good retrofit time, considering all the major problems
[03:04:05] <cradek> maybe I could have done it in two weeks if it was originally a running machine
[03:04:13] <cradek> (that's just evenings/weekends of course)
[03:04:14] <skunkworks> ah - yes. very good. I think you could do it for a living :)
[03:04:48] <skunkworks> although everyone would want mach. emc? what is that? ;)
[03:05:11] <cradek> heh yeah, all I'd need would be 320V-capable gecko step/dir drives
[03:05:19] <skunkworks> heh
[03:05:30] <cradek> and it would perform GREAT
[03:05:33] <cradek> :-P
[03:06:20] <cradek> actually I doubt anyone wants mach - and they also don't really want emc either
[03:06:37] <skunkworks> stuart must be odd. ;)
[03:06:47] <cradek> nobody wants a keyboard and mouse on their cnc (and I don't either)
[03:07:11] <cradek> sure - just ask him
[03:07:31] <skunkworks> we have a brand new (well a year or 2) centroid machine. keyboar and mouse.
[03:07:36] <skunkworks> keyboard
[03:07:53] <cradek> I shouldn't say "nobody" - people who say "nobody wants" or "everyone wants" are going to continue on to tell you something that's not true
[03:08:10] <cradek> huh.
[03:09:07] <cradek> I've never seen/used a centroid
[03:09:23] <skunkworks> neiter have I
[03:09:24] <skunkworks> ;)
[03:09:38] <cradek> they're a polished pc retrofit right?
[03:09:43] <skunkworks> (I don't have to deal with that department.)
[03:09:50] <skunkworks> yes
[03:10:01] <skunkworks> it is running some form of linus
[03:10:03] <skunkworks> linux
[03:10:13] <cradek> heh, isn't everything
[03:10:28] <skunkworks> almost everything. (except microsoft)
[03:10:35] <skunkworks> even apple now ;)
[03:11:02] <cradek> I remember it leaked that microsoft uses macs in their artwork dept
[03:11:05] <cradek> so they're probably using linux too
[03:11:11] <skunkworks> heh
[03:11:49] <skunkworks> oh well - I should go to bed.
[03:11:50] <skunkworks> night
[03:11:54] <cradek> me too
[03:12:05] <cradek> future-me will like past-me (now now-me) better if I do
[03:12:32] <skunkworks> heh
[08:55:53] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[09:39:50] <micges_work> hello
[09:50:06] <micges_work> I would like to consider this patch:
http://www.pastebin.ca/1542986
[10:17:19] <alex_joni> micges_work: looks ok, there is one thing I don't understand
[10:17:27] <alex_joni> line 25, 26 in that diff
[10:17:48] <alex_joni> -extern int emcTaskPlanRun(int line);
[10:17:49] <alex_joni> +extern int emcTaskPlanRun();
[10:18:01] <alex_joni> was emcTaskPlanRun(int line) used before?
[10:38:38] <micges_work> alex_joni: function was only defined in emc.hh
[10:38:53] <micges_work> another some old code
[10:42:51] <micges_work> alex_joni: I think its relic prototype from emc1
[10:49:23] <alex_joni> then it's ok
[10:51:13] <micges_work> cool
[10:57:36] <alex_joni> at least I don't see how it could affect anything
[10:57:46] <alex_joni> and it allows some flexibility for the user
[10:59:10] <CIA-8> EMC: 03micges 07master * r6b573c27271a 10/src/emc/ (6 files in 3 dirs): * Add new [RS274NGC]RS274NGC_RUN_CODE inifile option, gcode executed before RUN command
[10:59:38] <micges_work> if option is not defined there is no change in functioning
[11:00:48] <micges_work> alex_joni: flexibility without afecting anything was the goal ;)
[11:00:59] <jthornton> what does the option do?
[11:02:08] <micges_work> when you set M4 in options then EMC will execute it after you press start and before actually start running program
[11:02:49] <micges_work> when you set it to 'G4 P10' then every start of program will be delayed 10seconds
[11:03:39] <jthornton> cool
[11:06:39] <jthornton> so your ini entry would look like RS274NGC_RUN_CODE = G4 P10
[11:07:02] <jthornton> can you have more than one g code on the line?
[11:07:38] <micges_work> it must be one valid gcode line, so no repeated G0 and such
[11:09:09] <jthornton> ok
[11:09:15] <micges_work> jthornton: general gcode writing rules apply for this option
[11:10:12] <jthornton> thanks
[11:30:23] <alex_joni> micges_work: when I think of it some more, I think another functionality would be even better
[11:30:52] <alex_joni> hmm.. maybe not
[11:30:58] <alex_joni> I'm thinking about restart from line
[11:31:35] <alex_joni> say you run through the program in simulation mode, and register the mode changes up to the line where the user wants to start from
[11:32:14] <alex_joni> then issue a call to execute those mode changes before actually running from that line
[11:32:27] <alex_joni> (like: M6 T15,
[11:32:32] <alex_joni> M3 S1200
[11:32:34] <alex_joni> G21
[11:32:37] <alex_joni> etc..)
[11:32:52] <alex_joni> not sure you can put them all on one line
[11:33:13] <micges_work> you can't put them all in one line
[11:34:01] <micges_work> but my next could be to allow RS274NGC_RUN_CODE to be not inifile line but a file or such
[11:34:18] <alex_joni> right
[11:34:20] <micges_work> and task could write mode changes to that line after stop
[11:34:22] <alex_joni> that's what I was thinking
[11:34:28] <alex_joni> s/line/file/
[11:34:55] <micges_work> yes
[11:35:09] <SWPadnos> that would go 90% of the way to having "perfect" run from line
[11:35:33] <micges_work> hard task is to define model to mode changes recording
[11:35:33] <SWPadnos> there are still cases where the machine can't be automatically put into the right state, such aas when people use custom M codes
[11:36:54] <micges_work> SWPadnos: I think there always be some odd cases ;|
[11:37:36] <SWPadnos> you don't need to record them all, only two things per modal group - a flag indicating whether this group has changed and the current state of that group/item
[11:37:38] <SWPadnos> yeah
[11:38:12] <micges_work> that info should be get from interp
[11:38:24] <micges_work> will be a lot easier
[11:40:21] <micges_work> SWPadnos: mode change recording can only works when goto last running line will be done, or will be useless
[11:41:06] <SWPadnos> I'm not sure I understand
[11:41:56] <micges_work> say you have 2d laser, you stop milddle of line, jog some to see how burning is doing an then you restart last stopped line, without goto last running position task will enable spindle(beam) on current position
[11:43:47] <SWPadnos> oh, yes, that could be a problem ;)
[11:44:29] <SWPadnos> it seems that most of the time, you would want to restart from where you stopped, or from the beginning of some move before the stop point
[11:45:17] <micges_work> I think not
[11:45:59] <SWPadnos> depends on whether you have a laser, mill, plasma, EDM ...
[11:46:32] <SWPadnos> oh - I meant that the machine would need to start changing modes at a well-known point, not "wherever it is"
[11:47:13] <micges_work> yes
[11:47:58] <SWPadnos> so the "best" thing to do is to have a setting that tells EMC2 what to do :)
[11:49:18] <SWPadnos> or more likely, several settings
[11:50:26] <SWPadnos> changing machine state is one group of options (should the spindle be left as is or changed? what about moving back to the stop point, how about coolant or tool numbers, re-read offsets? ...)
[11:50:49] <SWPadnos> err - I meant to leave motion out of that list
[11:51:09] <SWPadnos> because "where to restart" is another option or set of options
[11:51:37] <jepler_> hm, where's the buildbot's irc presence?
[11:52:19] <SWPadnos> good question
[12:09:50] <jepler_> Comments?
http://emergent.unpy.net/files/sandbox/0001-remove-milltaskcanon-nobody-uses-it.patch
[12:10:45] <SWPadnos> hmmm
[12:10:51] <SWPadnos> is it usable?
[12:10:58] <micges_work> it was usable?
[12:11:05] <SWPadnos> (ie, has it been maintained)
[12:13:18] <jepler_> it looks like it's received a bare minimum number of commits in order to keep linking
[12:13:27] <jepler_> I doubt (but don't have any actual evidence) that anybody uses it
[12:14:03] <jepler_> I have no idea whether it works usefully now
[12:15:34] <CIA-8> EMC: 03bigjohnt 07master * ra8f84b4e6401 10/docs/src/config/ini_config.lyx: Add RS274NGC RUN CODE to manual
[12:16:10] <jthornton> breakfast time :)
[12:17:17] <SWPadnos> theoretically, you should be able to run G-code through SAI and run the SAI output through canterp to actually control the machine
[12:17:22] <SWPadnos> (right?)
[12:17:25] <jepler_> as far as I can tell it doesn't work -- if you MDI STRAIGHT_TRAVERSE(1, 1, 1, 0, 0, 0, 0, 0, 0)
[12:17:30] <jepler_> or run it in a part program, nothing happens
[12:17:47] <jepler_> SWPadnos: that's the idea of milltaskcanon, yes
[12:18:35] <SWPadnos> well, I think I'd like to keep it, just in case someone wants to fix it up and use it :)
[12:18:56] <jepler_> that's what the history is for
[12:19:19] <jepler_> "oh yeah, I think that existed back in 2009 or so" we'll say to the nut in 2015 who wants it
[12:19:34] <SWPadnos> it may be a better intermediate language for something like a standalone STEP interpreter, or even for custom profile-generating code
[12:19:37] <jepler_> but in the meantime we didn't spend 6 years incrementally wasting everyone's time who is busy adding new actual features
[12:19:37] <SWPadnos> heh, well there is that
[12:20:05] <SWPadnos> but incremental time-wasters are more efficient - nobody notices that the time is being wasted until it's too late :)
[12:30:04] <skunkworks_> http://www.cnczone.com/forums/showthread.php?t=84346&page=4
[12:35:58] <alex_joni> jepler_: the runtests use only SAI ?
[12:37:28] <alex_joni> hmm.. that link from skunkworks_ looks a lot like an AXIS running on doze
[12:37:35] <alex_joni> http://www.cnczone.com/forums/attachment.php?attachmentid=87378&d=1251287833
[12:37:57] <SWPadnos> complete with icons
[12:38:05] <SWPadnos> I was wondering where the source code is ...
[12:38:08] <jepler_> alex_joni: yes
[12:39:53] <alex_joni> I think milltaskcanon was added only 2-3 years ago to emc2, it did exist a long time ago in emc1
[12:40:02] <alex_joni> maybe mshaver was it that requested it
[12:42:03] <jepler_> commit 246a07cedfdfeb9eb4ecc9e367b10323f9a19f01
[12:42:03] <jepler_> Author: Fred Proctor <proctor@users.sourceforge.net>
[12:42:03] <jepler_> Date: Thu Apr 28 13:24:41 2005 +0000
[12:42:03] <jepler_> Added canonical interpreter directory
[12:43:06] <jepler_> emc1 had canterp.cc
[12:43:18] <alex_joni> jepler_: I know that..
[12:45:22] <jepler_> bbl
[12:47:09] <skunkworks_> and my ball in cage gcode. ;)
[13:11:03] <skunkworks_> alex_joni: is the cone in the axis window orentated right?
http://juve.ro/blog-files/puma/puma-tux2.jpg
[13:11:13] <skunkworks_> * skunkworks_ is a bit lost.
[13:18:18] <alex_joni> skunkworks_: nope ;)
[13:18:29] <alex_joni> it's not
[13:18:47] <alex_joni> but since you have all 3 rotations, it's quite hard to define how the tool should be oriented
[13:19:26] <alex_joni> I think AXIS does rotate by A around Ox, then (along the newly rotated plane) rotate by B around Oy
[13:19:35] <alex_joni> then rotate by C around Oz
[13:19:55] <alex_joni> and the output from emc2 should be rotate around ABC without changing the rotation planes
[13:20:15] <alex_joni> ^^^ just a guess
[13:20:31] <skunkworks_> ok - I don't feel bad that I am confused ;)
[13:21:17] <alex_joni> don't feel.. this is easily confusing
[13:21:19] <alex_joni> ;)
[13:39:30] <micges_work> alex_joni: what do you think about idea to add param to RUN command (beside line_nr) to specify if RUN it from begin or from last runned point or from current point
[13:39:32] <micges_work> ?
[13:40:04] <micges_work> alex_joni: beside of functionality RS274NGC_RUN_CODE
[13:41:05] <cradek> micges_work: can you describe in more detail what you mean?
[13:42:01] <micges_work> cradek: did you follow earlier discuss?
[13:42:57] <cradek> no, I will read back
[13:45:14] <cradek> ok yes
[13:45:19] <micges_work> so in addition to mode switch recording, file RS274NGC_RUN_CODE.NGC that can be edited at any time (because could be readed in in RUN command)
[13:46:55] <micges_work> run command can have additional parameter sended to task to let it know how (if any) emc must move before rfl
[13:47:01] <cradek> I think RUN_CODE is a very poor way to fix this
[13:47:22] <cradek> if you want to make rfl smarter, that is not the way to start
[13:47:24] <micges_work> if no param is set, emc will run as it is now
[13:47:41] <cradek> yes I read that
[13:47:54] <SWPadnos> run_code and end_code are good ideas, but not for RFL
[13:48:13] <cradek> I disagree
[13:48:14] <SWPadnos> they would complement the existing RS274NGC_STARTUP_CODES
[13:48:26] <micges_work> no no
[13:48:33] <cradek> they hide gcode that should be in the part program
[13:48:55] <SWPadnos> well, that seems to be true, but there are many machine types
[13:49:15] <micges_work> each machine have gcode that must be always executed before rfl
[13:49:15] <SWPadnos> in some cases, there may be a need to sequence power or hydraulic systems before running a program
[13:49:27] <SWPadnos> and similar needs at shutdown/program end
[13:49:29] <micges_work> so that gocde goes to RUN_CODE
[13:49:44] <micges_work> so that goes to END_CODE
[13:50:09] <micges_work> also each machine must (could) move to last point before rfl
[13:50:30] <SWPadnos> I can imagine needing certain things to happen when you use RFL, but I don't know that a static set of codes is the answer
[13:50:36] <cradek> what is "last point" and how does it move there?
[13:50:37] <micges_work> that will be discovered by GUI and append to RUN command
[13:51:02] <cradek> if we want a smarter rfl I'd like to see a full plan and spec that we could discuss
[13:51:10] <SWPadnos> agreed
[13:51:28] <cradek> I see these little hacks that we (many of us, not just this change) keep putting in as an obstacle to actually fixing it
[13:52:17] <cradek> some actual fixes have been mentioned on the list, such as letting the user save a set of return points
[13:52:55] <cradek> there are possibly some real coherent solutions - RS274NGC_RUN_CODE.NGC doesn't look like one of them to me
[13:53:32] <SWPadnos> "little hacks" is the MO with the whole project really. most of the time, people glaze over when we start discussing future plans or designs, or come back with retorts like "who's going to write it"
[13:53:45] <SWPadnos> (that's an observation, not a condemnation)
[13:53:50] <SWPadnos> (well, maybe a little condemnation)
[13:54:03] <cradek> in general, the spec writer has to be willing to write it
[13:54:09] <cradek> the spec is a way to get others not to complain
[13:54:12] <SWPadnos> heh
[13:54:21] <cradek> ken L did this with several major gcode changes, and it was very effective
[13:54:29] <SWPadnos> I hadn't really thought of it that way before :)
[13:54:36] <cradek> people had good ideas and the entire plan was improved, then he did it
[13:55:21] <cradek> but I agree that's not how it often works
[13:55:39] <cradek> but for a big hotly-debated change, it probably should be
[13:57:00] <cradek> putting M3 in the ini file so the spindle comes on when you run is a very shortsighted and inadequate solution to the problem of resume not starting the spindle
[13:57:26] <cradek> it MAY be ok for micges's plasma machine, but on my lathe, what speed does the spindle run? Does it run in CSS mode?
[13:57:42] <cradek> it does not come close to solving the stated problem
[13:59:02] <cradek> but it is a hack that, if people start using it, will be an obstacle to a proper fix - because we won't want to break their existing functionality, no matter how bad it is
[14:00:50] <cradek> SWPadnos: your idea of keeping machine state (spindle speed, fwd/rev, css mode) is much closer to solving the problem - when you combine it with return points or some other safe-reentry scheme
[14:01:10] <cradek> I am the only one talking
[14:01:23] <cradek> also, I need breakfast - bbl.
[14:01:43] <SWPadnos> sorry - wife interrupt
[14:02:01] <jepler_> that one's non-maskable
[14:02:06] <SWPadnos> indeed
[14:02:09] <SWPadnos> and highest priority
[14:02:34] <SWPadnos> regardless of execution ring
[14:02:56] <micges_work> heh I'm scared ;)
[14:03:53] <micges_work> going home, bbl
[14:07:59] <jepler_> mshaver: do you use, or know anyone who uses, milltaskcanon? alex_joni thought maybe it was there for your sake.
[14:11:28] <SWPadnos> hmmm. is git.linuxcnc.org slow for others or is it just me? (using gitweb)
[14:12:16] <cradek> my line is a little slow right this second
[14:12:21] <SWPadnos> ok
[14:15:42] <CIA-8> EMC: 03jepler 07master * rbaadf6423c82 10/docs/src/config/ini_config.lyx: Revert "Add RS274NGC RUN CODE to manual"
[14:15:42] <CIA-8> EMC: 03jepler 07master * rbdc5c7b6aeca 10/src/emc/ (6 files in 3 dirs): Revert "* Add new [RS274NGC]RS274NGC_RUN_CODE inifile option, gcode executed before RUN command"
[14:15:43] <CIA-8> EMC: 03jepler 07master * rb131c826af68 10/src/emc/nml_intf/emc.hh: remove prototype for function that is not defined
[15:09:31] <micges> logger_dev: bookmark
[15:09:31] <micges> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-08-26.txt
[15:14:45] <mshaver> jepler: not off hand, looking at canons now...
[15:38:34] <mshaver> jepler: I _think_ it's used by "canterp", the canonical interpreter. If you were to put [TASK] TASK = milltaskcanon in your .ini file, you would have a machine that ran on an input file of canonical commands, rather than g-code. I've personally never tried it, but that's the theory. There is also somewhere a STEP interpreter version of the task planner.
[15:45:52] <jepler_> yeah, I know what it is; I just doubt if anyone uses it
[15:45:58] <jepler_> it didn't seem to work when I tried it, actually..
[16:32:45] <mshaver> jepler: It doesn't surprise me. it's probably bit rotted...
[16:33:44] <mshaver> jepler: I don't think anyone uses it, but it might have tutorial value. I don't know, it's a subject for discussion!
[16:34:40] <mshaver> jepler: One other thing, now that we use milltask for both mills and lathes, maybe it should be called emctask, gentask. etc?
[16:57:14] <alex_joni> mshaver: actually it should get rewritten ;)
[17:20:32] <micges> on wiki, pages that describing problems/ideas that was already or partially added/resolved in emc2, can I delete content or tagged it as a Implemented only ?
[17:21:16] <cradek> sure
[17:21:51] <micges> sure what? tagged it or delete it?
[17:22:23] <cradek> micges: I hope you did not feel like I was picking on you earlier. I think you only made the mistake that we all make sometimes, of not knowing whether a certain change is best kept for your own setup only, or appropriate for everyone
[17:23:08] <cradek> I'm not sure about tag or delete
[17:25:45] <micges> cradek: no problem
[17:27:09] <micges> cradek: can you specify your lathe approach to rfl problem?
[17:28:11] <cradek> sure
[17:28:57] <cradek> after every tool change in the program, I put all modal g codes including spindle commands. then there are safe entry moves to the work from tool change position. When I need to restart a program, I start at one of these tool changes, which are always safe starting points
[17:29:16] <cradek> I do the same on the mill
[17:29:57] <micges> cradek: when you brake tool in the middle?
[17:30:53] <cradek> I don't seem to have that problem much, and when I do, it is no trouble to re-run all of that tool's path
[17:31:07] <cradek> I seem to use each tool only a little bit in my kind of work
[17:31:10] <micges> ok
[17:31:33] <micges> now my approach ;)
[17:31:45] <cradek> if I am drilling a large deep hole I sometimes need to clear chips. It is usually using a drill cycle. I feed hold or pause when the drill is out
[17:32:04] <cradek> then I turn spindle override to zero which stops the spindle. I clear the chips, then turn spindle back up to 100%, then resume
[17:32:37] <cradek> since it is a drill cycle, you can't use rfl anyway to start in the middle of the operation
[17:32:51] <SWPadnos> speaking of lathe work, I'll get a local friend to do that threading - thanks for the offer (or acceptance of my request :) )
[17:33:04] <cradek> sure, no problem
[17:33:08] <cradek> local is nicer - no shipping
[17:34:36] <micges> my side, mill: often files have 75.000 up to 150.000 lines of gcode, one program can be runned for 3 days, I'm generating this gcode from dxf files, I can't add any safe points
[17:35:23] <cradek> you could if you wanted :-)
[17:35:35] <cradek> but yes that sounds very different from my kind of work
[17:35:51] <micges> laser: must be perfectly smooth and straight burned, up to 100 times start->stop->jog->see what happens->rfl
[17:37:32] <micges> up to 20000 lines, can be rfl on g0 lines, but then operator must have spindle on switch all time in one hand (can't be 2 times burned in one place)
[17:38:52] <cradek> you could put m3 after every g0 then?
[17:39:07] <micges> I have few oxygen cutters and plasma, they act like laser mostly
[17:39:13] <jepler_> how many meters of burn in one part, if it runs for 3 days? .5km?
[17:39:42] <micges> jepler_: that on mill
[17:39:47] <micges> that's
[17:40:07] <jepler_> (that's based on 100mm/min which seems like a low-end estimate..)
[17:40:41] <micges> often < 60mm/min
[17:40:51] <micges> very hard steel
[17:41:12] <micges> about 0.02 deep in one cycle
[17:42:32] <micges> cradek: on laser it is m3,g4p0.1,g1,m5,g0 cycle
[17:43:33] <micges> (g4 it's laser inertia)
[17:45:16] <micges> lastly I have file that gcode generated from was about 250k of lines..
[17:46:30] <micges> so there is no place to enter gcode manually and rfl manually.. that's main difference between our approach to some functionality ;)
[17:54:17] <jepler_> micges: you asked a question about the wiki earlier. If it's a page that was written about a feature that has since been added and documented, the page can be replaced by a link to the html documentation for the feature.
[17:54:41] <jepler_> I'm not sure if that answers your question.
[17:55:14] <micges> jepler_: ok
[19:40:12] <micges> good night all
[20:37:48] <CIA-8> EMC: 03mshaver 07master * rc8d5c9210101 10/configs/smithy/622.ini: fix a numerical error in a comment
[21:23:10] <robh_> hi all, i looking at fitting a twin turret lathe out with EMC, has top slide turret with Z & X no problem, then i have a bottom turret with is just a 2nd Z if u like no X, will EMC let me control this bottom turret with tool lengths applied to it for drilling etc
[21:25:12] <cradek> afraid not directly - the most obvious thing to call the bottom would be W
[21:25:22] <cradek> but you cannot have Z and W tool offsets simultaneously
[21:25:44] <cradek> however, you could just offset W in your coordinate system instead
[22:43:55] <robh_> sorry cradek had to pop out for abit, i dont mind what bottom is called in terms of axis word, and i will not need to use both at the same time
[22:45:17] <robh_> bottom turrnet has got room for 8 tools all i was going to do was split T1-8 top turret, T9-17 bottom
