Back
[00:25:49] <jepler> jmkasunich: emc doesn't do any special treatment of "cyclic" axes, like abc on some machines. actually, I recently removed some related code that was disabled
[00:26:41] <jepler> (most people seem to want something other controls do, not the thing I dreamed up that seemed saner)
[00:27:40] <jmkasunich> I think I may be confused by something I read in the docs about arc moves - they _are_ limited to +/- 360 degrees
[00:27:52] <jmkasunich> although I don't see how you could request more than that in g-code anyway
[00:28:20] <jepler> yeah G2/G3 can't do more than a full circle
[00:28:36] <jepler> you can program A3600 and if you're at A0 and it's within your limits, you'll get 3600 degrees of motion
[01:33:43] <jmkasunich> cradek: we need a vismach version of max5, with the right limits and such
[01:44:18] <jmkasunich> the 5axis sim config won't accept g-code with u and v words
[01:44:36] <jmkasunich> didn't you write kins that would accept those coords?
[01:45:08] <SWPadnos> there needs to be a "limit=none" option in the ini file
[01:45:27] <SWPadnos> or something like jepler's modulo joints
[01:47:15] <jmkasunich> well, that I can work around
[01:47:18] <jmkasunich> just set them big
[01:48:44] <SWPadnos> oh - I missed the line about U and V words :)
[01:49:22] <jmkasunich> I think his kins can deal with u and v, maybe all I need to do is change some inifile stuff
[01:51:07] <SWPadnos> oh look at all the extra stuff now :)
[01:51:09] <SWPadnos> oops
[01:51:50] <jmkasunich> well, it accepts the uv g-code now, but it doesn't do the right thing when u and/or v are non-zero
[01:52:34] <jmkasunich> I thought cradek had that working, but I could be mistaken
[01:52:44] <jmkasunich> or it could be a differnent kins file
[01:54:25] <SWPadnos> dunno
[01:55:00] <jmkasunich> ah, there is a maxkins.c
[02:09:39] <jmkasunich> wtf - it simply passes u/v/w on to joints 6/7/8
[02:09:47] <jmkasunich> max doesn't have those joints
[02:11:42] <jmkasunich> * jmkasunich waits for cradek
[02:11:46] <jepler> as I suspected, a big fraction of bugs in the offset path that offs would make was because arc endpoints were wrong by more than a tiny amount. fixed that problem:
http://emergent.unpy.net/index.cgi-files/sandbox/offs-one-more-bug-fixed.png but there are still bugs left:
http://emergent.unpy.net/index.cgi-files/sandbox/offs-at-least-one-bug-left.png
[02:13:10] <jmkasunich> neat
[02:14:12] <jmkasunich> that blue circle in the bug image - is that a circle in the output of offs?
[02:14:17] <jepler> yes
[02:14:21] <jmkasunich> oops
[02:14:31] <jepler> the bug I'm chasing now causes a 360 degree circle to get added where there should be none
[02:14:55] <jepler> I suspect that it is a circle that should actually be zero degrees but I'm not 100% sure
[02:16:13] <jepler> no, that doesn't seem so likely -- the path inset just a bit less has the same number of circles
[02:17:23] <SWPadnos> wrong "polarity" - ie G2/G3 improperly chosen?
[02:17:52] <SWPadnos> is that little triangle a crossover or a small void remaining after a big offset?
[02:18:44] <jepler> the little triangle is a small void remaining -- it's right, I think
[02:18:57] <jepler> the bug is the circle, and it looks exactly coincident with that other contour it's near
[02:19:47] <SWPadnos> is that a lift / rapid connecting the triangle with the arc the circle is connected to? (the blue line)
[02:23:11] <jepler> there's a rapid that exactly overlays a line
[02:23:44] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/demo_cradek.ngc
[02:24:07] <jepler> each Z-level is a different contour
[02:24:24] <jepler> if you load this and switch into perspective view you see that the circle is its own contour
[02:24:48] <jepler> (at this point the shape has broken into 5 contours plus the bug circle)
[02:24:53] <jepler> bbl
[02:24:59] <SWPadnos> ok
[02:32:11] <SWPadnos> there are several segments that have the same endpoint (X3.05088, Y-2.20327)
[02:32:48] <SWPadnos> there are two rapids that overlay (as you mentioned), then another arc that starts at that point, and the arc in question has that point as start and end point
[02:33:01] <SWPadnos> not a problem with lines, but a surprise with arcs
[02:38:11] <cradek> jmkasunich: you are right that I never got U,V working in the 5axis sample config. they do however work on max.
[02:38:34] <jmkasunich> the source for maxkins seems to just pass them on
[02:38:41] <cradek> no, look again
[02:38:44] <jmkasunich> joints[6] = pos->u;
[02:38:44] <jmkasunich> joints[7] = pos->v;
[02:38:44] <jmkasunich> joints[8] = pos->w;
[02:38:58] <cradek> they should also be used for the appropriate other joints
[02:39:25] <jmkasunich> but passing them on means that joints 6 and 7 will ferror out - there are no motors there
[02:39:37] <jmkasunich> or did you hack it with feedback "jumpers" in hal?
[02:39:50] <cradek> yes surely
[02:39:57] <cradek> otherwise they won't show on the screen etc.
[02:40:12] <jmkasunich> oh, joints/axes crap
[02:40:19] <cradek> I would have looped back W too
[02:40:45] <jmkasunich> I decided to start a vismach version of max
[02:40:56] <jmkasunich> if/when I get it working I'll make a sim config that uses it
[02:41:00] <cradek> cool
[02:41:37] <cradek> wow, offs is looking good
[02:41:38] <jmkasunich> I started trying to do a model for the workshop - I think I have a nice way to make a sphere with only a few lines of g-code
[02:42:28] <cradek> neat
[02:42:38] <cradek> you asked me to test cutting wood, which I never did
[02:45:28] <jmkasunich> max uses 3" rotary tables, right?
[02:45:38] <jepler> i'm not completely happy doing this, but expliclitly removing degenerate items from contours fixes the circle problem
[02:45:45] <cradek> no, I think they are 4"
[02:45:46] <jepler> now there's only one head-scratcher -- there's an area that never gets filled
[02:46:04] <jmkasunich> cradek: can you post the max config files somewhere? (ini, hal)
[02:46:23] <cradek> the ones on trunk 'max5' are current
[02:46:54] <jmkasunich> oh, that stuff is all on a branch?
[02:47:02] <jmkasunich> no wonder I couldn't find it
[02:47:19] <jepler> there's no reason the middle of that trapezoidal area doesn't get cut:
http://emergent.unpy.net/index.cgi-files/sandbox/unfilled.png
[02:47:22] <jmkasunich> there is a maxkins in head
[02:47:45] <cradek> I'm pretty sure it's on trunk
[02:48:09] <cradek> hmmmm
[02:48:13] <jmkasunich> I have a current checkout of trunk - no max5 config
[02:48:14] <cradek> I must be on drugs
[02:48:18] <cradek> wtf.
[02:48:32] <jepler> RCS file: /cvs/emc2/src/emc/kinematics/maxkins.c,v
[02:48:36] <jepler> revision 1.2
[02:48:36] <jepler> date: 2008/02/17 02:11:19; author: cradek; state: Exp; lines: +133 -0
[02:48:36] <jepler> merge maxkins from the branch
[02:48:51] <jmkasunich> didn't merge the config maybe?
[02:48:58] <cradek> could be
[02:49:04] <cradek> or maybe it was never checked in at all
[02:49:11] <cradek> (wonder what machine it's on...)
[02:49:17] <cradek> I bet maxkins is up to date
[02:49:52] <cradek> I thought jepler was running max5 in sim on his laptop at stuart's. maybe we just copied the config there.
[02:50:03] <cradek> oh right, I had that little HP machine
[02:50:30] <cradek> jepler: so it stops on that trapezoid after making lots of progress on it?
[02:51:13] <cradek> jepler: the arc on the rightmost point of the trapezoid has just become degenerate when it stops
[02:51:54] <jepler> cradek: interesting observation, thanks
[02:52:30] <jepler> cradek: yes, that happens at about 40*offset, while this was run until 100*offset
[02:52:46] <jepler> but gee if it doesn't look good besides that little problem
[02:53:00] <jepler> I should put the zenbot/pluto configuration in cvs, since I actually have some confidence in it
[02:53:03] <jepler> but for now -- goodnight
[02:53:16] <SWPadnos> it does look good. goog night
[02:53:19] <SWPadnos> good
[02:54:02] <cradek> jepler: yes it looks really excellent. goodnight.
[03:04:35] <jmkasunich> cradek: you still there?
[03:06:53] <cradek> yes
[03:07:20] <jmkasunich> if max isn't buried somewhere, could you take photos from front, side, top, etc
[03:07:35] <jmkasunich> things that would let me get an idea of layout and approximate scale
[03:10:22] <cradek> sure
[03:10:51] <cradek> dang is the weekend over already?
[03:11:03] <jmkasunich> in 50 mins
[03:12:20] <SWPadnos> 1:50 for him
[03:12:43] <jmkasunich> lucky bastard
[03:13:05] <SWPadnos> heh
[05:13:37] <CIA-32> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/max5gui.py: initial commit of 'max5' gui model - needs tweaked, but it is pretty close
[12:20:24] <jepler> oh cool -- there's something "like isolcpus" but it doesn't have to be applied at boot time. you change it through a /sys interface, I think. I'm making a new kernel with that enabled
[12:21:24] <jepler> +CONFIG_CGROUPS=y
[12:21:30] <jepler> +CONFIG_CPUSETS=y
[13:06:09] <jepler> hi skunkworks_
[13:06:16] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/src/ (modsilent Makefile): silence kbuild messages that we know do not indicate a problem
[13:06:40] <SWPadnos> yay
[13:07:11] <jepler> I'm sure there's a "right-er" way but this'll do for now until someone contributes a better fix to silence those
[13:07:33] <skunkworks_> Good morning jepler.
[13:09:43] <skunkworks_> (and SWPadnos)
[13:10:16] <CIA-32> EMC: 03compile-farm 07BDI-4.51 (2.6.16.20-rtai) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
[13:10:35] <SWPadnos> hi skunkworks
[13:10:37] <SWPadnos> oops
[13:12:03] <jepler> hah, wouldn't you know it!
[13:12:38] <skunkworks_> when is that going to stop being supported?
[13:16:25] <jepler> skunkworks_: when it becomes "too hard"
[13:16:29] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/src/modsilent: try to make the modsilent script work with python older than 2.4. also, when actually filtering, write the messages to stdout (which is where they came from)
[13:17:18] <CIA-32> EMC: 03compile-farm 07BDI-4.51 (2.6.16.20-rtai) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
[13:17:36] <cradek> the spindle on awallins's machine looks very responsive
[13:18:30] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/src/modsilent: look for make on the path
[13:20:44] <skunkworks_> cradek: yes - I cannot see it change direction
[13:21:13] <cradek> it must be, because I see threads :-)
[13:22:15] <skunkworks_> :)
[13:51:24] <jepler> hm did that fix bdi? I thought a "build OK" message came to IRC.
[13:52:04] <cradek> I didn't get it in email either. maybe it is still building.
[13:52:19] <jepler> incremental build successfull at 2008-06-02 13:19:25
[13:52:57] <jepler> I guess the message went missing
[13:53:09] <micges> jepler: you patch is working. I managed to decrease from 40% CPU to 25% with your patch by optimize my code
[13:53:13] <micges> thanks
[13:53:35] <jepler> micges: what is your OS and kernel version?
[13:54:02] <jepler> micges: does the problem exist even if you use unmodified emc and configs/sim?
[13:54:42] <micges> if unmodified problem is not exist
[13:55:09] <micges> but I only added more root_window.after proc, that it
[13:55:32] <micges> rest of opengl is not touched
[13:55:52] <micges> os is ubu 8.04 from live cd
[13:56:27] <micges> and 2.2.5 compiled run in place
[13:57:57] <micges> bbl
[13:58:00] <jepler> micges: because of the downside to my change that we already discussed (higher CPU usage when idle) and because it sounds like it doesn't affect unmodified emc2.2.5, I am not planning to incorporate it into a future 2.2.x release
[13:59:20] <micges> ok
[13:59:54] <micges> I will search deeper to see why it was nessesary for me
[14:12:30] <jepler> hmph, this dynamic-isolcpus isn't actually in hardy's 2.6.24-16, and applying this old patch isn't obvious
[15:26:10] <alex_joni> jepler: 2.6.25+ then :)
[15:32:42] <jepler> looking more, I find that cpuset.sched_load_balance (which is in hardy) is supposed to be used for this; but I can't figure out the details of setting it up
[15:35:20] <alex_joni> there was a message recently on the rtai list regarding dropping isolcpus.. did you see that?
[15:36:57] <alex_joni> (I see now that CPUSETS is discussed in that email, so you probably read it ;)
[15:37:54] <jepler> yeah that's what set me off
[15:37:54] <jepler> er, informed me about this :-P
[15:38:18] <jepler> well poo -- I just killed that machine
[15:39:11] <jepler> I wonder if it's something I did in cpusets/cgroups or the regular old lock-ups I'm familiar with
[15:39:25] <jepler> it did happen right after I changed a cpuset.cpus
[15:47:11] <cradek> jepler:
http://www.linuxcnc.org/docview/html//gcode_main.html#r10_1_7 is now wrong
[15:50:19] <jepler> hm I didn't realize I'd documented that "-P
[15:50:23] <jepler> wow what happened to my eyes?
[15:53:15] <CIA-32> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/gcode/main.lyx: remove documentation for feature that was never enabled in the 2.2 series
[15:53:34] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: remove documentation for feature that was never enabled in the 2.2 series
[16:21:10] <alex_joni> * alex_joni wonders if "loadusr sudo modprobe .." is evil
[16:21:54] <SWPadnos> * SWPadnos wonders what would happen if the user weren't there to typi in a password
[16:22:00] <SWPadnos> or type
[16:22:03] <alex_joni> you can 'fix' sudoers
[16:22:57] <jepler> using "sudo" is a no-go for any hal file we bundle with emc
[16:23:14] <jepler> I'd go with "loadusr emc_module_helper ..." + new entries in module whitelist
[16:23:29] <alex_joni> trying to load parport_pc and parport_cs
[16:23:29] <cradek> what are you doing?
[16:23:31] <jepler> or "loadmod" (load a module that is not a HAL component)
[16:23:50] <jepler> (to be written)
[16:23:58] <alex_joni> and then unload them immediately afterwards
[16:24:07] <alex_joni> jepler: heh.. yeah
[16:24:20] <jepler> but either way .. it would use emc_module_helper, not sudo
[16:24:24] <jepler> that's the point of emc_module_helper
[16:24:29] <alex_joni> yeah, I know
[16:26:10] <alex_joni> jepler: it's not meant to be bundled with emc..
[16:27:13] <jepler> for one-of-a-kind situations I wouldn't dream of telling you what to do
[16:27:21] <jepler> sudo probably is the shortest path
[16:28:12] <alex_joni> I agree that emc_module_helper is the way to go "officially" :)
[23:24:33] <jepler> well I "figured out" how to use sched_load_balance, except that it causes a crash very soon after that
[23:25:03] <jepler> actually my second crash was provoked when I was switching between isolated and regular mode repeatedly
[23:25:13] <jepler> but I'm now pretty sure that it's crash-making
