Back
[00:07:22] <tomp> some racks can use a single x and many y positions. most need the tool chuck to move away before any downward z motion is allowed. I do a lot of racks. a shuttle is rack that extends and retracts, i use pneumatics. a Zhi and Zontool is common. a tip/tilt switch is good for safety input. individual pod sensors is also nice.
[00:09:52] <tomp> the shuttle saves the work table/ tool travel ate up by racks
[00:44:16] <tomp> i even did a shuttling carousel that eliminated the intermediate arm like on the mazak. that method has a single xy but several tools appear there.
[02:59:25] <jepler> cradek: did you fix a bug regarding the position after toolchange if not all axis words were specified? I get this in 2.2.1, haven't tried with the tip of v2_1_branch yet.
http://emergent.unpy.net/index.cgi-files/sandbox/comp311_2_wrong_position_after_toolchange.png
[02:59:58] <jepler> er, the v2_2_branch of course
[03:01:18] <jepler> same behavior with tip of v2_2_branch..
[03:03:56] <jepler> huh, same behavior with TRUN
[03:03:57] <jepler> K
[03:04:06] <jepler> fix surprising move, after a tool change, when not all words were specified.
[03:04:12] <jepler> even though I have this patch (I assume anyway)
[03:05:06] <jepler> or is this the new, correct behavior...?
[03:05:52] <cradek> I think it works right now. I'm not sure what you're asking
[03:06:04] <jepler> did you look at the image?
[03:06:09] <cradek> doh
[03:06:17] <jepler> because the program never specifies Z, the part after the toolchange is at a different depth than the earlier part
[03:06:38] <jepler> I see now that this revision was before the branch, so it's no surprise the behavior is the same in both
[03:06:57] <jepler> but, is it the part program that is broken here?
[03:07:04] <cradek> yes IMO
[03:07:12] <cradek> if you don't specify Z, Z shouldn't move
[03:07:25] <cradek> to my thinking, that was the bug
[03:07:41] <cradek> after tool change you have to program a safe approach
[03:07:52] <cradek> often that would be an XY move then a Z move
[03:08:19] <cradek> the old behavior was that on that XY move, Z would also move, which I think is very wrong
[03:08:42] <jepler> The coordinate axes will be stopped in the same absolute position they were in before the tool change (but the spindle may be re-oriented). --
http://linuxcnc.org/docs/2.2/html/gcode_main.html#sub:M6:-Tool-Change
[03:09:28] <cradek> we departed from that wrong (IMO) behavior
[03:10:01] <cradek> In EMC2, the machine does not return to its original position after a tool change. This change was made because the new tool might be longer than the old tool, and the move to the original machine position could therefore leave the tool tip too low.
[03:10:07] <cradek> (10.1.1)
[03:10:31] <jepler> OK so that earlier item should just be removed
[03:10:34] <cradek> yes
[03:10:37] <jepler> got it
[03:10:41] <cradek> thanks
[03:10:43] <jepler> I'll fix that
[03:12:51] <CIA-19> 03jepler 07v2_2_branch * 10emc2/docs/src/gcode/main.lyx: update M6 to reflect implementation
[03:13:03] <CIA-19> 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: merge from branch: update M6 to reflect implementation
[03:14:00] <jepler> (first, no compensation so we can see the part outline)
[03:14:00] <jepler> +g0 z1
[03:14:00] <jepler> g0 x1 y5
[03:14:00] <jepler> +g1 z0
[03:14:09] <jepler> and make this modification to the comp3*.ngc files (two places)
[03:14:22] <cradek> great
[03:15:53] <jepler> hm that doesn't show the path I want in the preview
[03:15:59] <jepler> (with compensation)
[03:15:59] <jepler> t4 m6
[03:15:59] <jepler> +g0 z1
[03:16:09] <jepler> it looks like the preview shows XY motion during the added G0
[03:16:10] <cradek> the end of 9.4.3 is bogus
[03:16:45] <cradek> does the actual path not match the preview?
[03:16:58] <jepler> well there's the tool change in between so yeah it doesn't
[03:17:05] <jepler> if I remove m6 ...
[03:19:51] <jepler> it looks like it has something to do with tool change, not with cutter radius comp...
[03:20:07] <cradek> what exactly is wrong?
[03:20:37] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/comp311_2_strange_preview_move.png
[03:20:46] <jepler> the move should be in Z only, but the preview shows X and Y move
[03:21:04] <cradek> when you run it what happens?
[03:22:08] <jepler> it moves from the toolchange position down to Z1
[03:22:27] <cradek> huh
[03:24:30] <CIA-19> 03jepler 07TRUNK * 10emc2/nc_files/ (comp311.ngc comp311_2.ngc): add z moves so that the z position is defined, particularly after the toolchange
[03:24:56] <CIA-19> 03jepler 07v2_2_branch * 10emc2/nc_files/ (comp311.ngc comp311_2.ngc): merge from trunk: add z moves so that the z position is defined, particularly after the toolchange
[03:31:44] <CIA-19> 03jepler 07v2_2_branch * 10emc2/src/emc/task/emccanon.cc: fix for helical moves with helical component greater than zero but less than a silly threshhold (I hope this gets fixed in a better way on TRUNK, this is a band-aid)
[03:32:06] <cradek> ugh
[03:33:45] <jepler> I fear that my other fix (remove the 'if') will have the effect of applying the helical axis constraints to all axes so I chose this fix instead
[03:34:49] <jepler> er "applying the helical axis constraints to all arcs"
[03:35:10] <cradek> yeah
[03:35:21] <cradek> well if you tested it I'm happy
[03:38:15] <jepler> * jepler is running tort with constraints checking
[03:38:47] <jepler> it fixes the test case in
https://sourceforge.net/tracker/index.php?func=detail&aid=1834576&group_id=6744&atid=106744 and there's no constraint violation in tort so far
[03:38:54] <jepler> no obvious problems on any other program I ran
[03:39:04] <cradek> cool
[03:39:22] <jepler> if you have a really crazy Z axis setup (accel 1/1000 of the other axes, for instance) I bet you could get a constraint violation
[03:39:34] <jepler> for an arc that went just under the helical test threshhold
[03:40:00] <jepler> but that would be a crazy machine
[03:46:01] <cradek> you know, if we get joint limits in general working, all that stuff in canon could go away
[03:59:22] <CIA-19> 03jepler 07v2_2_branch * 10emc2/debian/changelog: new items fixed
[03:59:55] <jepler> my goal would be to make a release in the next week or so unless a new problem shows up
[04:00:42] <jepler> * jepler heads off for the night
[04:01:21] <cradek> goodnight
[11:02:00] <tissf> hello all
[11:06:11] <alex_joni> hi
[11:06:26] <tissf> Small problem:
[11:06:27] <tissf> 1) when I load gcode_main.lyx in lyx, tool_compensation.lyx is automatically loaded at the same time. It's good.
[11:06:29] <tissf> 2) cp gcode_main.lyx gcode_main_fr.lyx
[11:06:30] <tissf> 3) cp tool_compensation.lyx tool_compensation_fr.lyx
[11:06:32] <tissf> 4) I load main_gcode_fr.lyx in lyx, tool_compensation.lyx comes with.
[11:06:33] <tissf> Now my question, how to replace automatic loading of tool-compensation.lyx by the French version?
[11:08:41] <tissf> bbl
[11:26:01] <alex_joni> there is a \begin_inset Include \input{tool_compensation.lyx} inside.. you need to change that
[11:31:43] <tissf> It was thanks Alex :)
[11:36:40] <alex_joni> tissf: you usually can change it from the GUI too.. (it displays a button called Input, if you click that you get a dialog, where you can change the link)
[11:49:11] <tissf> Ok, I edited the file directly, and it works.
[11:51:06] <tissf> I am a second reading and I am done with this large piece :)
[11:51:59] <tissf> It's time to go eat bbl
[12:02:18] <alex_joni> wow.. that's a lot of translation :)
[12:32:32] <alex_joni> jepler: short bugreport (a user reports that stepconf doesn't properly use the ratio motor/pulley when you press test axis, but it does save the proper values for the config it generates, and that one works ok)
[13:14:27] <jepler> alex_joni: hm, either I don't understand what you're saying, or it doesn't do that for me
[13:15:35] <jepler> I entered some numbers for pulley ratio and clicked "test this axis"; the number shown for 'Axis SCALE' is the same as what 'halcmd show param' gives
[13:16:06] <alex_joni> jepler: sorry about not beeing more precise.. but it's a bug reported by a german user in the forum I "moderate"
[13:16:15] <alex_joni> http://www.peters-cnc-ecke.de/forumupload/uploadFiles/22791_115670400581_EMC2Config.jpg
[13:16:22] <alex_joni> maybe you can try with those numbers?
[13:22:03] <jepler> 4 float RW 18 stepgen.0.position-scale
[13:22:11] <jepler> looks like I incorrectly did some math as integers
[13:22:33] <jepler> or something...
[13:29:33] <jepler> but in newer CVS TRUNK I've completely broken step test :(
[13:32:03] <skunkworks696> join ubuntu
[13:33:11] <jepler> hi skunkworks696
[13:40:49] <skunkworks696> jepler: good morning
[13:42:32] <jepler> hm
[13:42:42] <jepler> * jepler notices that charge-pump isn't hooked up during axis test in stepconf
[13:43:35] <jepler> that would be important for users who need charge-pump!
[13:45:51] <skunkworks696> Hmm - I thought you had already fixed that..
[13:46:05] <skunkworks696> oh - axis test..
[13:46:15] <jepler> I fixed it in the final ini/hal files only
[13:46:21] <jepler> i forgot all about it when writing axis test
[13:56:00] <jepler> alex_joni: I believe that bug is fixed for the next release of 2.2...
[15:12:26] <alex_joni> jepler: cool.. thanks
[15:13:33] <jepler> thanks for the report
[15:13:39] <jepler> stepconf has so many bugs :(
[15:19:00] <alex_joni> you never tried emc in the early days :)
[16:27:36] <jepler> how early? I probably first became aware of emc in 2004, and it was pretty bad in those days
[16:27:48] <jepler> nearly impossible to build, hard to tune, etc etc
[16:28:55] <alex_joni> * alex_joni talks about 2001-ush
[16:28:58] <alex_joni> -ish
[16:29:10] <alex_joni> I first tried it in 2003 I think.. and it was bad
[16:29:20] <alex_joni> tooke me about 2 weeks till I could get it running
[16:54:51] <cradek> is anyone interested in real tool table overhaul? (gui editing through nml, offsets allowed in all axes)
[16:56:27] <alex_joni> * alex_joni is
[16:57:10] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Alex_Joni <- some todo's I have in mind
[17:01:30] <cradek> I don't understand your bullet #2 about offsets
[17:02:07] <cradek> those offsets are internal to the interpreter, which reads ahead etc
[17:04:00] <cradek> I don't see how you would tie them into nml/guis
[17:33:30] <alex_joni> I haven't really thought it through..
[17:33:48] <alex_joni> but maybe writing could be done only when not in Auto/running
[17:35:59] <cradek> I'm afraid people want to do things like change offsets using these variables. but doing that instead of using the gcodes is problematic in the interpreter.
[17:36:33] <cradek> it would be nice to know what TASK is difficult and "fixed" by having these numbers available, and then talk about how to make that task easier
[17:36:55] <cradek> it feels to me like one of those cases where what the user wants and what the user asks for (the first solution to come to his mind) might not be the same thing
[18:08:29] <alex_joni> I agree.. but I still don't like GUI's that try to read/write to config files directly
[18:26:07] <skunkworks179> skunkworks179 is now known as skunkworks_
[19:26:27] <cradek> alex_joni: I don't see how that follows from what I said, maybe I am missing something
[19:40:40] <laguille> i every one
[19:41:07] <jepler> hello laguille
[19:41:30] <laguille> hello jepler how are you?
[19:42:12] <laguille> i'm a newbee on this chanel,
[19:42:22] <jepler> welcome
[19:42:24] <jepler> I'm doing well
[19:42:44] <laguille> where are you from?
[19:43:11] <jepler> the channel #emc is also available, it's for questions about setting up and using the software. this channel is for more technical discussions.
[19:43:40] <jepler> I'm from Nebraska, USA.
[19:45:18] <laguille> ok i'will try, i'm from switzerland, what's your "contact?/implication... " whit EMC2
[19:46:22] <jepler> I'm a developer, and use it on a desktop milling machine.
[19:51:08] <laguille> nice to meet you, i start with cnc, at this time a am finishing the mecanic, the software emc2 is installed on a old pc since 1 year, i'm impatiant. but need to configure the ini file according to my machine and perhaps (for sure) i will find problems, (excuse for my english)
[19:52:11] <laguille> i'm so happy to find this irc channel [dtc] [dtc]
[19:52:36] <jepler> #emc is a better channel for questions about setting up and using the software.
[19:53:50] <laguille> i'will try but what's the "activity /number of person etc. " of this channel or of the #enc one?
[19:54:58] <jepler> there are a few dozen people on #emc
[19:55:00] <jepler> it is not too busy
[19:56:13] <laguille> thank you very much for your informations, i go in the emc channel, see you next time :-o
[19:56:16] <jepler> OK
[19:56:18] <jepler> nice meeting you
[22:22:57] <alex_joni> cradek: it doesn't relate quite directly
[22:23:07] <alex_joni> but it was one of the things that got me started..
[22:23:29] <alex_joni> I don't like the fact that some gui's (if not all) read teh tbl and var files directly
[22:27:50] <cradek> alex_joni: writing to the var file is bad. writing to the tool table file is fine (since emc proper doesn't write to it)
[22:28:27] <cradek> but, I'd like to fix tool table editing to be gui and work over nml
[22:28:34] <cradek> then we don't have to worry about changing the file format
[22:30:58] <alex_joni> yeah.. my ultimate goal is that the GUI can run mostly without a local ini
[22:31:14] <alex_joni> only a nml should be enough
[22:31:25] <alex_joni> (in a networked scenario..)
[22:31:47] <cradek> are you suggesting sending the entire gcode program over nml?
[22:32:07] <alex_joni> hmm.. no
[22:32:15] <alex_joni> I didn't figure out how to properly solve that
[22:32:27] <cradek> that's the biggest non-NML issue IMO
[22:32:33] <alex_joni> maybe send folder contents over nml to GUI to put in the open dialog D:
[22:32:50] <alex_joni> (that's whacky.. I know..)
[22:33:13] <alex_joni> anyways.. gotta catch some sleep, my flight is pretty early
[22:33:21] <alex_joni> (at least early for me)
[22:33:28] <alex_joni> good night all
[22:34:13] <cradek> goodnight, have a safe trip
[22:34:44] <alex_joni> thx, I think I'll be online from there
