#emc | Logs for 2011-02-01

Back
[00:00:14] <robin_sz> 1) lots of HF when starting. I blew several drives when playing with that
[00:00:34] <robin_sz> 2) no "arc on" indication out from the machine,
[00:00:39] <roel01> hi Robin
[00:00:51] <robin_sz> so use a hall effect IC near the earth lead
[00:01:03] <robin_sz> hi roel01, long time huh?
[00:01:40] <roel01> yes real buzzy lately
[00:01:59] <robin_sz> and 3) there is no way to keep tha air on between cuts, it tends to just go to sleep as it repositions to the next part
[00:02:14] <giacus> robin_sz: a question, is the part that is going to be maachined isolate by the rest of the machine ?
[00:02:24] <robin_sz> the biggest problem is the HF starting, really dirty and noisy
[00:02:32] <robin_sz> no
[00:02:39] <giacus> not isolated ?
[00:02:42] <giacus> ok ..
[00:02:42] <robin_sz> use a star earth grounding plan
[00:02:58] <robin_sz> roel01: still etching PCBs?
[00:03:06] <roel01> yes
[00:03:12] <robin_sz> and riding Quads
[00:03:26] <giacus> robin_sz: any suggestion about rails to use ?
[00:03:54] <robin_sz> giacus: we did this several times .. use IGUS lienar rail, aluminium rail, plastic bushes
[00:04:16] <robin_sz> roel01: got any good toys recently?
[00:04:30] <giacus> robin_sz: ok, thanks
[00:04:35] <roel01> nope im trying to built a photoplotter
[00:04:37] <giacus> :)
[00:04:41] <robin_sz> heh
[00:05:01] <robin_sz> a photoplotter to film .. or direct to the resist?
[00:05:21] <roel01> to film
[00:05:27] <robin_sz> chicken :)
[00:05:40] <giacus> robin_sz: sorry .. no autocad files for that machine around ?
[00:05:51] <giacus> or plan file
[00:05:58] <robin_sz> mm, yeah, solidworks ...
[00:06:09] <robin_sz> but you'll need a CNC laser and a press to make it ;)
[00:07:10] <sed> sed is now known as sed_
[00:07:11] <giacus> mm, no
[00:07:13] <robin_sz> roel01: can you not get photoplotter cheap from the printing industry, as they are probably going digital print very rapidly now
[00:07:19] <giacus> we don't have laser
[00:07:32] <giacus> at the moment ..
[00:07:55] <roel01> 12�11robin_sz12� they relay expensive
[00:08:06] <robin_sz> oh
[00:08:24] <roel01> nothing under the 5000 euro's
[00:08:37] <robin_sz> so .. going to use a aperture and a motion system, or convert an old laser printer to UV led?
[00:09:20] <giacus> btw robin_sz the plasma yu seen cut 4 cm
[00:09:23] <roel01> hehe no i just got a sutable laser diode 20 watts wil do i think :)
[00:09:25] <giacus> roger ?
[00:09:32] <giacus> mild steel
[00:09:49] <giacus> run with external power generator
[00:09:56] <giacus> 15 KW
[00:10:34] <robin_sz> never tried mine that thick, but 150A should do 40mm OK
[00:10:47] <giacus> robin_sz: Max. cutting thickness mild steel mm 40
[00:10:49] <robin_sz> notice its a 150A machine, not 30 like you said
[00:10:54] <giacus> yeah ..
[00:10:59] <giacus> not 10 or 20
[00:11:04] <robin_sz> indeed
[00:11:04] <giacus> 40.
[00:11:25] <robin_sz> it wont pierce 40 though
[00:11:30] <giacus> I dont sayd 30 A
[00:11:37] <giacus> I sayd it cut 4 cm.
[00:11:42] <giacus> and it do it.
[00:11:48] <robin_sz> you said something like that ...
[00:11:52] <giacus> no.
[00:11:56] <robin_sz> here is the standard rule:
[00:12:01] <robin_sz> 100A cuts 30 mm
[00:12:15] <robin_sz> pierces 15mm
[00:12:24] <giacus> no no ..
[00:12:29] <robin_sz> yes it does
[00:12:34] <giacus> ok
[00:13:01] <robin_sz> to cut 40mm you will need to either drill a hole or start at the edge
[00:13:20] <robin_sz> 150A will pierce 20mm or ~
[00:13:43] <giacus> robin_sz: he's using an external power generator..
[00:13:51] <giacus> have you seen ?
[00:13:56] <giacus> http://www.cemont.it/amministrazione/scheda_prodotto_en.php_idp=347&idcc=24&from=lista
[00:13:58] <robin_sz> mmm ... diesel?
[00:14:02] <giacus> yeah
[00:14:26] <giacus> that wahy I sayd ..
[00:14:50] <giacus> now, are steppers ok for that ?
[00:14:56] <robin_sz> sure ..
[00:15:18] <giacus> ok
[00:15:25] <robin_sz> gear for 10mm to 15mm per rev and you are fine
[00:15:35] <giacus> let me start with the building
[00:15:54] <giacus> I will show the photos during the process
[00:16:00] <giacus> :)
[00:16:04] <robin_sz> fun
[00:16:08] <giacus> hehe
[00:16:16] <giacus> K:P
[00:17:16] <roel01> i'm off to bed
[00:17:22] <robin_sz> lucky you
[00:17:23] <giacus> night
[00:17:26] <giacus> thanks
[00:17:28] <robin_sz> with anyomne I know?
[00:17:33] <giacus> I'm going too
[00:21:36] <giacus> night
[00:24:13] <sed_> is a geckodrive all you need to control servo motors through a Parellel port?
[00:36:57] <SWPadnos> that and a power supply
[00:37:16] <Jymmm> electricity might help
[00:37:45] <jepler> mmm grilled cheese and tomato soup
[00:37:45] <SWPadnos> oh, and wires ;)
[00:38:34] <Jymmm> maybe a machine to put the motors on?
[00:39:02] <SWPadnos> he didn't mention a machine, just motors
[00:39:14] <Jymmm> ah, that's true.... my bad
[00:39:29] <Jymmm> oh, I know... a parallel port
[00:39:57] <SWPadnos> well, the parallel port weas mentioned, so I'd say it's either known or already part of the system
[00:40:48] <Jymmm> what about encoders?
[00:41:06] <SWPadnos> I was thinking about those - yes, I'd say that encoders are needed as well
[00:41:25] <Jymmm> what something to connect the encoders to the paraport
[00:41:35] <SWPadnos> the geckodrive and wires would cover that
[00:41:44] <sed_> do servo motors have encoders built in?
[00:41:59] <SWPadnos> some have encoders preinstalled
[00:42:07] <SWPadnos> do you have motors yet?
[00:42:16] <sed_> no nothing..
[00:42:23] <Jymmm> if you need encoders, you could look at http://usdigital.com/
[00:42:27] <sed_> and obviously I have no clue what I am doing
[00:42:50] <sed_> Jymmm are they linear encoders?
[00:42:52] <SWPadnos> ok. then you should definitely make sure that the motors either have encoders, or provisions for mounting them
[00:42:55] <SWPadnos> rotary
[00:43:36] <dmessier> hello tous
[00:43:45] <SWPadnos> bonjour, dmessier
[00:44:04] <dmessier> whatz happnin'??
[00:44:31] <SWPadnos> �a va bien?
[00:44:37] <sed_> I was looking at the kits from xylotex that included motors
[00:44:50] <SWPadnos> those would be steppers though, right?
[00:44:56] <SWPadnos> (or do they have servos as well?)
[00:45:02] <Jymmm> SWPadnos just steppers
[00:45:08] <sed_> Im sorry yea steppers
[00:45:14] <SWPadnos> so I thought
[00:45:34] <dmessier> how well is the tp handleing the servos on emc2??
[00:45:51] <SWPadnos> servo or stepper aren't all that different AFAIK
[00:45:59] <SWPadnos> and the new TP looks excellent in the plots
[00:46:17] <sed_> how do people typicly mount them to machines.. timing belt 1x1 pulley's?
[00:46:35] <dmessier> is the potential there for drive data starvation??
[00:46:40] <SWPadnos> depends on the motor torque/speed vs. the machine mechanics
[00:47:10] <SWPadnos> dmessier, I think it'll just slow down the feed rate
[00:47:19] <SWPadnos> Im not sure though
[00:47:20] <dmessier> ok nice..
[00:47:50] <dmessier> but NOT to 0... i hope??
[00:47:53] <sed_> I have a small benchtop knee mill
[00:48:36] <SWPadnos> no - if it slows down, it'll be because it's processing one block per TP cycle, so the rate whoulsn't hit 0
[00:49:00] <SWPadnos> I'm not sure how it deals with that though, you'd have to ask cradek / alex (or maybe both ;) )
[00:49:22] <SWPadnos> sed_, then it would depend on how powerful the motors you choose are, relative to your benchtop mill
[00:49:27] <dmessier> even minor dev's can cause material abuse in post heat treated parts..
[00:49:28] <sed_> the motors that come with the kit are 269 oz.in
[00:49:55] <SWPadnos> you can figure out how much torque you need
[00:50:15] <SWPadnos> crank a handle, and either use a spring scale or estimate the amount of force you're putting on the handle
[00:50:43] <SWPadnos> multiply by the handle radius (screw center to handle center)
[00:51:02] <SWPadnos> if you measure the radius in inches, and the weight in ounces, then the number you get is ounce-inches
[00:51:16] <Jymmm> Tie a 12" bar to the handle. one lbs on the end of the bar is one ft pound
[00:51:43] <dmessier> 1:3.. looks feasable..
[00:52:03] <dmessier> what is the max rpm??
[00:52:14] <sed_> inch pounds on the X/Y maybe 8ft/lbs on the knee
[00:52:44] <sed_> I figure I would want more to feed it into the cutter..
[00:53:44] <dmessier> what are you planning on cutting with it and for how long??
[00:54:20] <sed_> aluminum mainly.. the mill is only like 7x24 in size
[00:54:28] <sed_> er 7x18 I mean
[00:54:55] <dmessier> so a 3/4" cutter will be a max??
[00:55:03] <sed_> I would say
[00:55:12] <dmessier> spindle speed??
[00:55:23] <sed_> it has a R8 Collet
[00:55:40] <sed_> 2k RPM max I would say... havent checked in a while
[00:56:51] <dmessier> so light DOC... strategic programming req'd... Sharp positive tools... and short is better
[01:14:09] <CIA-8> 03jepler * 10emc2/src/Makefile:
[01:14:09] <CIA-8> It bugged me that the configs were copied every time, and weren't cleaned.
[01:14:09] <CIA-8> So I wrote some lines of makefiles.
[01:14:09] <CIA-8> Some other make commands were also silenced.
[01:16:03] <jepler> dmessier: If you want to test "starvation", the 'diag.ngc' from emc1 might be a good test. Increase the feed rate until you know the segments (which are around .0374 long) can be completed in well under a cycle.
[01:17:16] <jepler> ('diag.ngc' is about 1000 short, colinear moves)
[02:16:46] <fenn> jepler: why do you do t *=20 ?
[02:17:02] <fenn> and, is "z" really dt?
[02:17:18] <jepler> fenn: are you talking in spiro.py? Because in x() and y(), t goes from 0 to 1. The perimeter of a 4x6 rectangle is 20.
[02:17:43] <jepler> I don't remember if I gave dt a weird name .. if it's what's added to t repeatedly, then it's dt.
[02:17:49] <fenn> ok
[02:18:02] <Jymmm> jepler writes nice code, just sucks at documenting it =)
[02:18:53] <jepler> documentation?!?!
[02:18:58] <Jymmm> like most coders.
[02:19:20] <fenn> well in his defense, it was a quick hack
[02:19:36] <fenn> i am playing with a 3d version right now
[02:19:41] <Jymmm> * Jymmm is a comment whore...
[02:19:48] <fenn> z = sin*cos(t)
[02:19:51] <Jymmm> * Jymmm suffers from an acute case of CRS
[02:20:31] <Jymmm> fenn was that a question?
[02:21:22] <Jymmm> fenn: It all started here --> http://www.wordsmith.org/~anu/java/spirograph.html
[02:22:28] <fenn> yeah i read the logs
[02:22:34] <fenn> just made a pretty picture frame
[02:22:42] <fenn> (in styrofoam)
[02:22:43] <Jymmm> jepler 72,-21,80,49 that 'APPEARS' to stop when done.
[02:22:51] <Jymmm> fenn pic?
[02:22:58] <fenn> 1 sec
[02:23:00] <Jymmm> k
[02:26:25] <fenn> http://fenn.dyndns.org/pub/camera/DCP_0604.JPG
[02:27:15] <fenn> the stepover's a little too big so there's a lot of fuzzies
[02:27:36] <fenn> the thing on the left is something else
[02:27:39] <Jymmm> but I can see it =)
[02:28:46] <fenn> there is a slight screwup in the middle of the bottom when my dumb ass got tangled in the machine
[02:29:42] <Jymmm> you fell in?
[02:30:04] <fenn> i'm wearing a sweatshirt with strings for the hood.. got wrapped around the y leadscrew
[02:33:54] <Jymmm> ouch!
[02:45:20] <jepler> Jymmm: I don't understand what you mean up above when you said "'APPEARS' to stop when done"
[02:45:51] <Jymmm> jepler: remember we were talking about when it stops or has completed the shape
[02:46:05] <jepler> Jymmm: oh
[02:49:34] <Jymmm> fenn you using a mini router mill ?
[02:49:50] <Jymmm> http://fenn.dyndns.org/pub/camera/DCP_0604.JPG
[02:56:46] <CIA-8> 03cradek * 10emc2/src/emc/kinematics/tp.c: fix bad blend caused by different axis maxaccels
[03:22:40] <fenn> http://fenn.dyndns.org/pub/camera/DCP_0605.JPG <- slightly better, still looks like it was attacked by a robotic beaver
[03:26:19] <Jymmm> lol
[03:26:35] <Jymmm> you need to get a light down therebrighter than 2 candles
[03:31:49] <fenn> hmm i guess more candles wouldn't destroy the dungeon-like atmosphere
[03:32:06] <Jymmm> fenn Eh, ignote some boiling oil or something =)
[03:32:10] <Jymmm> ignite
[03:32:20] <fenn> limelight
[03:32:31] <skunkworks> looks like you guys have been having fun. ;)
[03:33:00] <Jymmm> skunkworks: Hey, I never thought I'd start a trend on that
[03:33:58] <skunkworks> math is fun ;) Little did you know it would be used to test the new TP
[03:34:22] <Jymmm> skunkworks: Actually if I knew trig, I would have never brought it up
[03:44:55] <skunkworks> time for bed. Night
[03:45:04] <Jymmm> nite
[03:51:56] <CIA-8> 03cradek * 10emc2/src/emc/kinematics/tp.c: more blending criteria fixes
[04:00:18] <jepler> yay
[04:00:27] <jepler> so both those weird cases I found are right now?
[04:01:04] <cradek> yes
[04:02:52] <cradek> but you should keep testing to make sure!
[04:03:01] <SWPadnos> I still wonder if G0 should be blended with "cuting" moves
[04:03:06] <SWPadnos> cutting
[04:03:42] <cradek> SWPadnos: if you get something like a consensus on the list and come up with a spec, I'll do whatever people want.
[04:03:51] <SWPadnos> thanks
[04:03:59] <SWPadnos> it's the consensus I'm wondering about ;)
[04:04:41] <cradek> me too
[04:04:47] <cradek> I have no idea what it should do
[04:05:04] <cradek> but remember you can set g61 in the program for when you want sharp corners...
[04:05:19] <SWPadnos> true
[04:05:35] <SWPadnos> does that become active at the beginning or at the end of a block?
[04:05:52] <fenn> lack of consensus == configurability
[04:05:56] <cradek> "at the end of the next move, and all following move ends, do this"
[04:06:28] <SWPadnos> next as in "the one on this line", or next as in "the one in a subsequent block" ;)
[04:06:30] <cradek> the best we'd end up with is inifile entries, and I kind of think that sucks...
[04:06:41] <cradek> not sure, probably both
[04:06:47] <SWPadnos> heh - on enver knows
[04:06:48] <cradek> I'm sure the kramer doc says
[04:06:58] <jepler> g64.159 p.01 q3 r19 f22 z[tan 7/5]
[04:07:03] <SWPadnos> oh, I thought you were quoting it
[04:07:04] <jepler> just expand g64
[04:07:36] <SWPadnos> some G-code is probably acceptable
[04:07:51] <fenn> i wonder how much you can cram into one g code
[04:07:56] <jepler> If it's configurable, it probably depends on the piece being produced, not the machine
[04:08:00] <SWPadnos> but a mode would be nice as well, one that isn't going to get reset by a program that doesn't know about it
[04:08:40] <jepler> fenn: With O-codes I imagine there will eventually be a need to say "store the state" and "restore the state" (like OpenGL's glPushAttrib()) .. that is a code that would do a lot of stuff
[04:09:06] <fenn> i hope we can abandon g-code before it comes to that
[04:09:11] <bpmw> Good evening everyone!
[04:09:17] <jepler> like "restore the arc plane to what it was before this O- call
[04:09:18] <SWPadnos> hmm - actually, path tolerance is even better. you can avoid screwing up the edge of a hole by reteracting further than the set tolerance
[04:09:21] <jepler> "
[04:09:25] <SWPadnos> hi bpmw
[04:09:41] <bpmw> Hi Steven!
[04:09:42] <SWPadnos> which can then blend with a G0 to get to the next hole
[04:10:25] <fenn> yep any good HSM cam program will put big fat curves in all the g0 moves anyway
[04:11:43] <cradek> SWPadnos: I honestly think you can't beat path tolerance. That's the most important new feature.
[04:12:03] <SWPadnos> I'd love to load up tort on somebody's machine, and catch the look on their face when they think their machine is posessed
[04:12:09] <SWPadnos> yep - that's a great one
[04:12:14] <fenn> tort?
[04:12:23] <SWPadnos> torture test file
[04:12:51] <bpmw> Hey Guys, I need a little help. I'm setting up my mill in new shop I built and decided to update Emc2. Now I can't start it.
[04:12:52] <SWPadnos> though the machine would appear possessed, not posessed
[04:13:02] <jepler> 20:18:40 <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/tort.ngc
[04:13:08] <SWPadnos> make install or make setuid
[04:13:09] <jepler> (on the sekrit channel)
[04:13:25] <cradek> jepler: have you run tort again yet?
[04:13:27] <SWPadnos> kwiet - itz apposed two bee sekrit!
[04:13:29] <jepler> cradek: no
[04:13:40] <SWPadnos> I just did, and played with the FO all the while
[04:13:43] <SWPadnos> seemed OK
[04:13:47] <cradek> SWPadnos: slick
[04:14:00] <cradek> SWPadnos: I think I nailed the FO problems for good
[04:14:02] <SWPadnos> but I couldn't tell if there were misblends, since the moves aren't all that long
[04:14:12] <jepler> tort was generated by a python program to do all kinds of crazy things that no real program ever would
[04:14:13] <SWPadnos> I hope so. excellent work
[04:15:32] <fenn> unfortunately real programs do all kinds of crazy things a test program would never do
[04:16:20] <SWPadnos> not this test program
[04:16:23] <jepler> fenn: I tried to capture all kinds of random blends with differing feed rates
[04:16:31] <cradek> jmkasunich: did you see tort.ngc?
[04:16:33] <jepler> There are probably not any complete reversals, though
[04:16:36] <cradek> http://emergent.unpy.net/index.cgi-files/sandbox/tort.ngc
[04:16:37] <SWPadnos> I sincerely hope that no program ever does anything even remotely close to this
[04:16:48] <jepler> SWPadnos: no, but real programs will do other weird stuff
[04:16:52] <fenn> axis looks so cool with hardware accel
[04:17:02] <cradek> fenn: it sure does
[04:17:06] <SWPadnos> true - non-congruent sets of total crap
[04:17:20] <SWPadnos> waaaaaahhhhh
[04:17:36] <fenn> like arcs that have mismatching endpoints and radii
[04:17:44] <fenn> or whatever that error is i always get
[04:17:48] <jepler> what do you mean by mismatching endpoints?
[04:17:52] <jepler> oh oh
[04:17:58] <jepler> yeah but it's not the tp's job to catch those
[04:18:20] <jepler> cradek: should I use the different accels/vels ini?
[04:18:38] <cradek> jepler: yes, that makes everything worse
[04:18:39] <jmkasunich> do you guys have an ini file to go with that?
[04:19:11] <cradek> jepler posted one, just a sec
[04:19:14] <jepler> 20:18:28 <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/weird-blend-1.png
[04:19:17] <jepler> 20:18:36 <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/stepper_inch.ini
[04:19:20] <jepler> 20:18:40 <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/tort.ngc
[04:19:40] <jepler> that stepper_inch.ini has all different (low) accels, all different vels, and no headroom
[04:20:04] <SWPadnos> http://www.sover.net/~swp/images/tortblend1.jpg
[04:20:09] <SWPadnos> http://www.sover.net/~swp/images/tortblend1-after.jpg
[04:20:23] <SWPadnos> before and after, with similar views in axis
[04:20:32] <jepler> my "before" was worse than yours
[04:20:33] <jmkasunich> thats a freaky tooplath
[04:20:39] <jmkasunich> toolpath even
[04:20:46] <SWPadnos> look at the yellow - it totally misses the arc
[04:20:55] <cradek> you scared me for a second there
[04:21:05] <jepler> SWPadnos: oh I see the problem in yours now
[04:21:09] <cradek> SWPadnos: it blended the following downward segment at the beginning of the arc
[04:21:12] <SWPadnos> yep
[04:21:30] <SWPadnos> I'm not positive that I ran both with 300% FO though, maybe I'll do it again
[04:21:37] <cradek> the big yellow curve gives it right away
[04:21:44] <SWPadnos> it sure does
[04:22:57] <SWPadnos> I'm running it again, and there are still some things that could be wrong behavior, but it's probably due to display cycle time
[04:23:18] <cradek> my paths are much smoother than yours - you must not have hardware gl.
[04:23:30] <SWPadnos> cygwin/X - it may not matter
[04:23:40] <cradek> I'm going to have to take this desktop to fest...
[04:24:48] <bpmw> Hi Guys, whatthe trick to get a new update to start? scripts/emc dosen't seem to work!
[04:25:02] <jmkasunich> shame we can mix axis's display technology with halscope's sampling
[04:25:15] <jmkasunich> s/can/can't/
[04:25:16] <SWPadnos> did you configure --enable-run-in-place?
[04:25:34] <jmkasunich> and do the "sudo make setuid" after "make" ?
[04:25:43] <SWPadnos> or make install
[04:26:08] <SWPadnos> jmkasunich, who says it can't be done?
[04:26:19] <bpmw> no all ive done so far is make clean and make.
[04:26:21] <jepler> cradek: http://emergent.unpy.net/index.cgi-files/sandbox/weird-blend-3.png
[04:26:28] <jmkasunich> well, anything can be done... can't be done simply and quickly
[04:26:36] <jepler> cradek: It's hard to see with all the other crap, but I got this really strange blend by hitting p and s during it
[04:27:02] <SWPadnos> you only need two buffers for XYZABC/Mode, each (servo cycle time / TP cycle time) long
[04:27:13] <SWPadnos> and the ability to move all that data from the kernel to GUI ;)
[04:27:24] <jmkasunich> halscope uses a shmem block
[04:27:42] <cradek> jepler: hmm, pause during a blend may be problematic
[04:27:59] <jmkasunich> hmm, axis won't start
[04:28:03] <cradek> changing FO during a blend may change its shape too, I'm not sure
[04:28:08] <jmkasunich> doing run in place
[04:28:18] <fenn> SWPadnos: that's a lot o' data
[04:28:21] <SWPadnos> did you install axis?
[04:28:56] <SWPadnos> 28 bytes * TP cycle rate = 28k / second
[04:29:03] <jmkasunich> not entirely sure
[04:29:13] <cradek> huh, I get a Z following error on the blend of line 230 to 231
[04:29:28] <jmkasunich> I have the axis package installed, but I have no idea if it works with a RIP compilation of cvs head
[04:29:47] <cradek> jmkasunich: it won't, because of the interpreter change. normally it would.
[04:29:55] <jmkasunich> I understand there are reasons why axis isn't part of emc2 cvs, but it is a bit of a nuisance
[04:30:59] <bpmw> Thanks guys , I need to print out instuctions from the "testing" wiki.
[04:30:59] <jepler> cradek: I think it's "right" in that it does touch some part of both moves, and since I didn't set a G64 P- it's not violating any maximum distance rule
[04:30:59] <bpmw> I missed a step or two.:)
[04:31:00] <jmkasunich> so what do I have to do to get axis working with my RIP checkout
[04:31:22] <jepler> jmkasunich: you have to build axis .. the latest 1.2rc or HEAD
[04:31:28] <bpmw> bye for now!
[04:31:40] <bpmw> quit
[04:31:48] <jmkasunich> /quit
[04:31:52] <SWPadnos> standard 'sudo env EMCROOT=/path/to/emc2 python setup.py install'
[04:31:54] <bpmw> exit
[04:31:54] <SWPadnos> heh
[04:31:56] <SWPadnos> see you
[04:32:01] <SWPadnos> use a slash
[04:32:07] <bpmw> i did
[04:32:08] <cradek> /quit
[04:32:20] <cradek> heh
[04:32:26] <SWPadnos> it worked
[04:32:50] <cradek> jmkasunich: axis.unpy.net, cvs snapshots, axis-latest.tar.gz
[04:32:53] <SWPadnos> hmmm - you shouldn't need sudo on that axis install, should you?
[04:33:04] <cradek> SWPadnos: yes
[04:33:07] <jepler> SWPadnos: unforuntately, it installs stuff in /usr/lib and /usr/share
[04:33:11] <SWPadnos> ok
[04:33:30] <cradek> jepler: can you run tort past line 230? I get a following error
[04:33:34] <jepler> that's on the "should be fixed" list
[04:33:53] <jepler> cradek: oops, mine was still paused. I'll let you know
[04:34:29] <jmkasunich> jepler: is that gonna play nice with my existing install of emc2-axis 1.2rc2-1.0?
[04:34:41] <fenn> hum. axis rotates around the orgin now?
[04:34:43] <jepler> jmkasunich: yeah I think so
[04:34:54] <cradek> fenn: it rotates around the center of the program OR the selected line
[04:35:30] <SWPadnos> I have tighter ferror settings than the torture test ini, and I get no errors
[04:35:53] <cradek> argh, no ddts in the halfile
[04:35:56] <fenn> must admit i liked the rotation better before
[04:36:19] <SWPadnos> argh - kate is like mini
[04:36:25] <SWPadnos> huuuuuuuuge
[04:37:04] <jmkasunich> swp: but you should be able to resize it once and have it stay that size
[04:37:27] <SWPadnos> depends on how many "x terminals" you run it on
[04:37:42] <SWPadnos> it didn't know what to do with the 3840x1024 desktop on my windows machine
[04:38:21] <SWPadnos> I have much higher accel and vel settings in my ini - that may help with the lack of ferrors
[04:38:44] <cradek> yes low accel is always worse
[04:39:05] <SWPadnos> I'm also using a USC, not stepgen
[04:41:20] <jmkasunich> john@ke-main-ubuntu:~/emcdev/axis-ps436$ sudo env EMCROOT=~/emcdev/emc2head python setup.py
[04:41:20] <jmkasunich> Building for EMC2 in /home/john/emcdev/emc2head
[04:41:20] <jmkasunich> ['/home/john/emcdev/emc2head/include'] ['/home/john/emcdev/emc2head/lib'] ['-Wl,-rpath,/home/john/emcdev/emc2head/lib']
[04:41:20] <jmkasunich> usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
[04:41:20] <jmkasunich> or: setup.py --help [cmd1 cmd2 ...]
[04:41:22] <jmkasunich> or: setup.py --help-commands
[04:41:24] <jmkasunich> or: setup.py cmd --help
[04:41:26] <jmkasunich> error: no commands supplied
[04:41:29] <jmkasunich> j
[04:41:39] <cradek> ... install
[04:41:51] <jmkasunich> duh
[04:42:00] <jmkasunich> darn wordwrap in the IRC window
[04:42:18] <jepler> cradek: I got a ferror on line 231 .. this is with the original (different accel) ini
[04:42:25] <jmkasunich> error: invalid Python installation: unable to open /usr/lib/python2.4/config/Makefile (No such file or directory)
[04:42:27] <jepler> cradek: but it's bedtime here .. we can talk about it tomorrow
[04:42:31] <SWPadnos> interesting. the total execution time for the servo-thread is almost 500 uS on this machine
[04:42:36] <jepler> jmkasunich: apt-get build-dep emc2-axis then install agan
[04:42:43] <SWPadnos> oops - over 500 uS
[04:42:47] <cradek> jepler: ok, goodnight
[04:42:50] <cradek> jepler: thanks again very much
[04:43:18] <SWPadnos> I sonder if it would help to make the base_thread slower than the 250 uS it is now
[04:43:21] <SWPadnos> wonder
[04:43:34] <SWPadnos> see you jepler - thanks for the test program(s)
[04:43:34] <jmkasunich> swp, not very much
[04:43:46] <jmkasunich> what are you running on, that seems incredibly slow
[04:43:59] <SWPadnos> celeron 500
[04:44:08] <jmkasunich> something is fscked
[04:44:17] <SWPadnos> so I multiplied the tmax numbers by 2, to get ns
[04:44:32] <SWPadnos> incidentally, it might be nice for halcmd to show thread total execution time
[04:44:40] <jmkasunich> yes, it would
[04:44:52] <jmkasunich> but right now, hal parameters need to belong to some component
[04:45:05] <jmkasunich> what component "owns" the thread times?
[04:45:12] <cradek> jepler: definitely an accel violation at line 231
[04:45:21] <SWPadnos> those parameters are "item already named in thread list.tmax"
[04:45:22] <jmkasunich> (I already have the code to calc the times, just no param to stick them in)
[04:45:35] <SWPadnos> just have halcmd print it with show
[04:45:42] <jmkasunich> oh, I see
[04:45:48] <SWPadnos> 999012 YES servo-thread 265308
[04:45:53] <jmkasunich> thats probably doable without too much trouble
[04:46:02] <SWPadnos> yep. I could even do that
[04:46:43] <cradek> ohhhhh it's a helix
[04:46:44] <jmkasunich> what are your .time readings?
[04:46:47] <cradek> aha
[04:46:53] <SWPadnos> anyway - it's 266849 cycles for ppmc read/write, 4 pid calcs, and motion command handler + controller
[04:46:54] <SWPadnos> one sec
[04:47:09] <SWPadnos> 02 s32 RW 30334 motion-command-handler.tmax
[04:47:10] <SWPadnos> 02 s32 RW 91296 motion-controller.tmax
[04:47:12] <SWPadnos> 04 s32 RW 6289 pid.0.do-pid-calcs.tmax
[04:47:13] <SWPadnos> 04 s32 RW 6210 pid.1.do-pid-calcs.tmax
[04:47:15] <SWPadnos> 04 s32 RW 6664 pid.2.do-pid-calcs.tmax
[04:47:17] <SWPadnos> 04 s32 RW 8491 pid.3.do-pid-calcs.tmax
[04:47:18] <SWPadnos> 05 s32 RW 64359 ppmc.0.read.tmax
[04:47:20] <SWPadnos> 05 s32 RW 53206 ppmc.0.write.tmax
[04:47:21] <SWPadnos> 06 s32 RW 0 scope.sample.tmax
[04:47:27] <jmkasunich> bet .time is an order of magnitude smaller
[04:48:11] <SWPadnos> 02 s32 R- 591 motion-command-handler.time
[04:48:12] <SWPadnos> 02 s32 R- 33264 motion-controller.time
[04:48:14] <SWPadnos> 04 s32 R- 468 pid.0.do-pid-calcs.time
[04:48:15] <jmkasunich> the ppmc ones will always be long, thats EPP overhead
[04:48:16] <SWPadnos> 04 s32 R- 453 pid.1.do-pid-calcs.time
[04:48:17] <SWPadnos> 04 s32 R- 353 pid.2.do-pid-calcs.time
[04:48:19] <SWPadnos> 04 s32 R- 2139 pid.3.do-pid-calcs.time
[04:48:20] <SWPadnos> 05 s32 R- 30827 ppmc.0.read.time
[04:48:22] <SWPadnos> 05 s32 R- 18909 ppmc.0.write.time
[04:49:07] <jmkasunich> it can be interesting to scope the .time parameters
[04:49:14] <SWPadnos> some moving average would be nice. even a (new + old) /2
[04:49:46] <SWPadnos> I can imagine
[04:56:16] <jmkasunich> 02 s32 RW 44615 motion-command-handler.tmax
[04:56:16] <jmkasunich> 02 s32 RW 99256 motion-controller.tmax
[04:56:16] <jmkasunich> 06 s32 RW 16737 parport.0.read.tmax
[04:56:16] <jmkasunich> 06 s32 RW 18928 parport.0.write.tmax
[04:56:16] <jmkasunich> 06 s32 RW 0 parport.read-all.tmax
[04:56:17] <jmkasunich> 06 s32 RW 0 parport.write-all.tmax
[04:56:19] <jmkasunich> 05 s32 RW 0 scope.sample.tmax
[04:56:21] <jmkasunich> 04 s32 RW 1964 stepgen.capture-position.tmax
[04:56:23] <jmkasunich> 04 s32 RW 13037 stepgen.make-pulses.tmax
[04:56:25] <jmkasunich> 04 s32 RW 16595 stepgen.update-freq.tmax
[04:56:55] <SWPadnos> what CPU?
[04:57:03] <jmkasunich> Sempron 2800
[04:57:10] <jmkasunich> 1.? GHz clock
[04:57:15] <jmkasunich> 1.6GHz I think
[04:57:22] <SWPadnos> around 1.6-2.0, I think
[04:57:44] <jmkasunich> the faster clock explains why I have higher numbers - cache misses cost more clocks on this box
[04:57:45] <SWPadnos> hmm - I wonder if your slightly higher numbers are from the extra registers
[04:58:03] <SWPadnos> don't bet on it ;)
[04:58:14] <SWPadnos> this m,achine uses PC133 SDRAM
[04:58:18] <jmkasunich> I have 3x or more the clock, but I doubt the memory bandwidth is 3x
[04:58:20] <SWPadnos> one bank
[04:58:33] <SWPadnos> DDR400 or thereabouts?
[04:59:00] <jmkasunich> might be
[04:59:11] <SWPadnos> that would be roughly 3x the transfer
[04:59:15] <SWPadnos> rate
[04:59:32] <SWPadnos> the sempron isn't dual-bank, is it?
[04:59:39] <jmkasunich> don't think so
[05:00:05] <jmkasunich> the 99000 in controller is probably the new TP ;-)
[05:00:08] <SWPadnos> ok. the larger cache size would probably help a lot - remember that PIII-era celerons basically had no cache
[05:00:12] <SWPadnos> yep
[05:00:45] <SWPadnos> this one has 128k, Linux thinks
[05:01:35] <jmkasunich> controller.time is usually about 22-24K, goes up to 46K or so every so often
[05:01:40] <SWPadnos> anyway, the numbers look fairly close to me, for the couple of functs we have in common ;)
[05:01:45] <jmkasunich> probably traj cycles
[05:01:57] <SWPadnos> ok - new blocks?
[05:02:03] <jmkasunich> the TP only runs one time in 10
[05:02:18] <SWPadnos> shouldn't you see the spike every 10 samples then?
[05:02:27] <jmkasunich> yeah, on the scope
[05:02:27] <jmkasunich> I
[05:02:40] <jmkasunich> I'm just doing halcmd show | grep time, and repeating manually
[05:02:47] <jmkasunich> so its a random sample
[05:02:49] <SWPadnos> if only IRC had shared screens :)
[05:02:52] <SWPadnos> ah, ok
[05:02:59] <jmkasunich> I get the high one about one out of ten tho
[05:03:17] <SWPadnos> ok. I was trying to get watch to do that for me, but it doesn't seem to work
[05:03:46] <jmkasunich> I had troubles doing that too, I think you need parans around the entire pipeline or something like that
[05:04:02] <jmkasunich> I was just using history, I could run it several times per second that way
[05:04:03] <SWPadnos> watch -d -n 1 '/Project/emc2/bin/halcmd show param | grep -F .time'
[05:04:11] <SWPadnos> that's what I tried (and numerous variations)
[05:04:25] <SWPadnos> should work according to the manpage
[05:05:35] <jmkasunich> just got a following error on line 246 of tort.ngc
[05:05:40] <fenn> another entry in the "would be neat" pile.. if axis had a scrolling halscope display at the bottom, and you could drag a cursor back and forth to move the cone to the current position you're looking at on the scope
[05:06:13] <SWPadnos> that would be neat
[05:06:21] <SWPadnos> also long-term logging for halscope
[05:06:44] <fenn> in order to detect unauthorized use of the cnc machine
[05:06:47] <jmkasunich> there is code to put a "Roll" button in the Run Mode selection area on halscope
[05:06:56] <jmkasunich> but the actual roll mode isn't implemented
[05:06:59] <fenn> hmm.. what's this i see in the logs? harley davidson signs?
[05:08:22] <Jymmm> fenn that might be me
[05:08:58] <jmkasunich> scoping .time
[05:09:18] <jmkasunich> command handler is damn fast most of the time (duh, no command to handle most of the time)
[05:09:34] <jmkasunich> minimum is about 150 clocks
[05:10:00] <jmkasunich> most common when its actually doing something is about 2000
[05:10:04] <Jymmm> fenn: http://static.flickr.com/33/61765799_f610fa36cb.jpg
[05:10:31] <fenn> alert! unauthorized use of the HD logo!
[05:10:48] <SWPadnos> the tmax calculation doesn't subtract overhead, does it?
[05:10:51] <Jymmm> fenn: horseshit... only if I sell it
[05:10:56] <fenn> mwahahha
[05:10:58] <Jymmm> fenn $20 =)
[05:11:02] <jmkasunich> with spikes to 35-40K every 100ms or so (not really periodic tho)
[05:11:11] <jmkasunich> SWP: no
[05:11:12] <SWPadnos> (else the numbers would'nt have been so high with the gettime bug)
[05:11:18] <SWPadnos> ok
[05:11:44] <jmkasunich> overhead is pretty darned low tho, couple of function calls
[05:12:13] <jmkasunich> controller definitely does more work than command-handler
[05:12:19] <jmkasunich> minimum is about 6K
[05:12:36] <CIA-8> 03cradek * 10emc2/src/emc/task/emccanon.cc: another problem found by jepler's torture ngc file: helix constraints
[05:14:04] <jmkasunich> seems like the TP takes about 25K clocks every 10mS
[05:14:18] <jmkasunich> superimposed on a base "line" that isn't really very flat
[05:14:21] <SWPadnos> that's the TRAJ cycle, no doubt
[05:14:33] <cradek> is that good or bad?
[05:14:46] <SWPadnos> neither - it's information
[05:14:55] <SWPadnos> I think it would be a lot more using hexkins ;)
[05:15:16] <jmkasunich> on a 500MHz box its 50uS every 10,000uS, not too bad ;-)
[05:15:37] <jmkasunich> I'm more interested in the baseline variations
[05:15:46] <SWPadnos> it's the peaks that get me. maybe the thread code should have a time and tmax var in the thread struct
[05:16:04] <SWPadnos> so I'mnot adding up all the tmaxes, which probably don't occur at the same time
[05:16:14] <jmkasunich> yeah
[05:16:28] <SWPadnos> that would be an RTAPI thing, right?
[05:16:32] <jmkasunich> the prob with just having it in the thread struct and printing with halcmd is that you can't scope it
[05:16:40] <jmkasunich> nope, hal
[05:16:57] <jmkasunich> each hal thread is a rtapi task, but the timing is done by hal
[05:17:12] <jmkasunich> start = get_time()
[05:17:18] <SWPadnos> ok. I thought that was in rtai_rtapi.c
[05:17:30] <jmkasunich> the get-time implemenetation is in rtapi
[05:17:34] <SWPadnos> ok, just the get_time (clocks) function is there
[05:17:44] <jmkasunich> in hal it looks like this:
[05:17:48] <jmkasunich> start = get_time()
[05:17:55] <jmkasunich> while (functions to run)
[05:17:58] <jmkasunich> run function
[05:18:05] <jmkasunich> end = get_time()
[05:18:13] <jmkasunich> function time = end - start
[05:18:17] <jmkasunich> start = end
[05:18:24] <cradek> heh, that's more like it, I multiplied all jepler's vel/accel by ten and set FO 2000%
[05:18:30] <jmkasunich> next function
[05:18:32] <jmkasunich> }
[05:18:48] <SWPadnos> ok, so leave out the start=end, and do it once more after the loop, and it should be OK
[05:19:01] <SWPadnos> can threads export HAL pins/params?
[05:19:15] <jmkasunich> it would be real easy to save the original start in another variable, thread_start, and do thread_time = end - thread_start
[05:19:21] <SWPadnos> yes
[05:19:31] <jmkasunich> no, threads can't own anything, only components can
[05:19:34] <SWPadnos> ok
[05:20:03] <SWPadnos> but a thread should be able to write to a signal or param?
[05:20:08] <jmkasunich> yes
[05:20:15] <SWPadnos> duh - tmax and time
[05:20:30] <jmkasunich> I have an answer (sort of)
[05:20:37] <SWPadnos> threads can export the params
[05:20:40] <jmkasunich> the threads component exists to create threads
[05:20:41] <SWPadnos> but it gets unloaded
[05:20:55] <jmkasunich> we're thinging the same thing
[05:20:58] <SWPadnos> yep
[05:21:01] <jmkasunich> thinking even
[05:21:09] <SWPadnos> thinging the same think
[05:21:19] <jmkasunich> problem is that emc doesn't use threads
[05:21:25] <jmkasunich> the motion module creates the threads
[05:21:29] <SWPadnos> right - motion does that
[05:21:38] <SWPadnos> so maybe motion should have the params
[05:21:43] <SWPadnos> since it createsthe threads
[05:21:57] <SWPadnos> it has 7000 others, a few more won't hurt
[05:22:19] <jmkasunich> motion _could_ export params, and then use hackery (knowledge of HAL internal structs that it shouldn't have) to get the values from the thread struct and write them to the param
[05:22:35] <jmkasunich> crufty tho
[05:22:44] <SWPadnos> just have the threads write the params
[05:22:52] <jmkasunich> ?
[05:23:08] <jmkasunich> the code that makes the time measurements is part of hal_lib
[05:23:23] <jmkasunich> the measurement results get stored in the hal_thread structure
[05:23:54] <jmkasunich> that code doesn't know anything about any parameters that a module may or may not have exported, so it can't copy the data to the params
[05:23:54] <SWPadnos> where does that value get transferred into *.tmax and *.time?
[05:24:19] <jmkasunich> * jmkasunich looks
[05:24:27] <SWPadnos> well, I could have done that ;)
[05:24:35] <SWPadnos> don't you remember?
[05:24:50] <jmkasunich> I remember where to look ;-)
[05:26:06] <jmkasunich> ah, the .time and .tmax params are created when a function is exported, and belong to the same module that the function does
[05:26:15] <SWPadnos> yep
[05:26:21] <SWPadnos> in hal_create_funct
[05:26:25] <jmkasunich> those time values are stored in the function struct, not the thread struct
[05:26:37] <jmkasunich> hal_export_funct
[05:26:44] <SWPadnos> ok.
[05:26:49] <SWPadnos> right
[05:26:56] <SWPadnos> that's what I ... nevermind :)
[05:27:00] <jmkasunich> hal_lib.c:1194 or therabouts
[05:27:23] <SWPadnos> yep. just looking for hal_create_thread
[05:27:30] <jmkasunich> the params are created already pointing at the data in the funct struct, no copy needed
[05:27:36] <SWPadnos> 1196
[05:27:41] <SWPadnos> :)
[05:27:48] <jmkasunich> yep
[05:28:13] <jmkasunich> note that export_funct() is passed a component ID, create_thread is not
[05:28:23] <SWPadnos> yep
[05:28:25] <jmkasunich> threads and functs are analogous to signals and pins
[05:28:32] <jmkasunich> pins belong to modules, signals are global
[05:28:43] <jmkasunich> functs belong to modules, threads are global
[05:29:20] <SWPadnos> hmmm
[05:29:23] <jmkasunich> see line 1318
[05:29:40] <SWPadnos> #if 0?
[05:30:02] <jmkasunich> that code used to export params for the thread time and tmax
[05:30:04] <SWPadnos> ot the "may need to revisit during refactor"
[05:30:15] <jmkasunich> the entire if 0'ed block
[05:30:29] <SWPadnos> ah - ok
[05:30:42] <jmkasunich> it exported params, owned by the hal library itself
[05:30:51] <jmkasunich> that was back when I treated the library like a component
[05:30:59] <SWPadnos> right
[05:31:17] <jmkasunich> there is a convoluted story explaining why I changed that
[05:31:26] <jmkasunich> the shmem allocation is pretty crappy
[05:31:27] <SWPadnos> heh
[05:31:45] <fenn> that would be like a snake swallowing it's tail
[05:31:48] <jmkasunich> it reuses metadata (pin structs, param structs, thread structs, etc) but not data that was allocated to a module
[05:32:10] <SWPadnos> right, and it has a separate pool of each struct type, since they're fixed length
[05:32:26] <jmkasunich> so if you loadrt, unloadrt, loadrt, unloadrt the same module multiple times, you have a memory leak
[05:32:47] <SWPadnos> hmmm. that's a bad-ish thing
[05:33:03] <jmkasunich> my hack to fix that - whenever there are no modules at all loaded, free all shmem and start fresh
[05:33:20] <jmkasunich> welllll, if the hal lib itself is a module, then you never start fresh
[05:33:27] <SWPadnos> right
[05:33:33] <jmkasunich> besides, the library shouldn't be a module anyway
[05:33:58] <SWPadnos> maybe not, but then again ...
[05:34:24] <SWPadnos> library parts are statically linked into each component, right?
[05:34:29] <SWPadnos> like export_*
[05:34:38] <jmkasunich> I'm using "module" in the HAL module sense, not the kernel module sense
[05:34:43] <jmkasunich> nope
[05:34:50] <jmkasunich> the RT version of the library is a kernel module
[05:35:03] <SWPadnos> ok - shared libs for userspace
[05:35:20] <jmkasunich> if a RT hal component (another kernel module) calls export_funct, that linkage is done at insmod time
[05:36:03] <SWPadnos> ok, so it's linked like a kernel module, but it doesn't act like a HAL module
[05:36:14] <jmkasunich> when you do rmmod, the hal component calls hal exit which destroys all objects (pins, params, functs) exported by the module
[05:36:42] <jmkasunich> so "it's" linked... "it's" = hal_lib?
[05:36:51] <SWPadnos> yes - sorry
[05:37:06] <SWPadnos> the RT version ofthe library
[05:37:09] <jmkasunich> you got it, hal_lib is a kernel module that implements the HAL api
[05:37:31] <jmkasunich> RT HAL modules are kernel modules that call the API to register HAL functions and stuff
[05:37:48] <SWPadnos> yep.
[05:38:29] <jmkasunich> on the user side, hal_lib.o is currently statically linked to each user space program, but thats just because I don't know shared library fu.. there is no fundamental reason it couldn't be a shared lib
[05:38:34] <cradek> jmkasunich: can you think of anything that would change stepgen.1.maxaccel after emc starts?
[05:38:37] <SWPadnos> well, it's a hack, but all the functions attached to a thread can have a threadtime and threadmax param, and the last one gets populated ;)
[05:39:35] <jmkasunich> swp: actually I think they'd all get populated
[05:39:39] <jmkasunich> cradek: thinking
[05:40:07] <cradek> I got following errors that I couldn't explain with halscope, so I tried halcmd show, and my maxvel is set too low
[05:40:08] <SWPadnos> hmm - you could change it so that each gets the total thread time elapsed instead of the funftion time
[05:40:13] <SWPadnos> function
[05:40:22] <jmkasunich> did you say max accel or max vel?
[05:40:22] <cradek> setp stepgen.1.maxvel [AXIS_1]STEPGEN_MAXVEL
[05:40:27] <cradek> STEPGEN_MAXVEL = 5
[05:40:31] <cradek> 04 float -W 2.48578e+00 stepgen.1.maxvel
[05:40:51] <jmkasunich> max vel is limited to the maximum steprate (determined by base period), scaled to position units
[05:41:11] <cradek> ah
[05:41:17] <jmkasunich> so if period is 50uS, max step rate is 10,000 steps/sec
[05:41:27] <cradek> scale 4000
[05:41:37] <jmkasunich> then max vel is 2.5
[05:41:43] <SWPadnos> ish
[05:41:44] <cradek> thank you
[05:41:48] <cradek> I would have wondered for an hour
[05:42:22] <cradek> changing base period from 50 to 20 fixed it, thanks
[05:42:29] <jmkasunich> np
[05:42:39] <jmkasunich> swp: I'd rather add new params
[05:42:44] <SWPadnos> yep
[05:42:49] <jmkasunich> heh, better yet
[05:42:51] <SWPadnos> they can just have a running total
[05:43:02] <jmkasunich> no need
[05:43:16] <jmkasunich> crap, never mind
[05:43:21] <SWPadnos> the new params
[05:43:38] <jmkasunich> when you export a param (for instance during export function) you have to specify the location of the data
[05:43:41] <SWPadnos> the last one would then have the thread total (more or less), and you can even calculate the thread overhead
[05:44:00] <SWPadnos> the funct struct would need two more numbers
[05:44:00] <jmkasunich> except that when you export a function, you haven't yet added it to a thread, so you don't know where the thread total is yet
[05:44:27] <SWPadnos> each funct gets a time, tmax, threadtime, and threadmax var
[05:45:21] <SWPadnos> keep thread_start, and add a couple of extra lines to the thread loop to populate thread{time,max} with end - thread_start
[05:45:24] <jmkasunich> that could work, but I don't like it
[05:45:36] <SWPadnos> as I said, it's a hack
[05:45:52] <SWPadnos> since every function, including all those unused ones, will get two more extra unused parameters
[05:46:07] <jmkasunich> yeah
[05:46:22] <SWPadnos> but it does give extra info as well - the thread loop overhead
[05:46:36] <jmkasunich> not really
[05:46:42] <jmkasunich> (not the overhead)
[05:46:54] <jmkasunich> time is still measured only once per pass thru the loop
[05:47:24] <SWPadnos> yes it does. funcN.threadtime - func(N-1).threadtime will be different from funcN.time by the thread overhead
[05:47:32] <jmkasunich> t(n) - t(n-1) = sum of function N and loop overhead, no way to split the two
[05:47:49] <SWPadnos> except that the funcN.time is there also
[05:48:05] <SWPadnos> the difference is due to the reassignment of start during the loop
[05:48:14] <SWPadnos> but there's no reassignment of thread_start
[05:48:31] <jmkasunich> call each measurement t[something]
[05:48:37] <jmkasunich> threadstart = t[0]
[05:48:49] <jmkasunich> end of funct 1 = t[1]
[05:48:58] <jmkasunich> end of funct 2 = t[2]
[05:49:00] <jmkasunich> etc
[05:49:17] <jmkasunich> end of funct last = t[last]
[05:49:24] <jmkasunich> end of loop is also t[last]
[05:49:27] <SWPadnos> yep. one sec - thinking
[05:49:45] <SWPadnos> ok. you're right
[05:50:02] <jmkasunich> for time you gain no new info, it just saves adding
[05:50:20] <SWPadnos> right
[05:50:24] <jmkasunich> for tmax, you do gain, because the inidividual tmax's aren't from the same run
[05:50:29] <SWPadnos> yep
[05:51:54] <SWPadnos> oops. bedtime, I think
[05:52:05] <jmkasunich> I was just thinking the same
[05:52:54] <SWPadnos> I guess it might be easier to just have halcmd add up the funct.time params ;)
[05:53:06] <SWPadnos> but not as accurate for tmax
[05:53:20] <jmkasunich> we can still capture the data and let halcmd print it
[05:53:29] <cradek> jmkasunich: the spiral works fine; it just slows down a bit when the segments get short.
[05:53:32] <jmkasunich> we just cant send it to a parameter for scope/halmeter
[05:53:40] <jmkasunich> cool
[05:53:53] <cradek> and the path turns into one giant yellow blend that follows the path correctly
[05:53:56] <SWPadnos> yeah -the thread data struct would be a better place for those times
[05:54:18] <jmkasunich> I'm not sure (closed the editor already) but I think they're already there
[05:54:31] <jmkasunich> or at least, the code is there but #if 0'ed out
[05:54:31] <SWPadnos> I wonder if someone should twise Les' arm and get him to try the latest EMC2?
[05:54:42] <cradek> he said he needs a new machine first.
[05:54:45] <jmkasunich> he's talked about it, he has computer issues
[05:54:49] <SWPadnos> ah
[05:54:51] <cradek> not sure if that's true...
[05:54:51] <jmkasunich> still running a 2.4 kernel
[05:54:57] <cradek> more importantly, he has isa bus issues
[05:55:08] <jmkasunich> STG card?
[05:55:10] <cradek> yes
[05:55:23] <cradek> I bet he could build emc2 with a little work.
[05:55:32] <jmkasunich> he should pull his disk, set it aside, and stick another disk in there, then install ubuntu
[05:55:39] <cradek> I agree
[05:55:40] <SWPadnos> ok. runtime and maxtime
[05:56:11] <jmkasunich> the build system is broken for older gcc's, so he'll need to update his kernel
[05:56:28] <SWPadnos> hence the new HD ;)
[05:56:30] <cradek> kernel has nothing to do with gcc
[05:56:32] <jmkasunich> which unless he's into kernel building (not) either BDI-4 or ubuntu
[05:56:43] <cradek> emc2 will run on a 2.4 kernel fine
[05:56:49] <jmkasunich> emc needs built with the same gcc that compiled the kernel and rtai
[05:56:58] <cradek> but it needs gcc3 (in addition to the gcc that compiled the kernel) to build
[05:57:11] <SWPadnos> as I recall, he had a problem with the network (or that could have been Paul, at Les' place)
[05:57:12] <cradek> it's fine if they are different, like on bdi4
[05:57:13] <jmkasunich> and the older BDI-s (pre 4.xx) used gcc-2.xx)
[05:57:23] <cradek> bdi4 still uses 2.95
[05:57:26] <cradek> but it also has gcc3 on it
[05:57:43] <cradek> bdi live (?) is the same way
[05:58:06] <jmkasunich> must be, it compiles
[05:58:12] <jmkasunich> (according to the farm)
[05:58:14] <cradek> right
[05:58:25] <cradek> but yeah, I also think les should install ubuntu on a new disk.
[05:58:38] <jmkasunich> safe and easy
[05:58:42] <cradek> let's start working on him :-)
[05:59:03] <Jymmm> * Jymmm just shakes his head *
[05:59:04] <SWPadnos> the compile farm clocks are off, I think
[05:59:05] <jmkasunich> I can even donate the disk if he's feeling cheap
[05:59:10] <cradek> I wonder if dave-e has any hard-earned lessons he could share
[05:59:15] <jmkasunich> SWP: how so?
[05:59:22] <jmkasunich> they're on UTC
[05:59:28] <SWPadnos> they have the latest build at 3/9/06, 5:38 AM
[05:59:30] <SWPadnos> ok
[05:59:38] <SWPadnos> that would be off from EST5EDT ;)
[05:59:53] <cradek> arg, midnight
[05:59:58] <jmkasunich> 1am
[06:00:00] <cradek> this has been a productive evening, guys, but it's over
[06:00:02] <SWPadnos> nope - 1AM
[06:00:08] <SWPadnos> night cradek
[06:00:10] <jmkasunich> they're still a little off, they drift
[06:00:23] <cradek> g'night
[06:00:24] <SWPadnos> yep, but not by the 5 hours I was thinking
[06:00:25] <jmkasunich> I tried getting ntp to work (I think it does work on the bdi-4 slot)
[06:00:34] <jmkasunich> night cradek
[06:01:03] <SWPadnos> well. I can add that timekeeping to the thread code, and also to halcmd for display if you like
[06:01:20] <Jymmm> Other than making a fixture, can anyone think of a way to drill angled holes - say 7 to 10 degrees?
[06:01:25] <jmkasunich> did you say the fields are already in the struct?
[06:01:30] <SWPadnos> get a 5-axis machine
[06:01:37] <SWPadnos> jmkasunich, yep, they're there
[06:01:39] <Jymmm> SWPadnos lol
[06:01:43] <jmkasunich> tilt the drill press table
[06:01:49] <SWPadnos> hexapod
[06:01:58] <SWPadnos> hexa-head, plus 3 cartesian axes
[06:01:59] <Jymmm> jmkasunich not for 120 holes I aint
[06:02:09] <SWPadnos> get a slanted drill ;)
[06:02:10] <Jymmm> ok wiht a 3 axis machine... hows that?
[06:02:18] <SWPadnos> get a sine vise
[06:02:40] <SWPadnos> if you need to do different angles, then you need another axis or two
[06:03:07] <Jymmm> SWPadnos well aint gonna happen for a while; guess I'll deal with the fixture
[06:03:26] <SWPadnos> right. that's good for one angle (at a time)
[06:03:50] <SWPadnos> I think there's no easy way other than another axis if you need to vary the angle in the same program
[06:04:49] <jmkasunich> swp: so the fields are in the struct but the code to set them isn't in (after) the thread loop?
[06:04:53] <Jymmm> I just need to figure out how to vary the z depth in the gcode
[06:04:55] <jmkasunich> feel free to add it then
[06:05:28] <SWPadnos> jmkasunich, I think so. I'll do that tomorrow unless I get interrupted
[06:05:34] <jmkasunich> thanks
[06:06:00] <SWPadnos> Jymmm, the Z depth to account for the tilt of the workpiece?
[06:06:35] <Jymmm> SWPadnos: yeah.... Need to drill 120 angled holes and glue in pegs
[06:06:48] <SWPadnos> big coat/key rack
[06:07:00] <Jymmm> SWPadnos yep, you got it
[06:07:03] <SWPadnos> heh
[06:07:28] <SWPadnos> how are you generating the G-code?
[06:07:32] <Jymmm> figure I'd prop up one side of the material by 1/4" for the tile
[06:07:36] <SWPadnos> yep
[06:07:45] <Jymmm> err tilt
[06:08:19] <SWPadnos> maybe more - you need to get it to the same angle you want the pegs to point at (well, 90deg -that angle)
[06:08:39] <Jymmm> not sure yet on the gcode... If I can figure out how to draw a tapered plate, I'd be good to go.
[06:08:50] <jmkasunich> Jymm: drill the holes straight, then mill the angle into the part ;-)
[06:09:00] <Jymmm> jmkasunich LOL
[06:09:16] <jmkasunich> how big are the holes?
[06:09:21] <jmkasunich> and how deep?
[06:09:21] <Jymmm> 1/4"
[06:09:23] <SWPadnos> what emc are you using?
[06:09:28] <Jymmm> 3/8" deep
[06:09:34] <Jymmm> SWPadnos TurboCNC
[06:09:40] <SWPadnos> that's not emc
[06:09:42] <jmkasunich> what material?
[06:09:45] <Jymmm> SWPadnos It's not?
[06:09:48] <Jymmm> jmkasunich pine
[06:09:53] <SWPadnos> get off this channel!
[06:09:57] <SWPadnos> :)
[06:10:10] <Jymmm> SWPadnos Fine....
[06:10:15] <SWPadnos> I was going to say - you could use loops if you use emc2
[06:10:17] <Jymmm> Jymmm has kicked Jymmm from #emc
[06:10:19] <SWPadnos> heh
[06:10:37] <SWPadnos> what a maroon ;)
[06:10:48] <Jymmm> happy SWPadnos ?
[06:10:51] <SWPadnos> he's back - kick him!
[06:10:58] <SWPadnos> yep - laughed out loud, actually
[06:11:03] <Jymmm> =)
[06:11:19] <SWPadnos> well - loops are probably out of the question
[06:11:30] <Jymmm> jmkasunich the material is pine.
[06:11:39] <SWPadnos> what kind of angle do you want for the pegs?
[06:11:51] <SWPadnos> like 15-20 deg. up?
[06:12:10] <SWPadnos> actually - use 30 degrees
[06:12:15] <Jymmm> maybe 7 degress... just enough to hold spools of embroidery thread (5" tall)
[06:12:24] <SWPadnos> sin(30) = 1/2
[06:12:26] <SWPadnos> oh
[06:13:06] <Jymmm> something that'll survive a 3.5 earthquake would be nice =)
[06:13:20] <SWPadnos> ok. how big is the overall sheet size?
[06:13:33] <SWPadnos> well, it'll survive, but the floss will be on the ground ;)
[06:13:49] <Jymmm> 4" wide x 48 to 96" long
[06:14:00] <SWPadnos> and the hole spacing?
[06:14:04] <Jymmm> well, 4" x 24"
[06:14:25] <SWPadnos> 24" apart?
[06:14:32] <Jymmm> staggered zig zag pattern... about 3"
[06:14:39] <SWPadnos> ok.
[06:14:41] <Jymmm> /\/\/\/\/\
[06:14:45] <SWPadnos> right
[06:15:13] <SWPadnos> do this. raise the top of the board by 1/8 of the height
[06:15:20] <SWPadnos> so for a 24" tall board, raise 3 inches
[06:15:32] <SWPadnos> that'll give you just over 7 degrees of tilt
[06:16:03] <SWPadnos> when you generate / write the G-code, move Z down by an extra 1/8 inch for each inch you move away from the top
[06:16:16] <SWPadnos> (assuming that you touch off at the top for Z=0)
[06:16:28] <Jymmm> z 0 tom
[06:16:42] <SWPadnos> this is earth to major tom
[06:16:58] <Jymmm> TOM == Top Of Material
[06:17:04] <SWPadnos> oh, TOM
[06:17:21] <Jymmm> why the added 1/8" ?
[06:17:34] <SWPadnos> because that's the slant of the top surface of the wood
[06:17:46] <lilo> [Global Notice] Hi all. One of our main rotation servers is misbehaving. It's back, but dropping users, and has been removed from rotation. We're looking at the issue. Any additional info will be on wallops ( /mode yournick +w )....thanks.
[06:18:24] <Jymmm> wouldn't I just be (in essence) just staircasing the drilling depth?
[06:18:29] <SWPadnos> yes
[06:18:30] <fenn> this sounds like a job for a drill press
[06:18:56] <Jymmm> fenn 120 holes on a drill press? ha!
[06:19:10] <SWPadnos> but the rapid moves between holes can use a Z offset, and the drill code can be the same (relative)
[06:19:33] <fenn> jymmm you ain't seen nothin: http://forums.bit-tech.net/showthread.php?t=105157
[06:19:50] <Jymmm> SWPadnos: Ok, x0 is 3" higher than x24...
[06:20:03] <SWPadnos> right
[06:20:27] <Jymmm> SWPadnos: Could I just set Z0 when at x0, then Z-3 when x24 ?
[06:20:50] <fenn> this image in particular http://www.etfos.hr/~ikocis/vodeno/IMG_0684.JPG
[06:20:55] <Jymmm> basically making the holes "deeper" so to speak
[06:21:18] <SWPadnos> that's what you're doing
[06:21:22] <SWPadnos> yes
[06:21:44] <SWPadnos> it'll take a bit longer, but will work just as well, and will probably be easier to code
[06:21:46] <Jymmm> SWPadnos Oh, I see what your saying... I was thinking something else.
[06:22:29] <SWPadnos> mach3 actually could do this without trouble - you can set one axis to follow another
[06:22:38] <SWPadnos> for squaring non-square machines
[06:23:41] <Jymmm> fenn: If I need to water cool my cpu... I 'll just go buy a radiator for a yugo.
[06:23:54] <Jymmm> or motorcycle
[06:24:17] <fenn> an oil cooler would be about right
[06:24:41] <SWPadnos> damn - that guy is a nut
[06:24:47] <Jymmm> fenn: I never actualyl said I would fill it with water =)
[06:24:56] <SWPadnos> good work for crappy tools though
[06:25:29] <Jymmm> fenn: I'd hop up to the winery and get a couple gallons of gylceroal
[06:26:38] <fenn> Jymmm: i mean the right size
[06:27:01] <fenn> hmm..
[06:27:27] <Jymmm> fenn: I've never towed anything, so never really seen an oil cooler. oh wait... that's about 8" x 12" right?
[06:27:55] <fenn> yeah
[06:28:17] <fenn> glycerol has a high heat capacity and doesn't conduct electricity?
[06:28:38] <Jymmm> it's a food grade coolant
[06:28:46] <Jymmm> that stuff I'm talking about...
[06:29:02] <fenn> hmm boiling point 290C
[06:29:52] <fenn> i wonder how flammable it is
[06:30:52] <Jymmm> No idea, jsut the shit gets damn cold!
[06:31:43] <Jymmm> SWPadnos: he's not a nut... just dedicated =)
[06:32:06] <fenn> same thing
[06:32:23] <Jymmm> Do you realize what he's probably been doing for months any of use could fabricate in a few hours.
[06:32:24] <SWPadnos> both
[06:32:40] <Jymmm> Do you realize what he's probably been doing for months, any of us could fabricate in a few hours.
[06:32:56] <SWPadnos> if we had running tools ;)
[06:32:58] <fenn> i hate it when people double-post like that
[06:33:03] <SWPadnos> if we had running tools ;)
[06:33:08] <fenn> i read the line like 6 times looking for the typo
[06:34:15] <Jymmm> SWPadnos yours isn't running?
[06:35:09] <fenn> nah he shoulda started small - that'll teach him
[06:35:15] <SWPadnos> nope
[06:35:21] <SWPadnos> well, it runs, but not CNC
[06:37:04] <SWPadnos> I really should finish up the designs for the motor mounts.
[06:37:15] <SWPadnos> I can mill them on a friend's BP
[06:37:33] <fenn> friend's cnc BP?
[06:37:38] <SWPadnos> yep
[06:37:49] <fenn> ah good then you can share, right? :)
[06:37:51] <SWPadnos> or his manual
[06:37:55] <SWPadnos> yep.
[06:38:22] <SWPadnos> I've searched for plans for BP motor mounts, and haven't found any (free)
[06:38:42] <SWPadnos> actually, I haven't even been able to fine the bolt pattern and screw location
[06:39:05] <fenn> Glycerol has about half the specific heat capacity and half the thermal conductivity of water, and a similar freezing point, but a 66% solution of glycerol/water has a freezing point of -43C
[06:39:06] <SWPadnos> it seems that anyone who figures it out wants to sell you their mount kit for $2000
[06:40:31] <Jymmm> SWPadnos grab a ruler and a camera
[06:40:59] <SWPadnos> hmmm - I may do that
[06:41:15] <fenn> isn't it just a square bolt pattern?
[06:41:17] <Jymmm> you can use software to get the real dimensions
[06:41:30] <SWPadnos> getting perfectly on axis can be a pain, but it's easier than measuring 2-D things in 3-D
[06:41:33] <fenn> take a pair of calipers and two bolts...
[06:41:43] <SWPadnos> the Y axis is a rectabngular pattern
[06:42:02] <SWPadnos> it's not the distance between bolts, it's the center of the ballscrew relative to those bolts
[06:42:16] <fenn> can't you measure that distance?
[06:42:37] <fenn> the triangle between bolts 1, 2, and the screw
[06:42:50] <SWPadnos> it's not easy, because the screw is irregular, and it isn't in the right place if you remove the bearing bracket
[06:43:02] <Jymmm> http://www.microkinetics.com/convkit.htm
[06:43:08] <Jymmm> $700
[06:43:12] <fenn> ah you may have to pull a trick like les mentioned for machining ballscrew ends
[06:43:28] <fenn> make a sleeve that fits over ball bearings that touch the bottom of the ballscrew grooves
[06:43:30] <SWPadnos> I have machined screws
[06:43:34] <SWPadnos> ah - right
[06:43:42] <SWPadnos> if only I had a lathe ;)
[06:43:45] <fenn> gah
[06:43:53] <fenn> get one - you won't be disappointed
[06:44:02] <fenn> a little one will do
[06:44:29] <fenn> or make a "fonly lathe" :)
[06:44:35] <SWPadnos> Jymmm, I've seen that kit, though I didn't find it the last time I was looking for them
[06:44:50] <SWPadnos> I can just use my friend's 5HP Takasawa ;)
[06:45:17] <Jymmm> SWPadnos: then this one should scare the shit out of ya (price wise) http://www.centroidcnc.com/bridgeportkneemill.htm
[06:45:32] <SWPadnos> yep - I don't even have to look at the page
[06:45:46] <SWPadnos> I really like the space saver design from elrod machine though
[06:46:24] <SWPadnos> http://www.elrodmachine.com/x&y.htm
[06:46:48] <SWPadnos> I need the space saving design, since the machine is in a corner of the garage
[06:46:56] <SWPadnos> (and we still have to park 2 vehicles in there)
[06:47:17] <Jymmm> SWPadnos: You KNOW you would give up parking in the garage if you had to =)
[06:47:28] <SWPadnos> I would, but not in winter ;)
[06:47:35] <fenn> looks like it sticks pretty far off the end
[06:47:42] <SWPadnos> not the space saver
[06:47:49] <SWPadnos> the black one in the second photo down
[06:47:57] <Jymmm> SWPadnos: Fine.... cut a hole in the wall
[06:48:07] <SWPadnos> the concrete wall - good idea
[06:48:19] <SWPadnos> http://www.elrodmachine.com/images/XY%20BracketssXbrkt3.jpg
[06:48:21] <fenn> oh the one with the orange cap
[06:48:29] <Jymmm> SWPadnos what? you can't get fireworks out there?
[06:48:37] <SWPadnos> nope - illegal
[06:48:45] <Jymmm> SWPadnos and your point is?
[06:49:22] <SWPadnos> illegal and unavailable ;)
[06:49:31] <SWPadnos> unless I go to canada
[06:49:33] <Jymmm> NOTHING is ever unavailable
[06:49:49] <SWPadnos> but then I'd be arrested as a terrorist when I try to come back
[06:50:02] <fenn> smuggling illegal explosives across the border eh?
[06:50:04] <SWPadnos> (with all those explosives in the car)
[06:50:05] <Jymmm> Nah.... get a permit from ATM
[06:50:09] <Jymmm> ATF
[06:50:18] <fenn> AFC
[06:50:22] <fenn> ARA
[06:50:23] <Jymmm> SWPadnos well, less than 50 lbs and you'll be ok
[06:50:56] <SWPadnos> well, that's assuming that I want to put a hole in my foundation
[06:51:46] <fenn> is there a particular reason for the ratio between the length and diameter of a motor
[06:51:55] <fenn> big servos always seem too skinny
[06:52:08] <SWPadnos> good servos are generally long and thin
[06:52:16] <SWPadnos> they have less rotational inertia that way
[06:52:26] <SWPadnos> since it's proportional to r^2
[06:52:35] <Jymmm> SWPadnos: $100 http://www.atf.gov/firearms/nlc/explosives/explo_types.htm
[06:53:02] <Jymmm> bastards raised their prices agian!
[06:53:07] <SWPadnos> oh, yay.
[06:53:33] <SWPadnos> I think little fireworks are now legal here, but Vermont has more strict rules than ATF
[06:54:09] <Jymmm> But, I bet those vermont rules are under NON-LICENSED usage
[06:54:28] <Jymmm> ATF Permit is a Get out of jail card
[06:54:42] <Jymmm> or in this case... never go to jail card =)
[06:54:55] <SWPadnos> use and sale, but yes, I might be able to geta license so I can go to NY or Canada and come home to blow up part of my house
[06:55:07] <SWPadnos> sounds like a plan ;)
[06:55:12] <Jymmm> lol
[06:56:13] <Jymmm> you know you want to =)
[07:00:20] <SWPadnos> well. it is, in fact, bedtime.
[07:00:23] <SWPadnos> good night guys
[07:00:29] <Jymmm> G'Night SWPadnos
[07:00:34] <SWPadnos> SWPadnos is now known as SWP_Away
[07:00:50] <Jymmm> thanks guys for the help with the hole drilling!!!
[10:55:29] <giacus> morning
[11:44:07] <giacus> robin_sz: around ?
[13:00:28] <CIA-8> 03jepler * 10emc2/nc_files/tort.ngc:
[13:00:28] <CIA-8> tort.ngc is automatically generated by a python program. This file, used with
[13:00:28] <CIA-8> a stepper configuration with no headroom, and different axis accelerations
[13:00:28] <CIA-8> and velocities, has turned up several tp bugs.
[13:04:59] <CIA-8> 03jepler * 10emc2/scripts/torture.py: new script creates torture-test ngc files
[13:06:19] <jepler> cradek: did you fix the line 231 problem or the line 270 problem?
[13:06:22] <jepler> cradek: or both?
[13:07:14] <cradek> I fixed 231 and never saw a 270 problem
[13:07:24] <cradek> maybe it was the same problem
[13:07:37] <cradek> it was a helix issue
[13:09:10] <jepler> I thought you said line 270
[13:09:15] <jepler> wasn't there another problem?
[13:09:23] <cradek> hmm
[13:09:27] <jepler> oh, you did say 230, not 270.
[13:09:31] <cradek> oh good
[13:09:32] <jepler> so it was the same problem
[13:09:56] <cradek> yeah, helix
[13:13:41] <jepler> I would love to watch/hear part of this file on a real machine
[13:13:56] <cradek> yeah let's do that soon
[13:14:17] <jepler> yay it's done
[13:14:20] <cradek> there's a torture case that tort doesn't trigger - arcs where rotary axes also change
[13:14:30] <cradek> I bet they are wrong (and I bet nobody cares)
[13:14:41] <jepler> I could add rotary axis to it; it wouldn't be hard
[13:14:49] <cradek> that might be nice
[13:14:52] <cradek> what's done?
[13:15:07] <jepler> I ran the last 65 lines of tort.ngc after a rebuild
[13:15:22] <jepler> you think an XYZA version of torture.py, or a full XYZABC one?
[13:15:35] <jepler> XYZA you actually have a chance of understanding on screen
[13:15:39] <cradek> true
[13:15:43] <cradek> how about xyza
[13:19:41] <jepler> my machine has no "A" axis but this program was accepted
[13:20:35] <jepler> some of the segments go torturously slowly when "A" changes
[13:21:03] <cradek> that's interesting
[13:21:14] <cradek> when A changes a lot?
[13:21:26] <cradek> see you later
[13:23:19] <jepler> joint 3 following error [OK]
[13:23:27] <jepler> on line .. 4!
[13:24:13] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/torture-xyza-noheadroom.ini
[13:24:17] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/tort-xyza.ngc
[13:29:54] <jepler> G0 X0 Y0 Z20
[13:29:58] <jepler> G19 G3 F770 (329 0) J-7.794229 K4.500000 X3.000000 Y1.205771 Z24.500000
[13:55:51] <cncuser> good morning
[13:57:25] <skunkworks> how is puppy going?
[13:57:34] <cncuser> skunkworks: seems ok
[13:58:37] <cncuser> updated version with correct readme in the configdir and gtkcalc http://cooltool.he.fdread.org/cncforum/coolcnc/coolcncb05.iso
[13:59:11] <cncuser> anyone good at regexp (sed, awk) ?
[13:59:16] <skunkworks> is this head or testing?
[13:59:36] <cncuser> i need to get foo till .!? from a string
[13:59:42] <cncuser> = extract a sentence
[13:59:48] <cncuser> skunkworks: head
[13:59:57] <skunkworks> nice - sorry no.
[13:59:58] <cncuser> 2 days ago head
[14:06:13] <jepler> cncuser: what language's regexp? They're all a little bit different, it seems like
[14:07:48] <cncuser> jepler: id like to use it in a bash script, available is awk and sed
[14:07:58] <jepler> oh look that's what you said the first time
[14:08:26] <cncuser> :)
[14:08:33] <cncuser> stuck in a loop ;)
[14:09:10] <jepler> >>> s = "See Jack run. Run Jack, Run."
[14:09:10] <jepler> >>> r = re.compile("(.*?[.!?])(?: |$)", re.DOTALL)
[14:09:10] <jepler> >>> r.findall(s)
[14:09:10] <jepler> ['See Jack run.', ' Run Jack, Run.']
[14:09:13] <jepler> here's the Python version
[14:09:20] <jepler> but I don't know if all these things can translate to awk or sed
[14:09:34] <cncuser> hmm, some escaping shgould do it
[14:09:50] <jepler> that says "find the minimum number of characters followed by one of [.!?] followed by space or the end of the line"
[14:10:23] <jepler> (?:...) means to not include whatever matched ... in the results
[14:10:31] <cncuser> ok. but i need Foo as startargument.. ok, i can do that afterwards. thanks
[14:10:45] <cncuser> lets see :)
[14:11:27] <jepler> awk doesn't seem to have "non-greedy match", which Python has as "*?".
[14:14:23] <jepler> (If you write the regular expression 'a.*?a' and match the string 'ababa', you get a 3-character match starting at the beginning, not a 5-character match; with 'a.*a' you get a 5 character match)
[15:12:08] <cncuser> hmm... das hab i hier gestern abgestaubt.... und i bekomms ned zum laufen s/foo$.!?$/\1/
[15:12:15] <cncuser> sorry
[15:12:23] <cncuser> wrong window ;)
[15:21:35] <alex_joni> heh
[15:24:59] <jepler> cradek: you should fix up torture-xyza-noheaderoom.ini and run the tort-xyza.ngc test
[15:26:51] <giacus> anyone know the max lenght and size for a stepper motor cable ?
[15:26:59] <alex_joni> * alex_joni finished the hardest day ever ;)
[15:27:02] <alex_joni> going home now..
[15:30:43] <cradek> jepler: I have an ini ready to try, where is tort-xyza.ngc?
[15:32:02] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/tort-xyza.ngc
[15:34:42] <cradek> jepler: let me know when you're done so I can try it
[15:36:21] <jepler> cradek: I don't think I'm running emc on install2
[15:36:28] <jepler> am I?
[15:36:31] <cradek> oh ... I am
[15:36:32] <cradek> duh
[15:36:49] <jepler> though actually if I can make one short run before you start that would be great
[15:37:05] <jepler> I've written "install completely inside emc2 directlry if using run-in-place"
[15:37:08] <cradek> it's all yours
[15:37:20] <cradek> that sounds nice
[15:39:12] <jepler> It seems to work .. I'll commit it (but I probably broke emc1+axis by removing all the axis stuff from /usr)
[15:40:04] <jepler> well, and your emc2+axis too
[15:40:14] <jepler> anyway, I'm done
[15:40:24] <skunkworks> Jepler - I am lost. I am trying to make the amount of time around the spiro to work but I don't think the 2*pi*lcm(R+r,r) - if I have R=5 and r=2 It takes 720 deg to complete and if I have R=4 and r=2 it takes 360 degrees to complete.
[15:40:52] <skunkworks> I am not seeing the pattern or finding info online.
[15:41:56] <cradek> jepler: works for me, yay, that's nice
[15:42:50] <jepler> skunkworks: I wasn't sure of the lcm(R+r,r) myself
[15:43:19] <jepler> skunkworks: it has to do something with when k*(R+r)/r is an integer, though
[15:44:06] <skunkworks> Ok - I will do some more research. Thanks
[15:44:10] <jepler> skunkworks: If you're using O-codes then you should be using 360s, not 2*pis .. I think sin and cos are in degrees in emc
[15:44:35] <skunkworks> right - but it still doesn't come out right - I know yours is in radians
[15:45:12] <jepler> is it r/gcd(R+r,r) circles?
[15:46:48] <jepler> (1 circle == 360 degrees or 2pi radians)
[15:46:55] <skunkworks> right
[15:47:22] <jepler> "Let a:=1, b:=p/q where p, q are coprime. Then the formula has a period of 2*?*p. If b is irrational, the formula is nonperiodic."
[15:47:29] <jepler> http://www.xahlee.org/SpecialPlaneCurves_dir/EpiHypocycloid_dir/epiHypocycloid.html under "formulas"
[15:47:39] <skunkworks> cool thanks
[15:47:42] <jepler> (huh -- xah lee has written something besides incoherent rants against python. who'd have thought it)
[15:48:01] <jepler> (that's "the formula has period of 2*pi*p")
[15:53:33] <cncuser> jepler: regarding the joint following error... it was tried on severall computers now. what was the setup ? CPU/RAM ?
[16:01:43] <jepler> cncuser: 300MHz laptop, 128(?) megs RAM
[16:02:01] <jepler> cncuser: I repeated it twice and got the same following error each time
[16:06:27] <cncuser> thanks jepler, ill try to reproduce
[16:46:55] <giacus> hola
[16:55:57] <skunkworks> Jepler - seems like it is R/r as a fraction reduced. then the denominator is the number of times around.
[16:56:43] <skunkworks> so R=5 and r=2 = it is 2. R=4 and r=2 - that reduces to 2/1 sor it is 1
[16:57:06] <jepler> skunkworks: OK, I can believe that
[16:57:39] <skunkworks> so far anyways :)
[17:00:37] <skunkworks> so R=9 and r=6 - that reduces to 3/2 - so 2 times around (720) that works also.
[17:00:54] <skunkworks> looks good
[17:01:40] <jepler> is R=10 r=4 identical to R=5 r=2?
[17:03:06] <skunkworks> differnt shape - same amount around the circle. Just tried 9/6 vs 3/2 - same 720 deg around but smaller.
[17:03:20] <skunkworks> and shaped differnt
[17:04:36] <skunkworks> if thats what you where wondering.
[17:04:53] <SWP_Away> SWP_Away is now known as SWPadnos
[17:05:00] <SWPadnos> I think it depends on which circle you're calculating the rotations for
[17:10:05] <skunkworks> using x = (R+r)*cos(t) - (r+O)*cos(((R+r)/r)*t)
[17:10:05] <skunkworks> y = (R+r)*sin(t) - (r+O)*sin(((R+r)/r)*t)
[17:10:33] <skunkworks> O seems to have no effect on the degrees around.
[17:10:43] <skunkworks> just R and r
[17:10:52] <SWPadnos> it's the distance along the unner radius, I think (which hole you stick the pen in)
[17:10:56] <SWPadnos> inner radius
[17:11:41] <SWPadnos> the two radii determine the periodicity, but if you put the pen e.g. at the center of the moving circle, you won't get any loops
[17:12:06] <skunkworks> right (makes sense) ;)
[17:12:19] <skunkworks> I can acually visualize that ;)
[17:12:26] <SWPadnos> and, interestingly, that case has repetition after 1 traversal, which is R/r rotations
[17:12:45] <SWPadnos> (of the inner circlr)
[17:12:47] <SWPadnos> circle
[17:23:21] <SWPadnos> hmmm, the rotation rate of the inner circle isn't quite what you'd think either, it's one less rotation than expected on every traversal
[17:23:41] <SWPadnos> (and one extra if traveling on the outside of the larger circle)
[17:25:14] <SWPadnos> wait, those numbers may not be exactly one
[17:25:39] <SWPadnos> (of course, I could just look up planetary gear formulas, instead of dreriving them myself ;) )
[17:27:19] <skunkworks> I think it is 360*(r/gcd(R,r)) <- does that make sense?
[17:27:39] <SWPadnos> the repetition period?
[17:27:57] <skunkworks> the number of degrees around to get back to the starting point
[17:28:16] <skunkworks> yes repitition period ;)
[17:28:28] <SWPadnos> hmmm - as you reduce r, the period should go up, and I can't tell if that happens ;)
[17:29:06] <SWPadnos> there are two constraints to satisfy for "repetition"
[17:29:19] <SWPadnos> one, the inner circle has to be at the start position
[17:29:34] <SWPadnos> two, the inner circle must be in the starting orientation
[17:30:23] <SWPadnos> start position is easy, that's something like 360*(R/r+1)
[17:31:13] <SWPadnos> starting orientation means that whatever the previous equation gives, it has to be a multiple of 360 (or 2*pi)
[17:31:46] <SWPadnos> so the lcm should be between the rotations/revolution and one full circle
[17:32:31] <SWPadnos> did that make sense?
[17:33:54] <skunkworks> I think I am lost a little. ;) I am going by my obsurvasion of the previous formula. period seems to be the denominator of the reduced fraction of R/r
[17:34:12] <skunkworks> multiplied by 360 or 2pi
[17:35:35] <SWPadnos> I don't think thats right. there's an offset of 1
[17:36:00] <SWPadnos> you can prove this to yourself by taking a coin and moving it around the inner perimeter of something (like a coaster)
[17:37:01] <SWPadnos> if you hold the same point on the coin in contact with the coaster perimeter, then the coind will rotate -1 times (negative because it's the opposite direction of rotation compared to "geared" motion)
[17:38:34] <SWPadnos> that's why I mentioned at the beginning that it depends on whether you're calculating for the inner circle rotations, or forthe number of traversals around the larger perimeter
[17:51:01] <Jymmm> Jymmm is now known as Red70sShow
[17:51:01] <Red70sShow> Red70sShow is now known as Jymmm
[17:51:31] <bill2or3> Would this work well for a Y-axis (on a gantry)? http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=7596083961
[17:52:19] <SWPadnos> I think I've hit a "cleanup" problem in the run script
[17:53:18] <Jymmm> bill20r3: 1/2" unsupported rails might bow
[17:53:41] <SWPadnos> they're not unsupported, they're part of a T-beam
[17:53:53] <SWPadnos> that looks very nice
[17:54:03] <bill2or3> so they're just for hoizontal mounting.. not designed for lateral loads?
[17:54:17] <SWPadnos> note that there's no drive mechanism though
[17:54:35] <SWPadnos> that looks like it's meant for horizontal opreration, but I'm not sure
[17:54:37] <bill2or3> yeah, I've have to attach a nut
[17:54:50] <bill2or3> * bill2or3 wishes he knew wtf he was doing.
[17:55:08] <SWPadnos> it's best to figure that out before getting too far - trust me ;)
[17:55:47] <Jymmm> SWPadnos: They are supported? Oh never looked at the LARGE pic =)
[17:55:52] <SWPadnos> heh
[17:55:57] <bill2or3> I believe you.
[17:56:51] <SWPadnos> it does say "locking positioning block" - I'm not sure it's meant for lots of motion
[17:57:05] <SWPadnos> it does look well built though, so it should work fine
[17:57:49] <bill2or3> I'm sure using less-than-perfect commercially made rails will be the least of my problems.
[17:57:54] <SWPadnos> and there are two, so you could make a really big gantry with one of these on each side :)
[17:58:19] <SWPadnos> Thomson is one of the better manufacturers
[17:58:19] <bill2or3> 2 gantrys, sandwich the spindle between them
[17:58:33] <bill2or3> I got 2 thomson rails for the X axis, they seem pretty nice.
[17:58:50] <bill2or3> X is perpendicular to the gantry, right?
[17:58:54] <bill2or3> Y is on the gantry?
[17:59:04] <SWPadnos> it's up to you
[17:59:28] <bill2or3> is there a standard convention, for when I'm talking about it?
[17:59:33] <SWPadnos> the only thing you want to be sure of is that you end up with a right-handed coordinate system when you're done
[17:59:46] <SWPadnos> that can be done by reversing an axis or two in software
[17:59:55] <bill2or3> yeah.
[18:00:08] <SWPadnos> I think the convention is to have X be the long horizontal axis, and Y the shorter one
[18:00:14] <SWPadnos> but I'm not sure if that's just me
[18:00:21] <bill2or3> my power supply should be here today, then I'll pretty much have everything I need to start construction.
[18:00:45] <bill2or3> for the gantry I'm thinking 2" steel square stock, maybe filled with cement.
[18:00:50] <bill2or3> but that's not finalized.
[18:01:14] <SWPadnos> for the moving part?
[18:02:27] <bill2or3> for the support of the moving part.
[18:02:44] <SWPadnos> ok. I'd caution against putting a lot of concrete in anything that you want to move ;)
[18:02:53] <bill2or3> yeah, I hear that.
[18:11:17] <bill2or3> the base piece (1/4" steel plate) is allready really heavy.
[18:12:57] <SWPadnos> around 12 pounds per square foot, I imagine
[18:13:30] <bill2or3> it's 19" by 24"
[18:13:42] <bill2or3> I'll have to bolt some handles to it for moving.
[18:13:53] <SWPadnos> ok, then about 40 pounds or so
[18:14:05] <bill2or3> yeah.
[18:14:21] <bill2or3> * bill2or3 looks for t-slot plates.
[18:37:43] <Jymmm> bill20r3 to go in wood?
[18:38:06] <bill2or3> to use as the table for the mill I'm building.
[18:38:40] <Jymmm> ah. I know of some sluminum t channel
[18:39:18] <bill2or3> like that 8020 stuff?
[18:39:26] <Jymmm> http://www.nesales.com/tools/t-track.htm
[18:39:39] <Jymmm> http://www.mlcswoodworking.com/shopsite_sc/store/html/smarthtml/pages/ttrack.html
[18:39:48] <bill2or3> * bill2or3 looks
[18:39:52] <Jymmm> http://www.woodcraft.com/family.aspx?DeptID=2307&FamilyID=3782
[18:40:05] <Jymmm> http://donkihote.shop.com/op/~4'_T_Track_Kit-prod-5788114
[18:40:11] <bill2or3> thats kind of neat.
[18:40:52] <Jymmm> http://www.rockler.com/ecom7/product_details.cfm?offerings_id=5325
[18:41:21] <Jymmm> Yeah, that's why I have all those bookmarked.... cheap enough if you can get away in using them.
[18:42:42] <bill2or3> I may just use a steel plate with some holes, and nuts attached on the bottom
[18:42:52] <bill2or3> just enough for clamps.
[19:37:45] <SWPadnos> SWPadnos is now known as SWP_Away
[19:43:55] <Jymmm> bill20r3 or if get brave tapped =)
[20:54:27] <NickServ> This nickname is owned by someone else
[20:54:27] <NickServ> If this is your nickname, type /msg NickServ IDENTIFY <password>
[20:55:24] <lilo> [Global Notice] Hi all. We just experienced a routing outage on a main rotation server. We're moving it out of main rotation and substituting other resources. You'll see people pinging out and coming back. Apologies for the inconvenience.
[20:55:59] <lilo> [Global Notice] We'll provide further information on wallops ( /mode yournick +w ) and if needed another global notice later. Thanks.
[21:04:10] <lilo> [Server Notice] Hi all. The server you're on is the one that just experienced connectivity problems. If you're seeing this, you will see a CTCP PING from freenode-latency in a moment. Please bear with us, and if you need more information, you can turn on wallops ( /mode yournick +w ).... thanks for your patience, and thank you for using freenode!
[21:17:27] <roltek> alex are you in
[21:17:34] <alex_joni> yes roltek
[21:17:38] <alex_joni> just came in
[21:18:37] <roltek> did they release the emc2
[21:20:28] <alex_joni> not yet
[21:20:31] <alex_joni> still working on it
[21:20:32] <bill2or3> I just got my powersupply. for some reason I expected it to be bigger.
[21:20:42] <bill2or3> but it's just pc powersupply sized.
[21:20:42] <alex_joni> however, there are debs for emc2 now, so you can test too ;)
[21:20:58] <alex_joni> roltek: it should be at least comparable with emc11
[21:21:26] <roltek> i see some talk about edm machines
[21:22:17] <roltek> it seemed like focus was going away from finishing milling
[21:22:42] <alex_joni> roltek: not really.. that was mostly talks
[21:22:57] <alex_joni> however, cradek just rewrote the trajectory planner
[21:23:06] <alex_joni> and you agree that needs some serious testing
[21:23:30] <roltek> are the developers going to finish handwheel which is vary imortant
[21:24:02] <roltek> i think what was done on tp was very good
[21:24:53] <alex_joni> roltek: handwheel might not make it to 2.0.0
[21:25:01] <alex_joni> but eventually it will get done
[21:25:17] <alex_joni> not the handwheel by itself, but a more complex thing (a hardware UI)
[21:25:28] <roltek> don't they need it for the mazak retro
[21:25:37] <alex_joni> where you can have external hardware buttons & knobs & sliders which act just like a GUI
[21:25:55] <alex_joni> jmk did some handwheel on the mazak
[21:26:02] <alex_joni> with components that are already there
[21:26:14] <roltek> very important for hard wireed nobs
[21:26:14] <alex_joni> but I'm not sure how proper that is.. you'd have to ask him
[21:27:04] <bill2or3> I have what is probablly a stupid question.
[21:27:40] <bill2or3> this powersupply has terminals for "L" and "N" (and ground) which I assume is Live and Neutral. how to I tell which is which from an AC wall socket?
[21:28:53] <roltek> thank you alex
[21:29:39] <cradek> bill2or3: http://www.google.com/search?q=US+power+outlet+live+neutral
[21:30:09] <cradek> then click the first hit
[21:30:13] <bill2or3> you google better than I. thanks.
[21:30:38] <cradek> welcome
[21:31:51] <bill2or3> "The hot and neutral wires are interchangeable as far as the equipment is concerned."
[21:32:07] <cradek> The black (hot ) wire goes to the brass or copper screw which is connected to the right (smaller) slot The white (neutral) wire goes to the silver or chrome screw which is connected to the left (larger) slot. The bare wire(ground) goes to the green screw for the separate ground path.
[21:32:22] <alex_joni> hi chris
[21:32:25] <cradek> (from under the picture of the US outlet)
[21:32:26] <cradek> alex_joni: hi
[21:32:57] <cradek> bill2or3: not sure why your power supply would make a distinction
[21:32:59] <alex_joni> what's up?
[21:33:13] <cradek> not much
[21:33:31] <cradek> tired of working on the bugs in task (*not* tp)
[21:34:02] <bill2or3> cradek, my first thought was it shouldn't matter, but lots and lots of 2-prong plugs are polarized, so that makes me wonder.
[21:34:03] <cradek> I guess combined linear/rotary axis moves aren't right
[21:34:32] <cradek> bill2or3: yeah, probably depends on the power supply design...
[21:34:46] <cradek> alex_joni: I'm sorry to hear about upt.ro
[21:35:01] <bill2or3> yeah.
[21:36:31] <alex_joni> cradek: me too
[21:36:37] <alex_joni> hope they sort it out pretty soon
[21:37:04] <cradek> I'm sure they will
[21:39:53] <alex_joni> yeah, that's for sure, the question is how fast
[21:52:03] <jepler> cradek: I remember you mentioning that the "Open" dialog did not show up localized. Apparently tcl only uses LANG even when LANGUAGE is set, so on ubuntu you have to invoke "LANG=de LANGUAGE=de scripts/emc2 ..." not just "LANGUAGE=de ..."
[21:53:03] <cradek> argh
[21:53:57] <alex_joni> jepler: how about setting LANG based on LANGUAGE?
[21:54:01] <alex_joni> or the other way around?
[21:54:07] <cradek> sometimes I hate programmers. there are two variables because ...?
[21:54:08] <alex_joni> inside the runscript I mean
[21:54:16] <jepler> alex_joni: I suspect that if you log in with a language set in ubuntu, both variables *are* set
[21:54:28] <jepler> alex_joni: but for someone who wants to test in a different language just to see if it works, it's tricky
[21:54:34] <cradek> jepler: I'll try
[21:55:19] <jepler> I disagree that the runscript should do anything
[21:57:25] <jepler> apparently use of $LANGUAGE is a GNU gettext extension
[21:57:41] <jepler> I have NFC why
[21:59:06] <cradek> jepler: it does work right, I must have tested with only one or the other
[22:00:00] <cradek> huh, I get Affnen on the titlebar and �ffnen on the button - I wonder which is right
[22:00:03] <jepler> can you verify that ubuntu sets them both if you log into X with some particular language selected?
[22:00:13] <alex_joni> jepler: I think it's a bit harder than that
[22:00:26] <alex_joni> from googling around I see that $LANGUAGE can hold more than one
[22:00:32] <alex_joni> the first one beeing the one active
[22:00:33] <cradek> it sets LANG LANGUAGE and GDM_LANG
[22:00:41] <jepler> cradek: Tk still doesn't have the ability to display non-ASCII in titlebars.
[22:00:42] <alex_joni> e.g. LANGUAGE="cs_CZ:cs:en_GB:en"
[22:01:00] <cradek> jepler: oh ok
[22:01:11] <jepler> cradek: on X11 systems at any rate
[22:01:18] <jepler> cradek: it's one of the things that makes me die inside
[22:01:23] <alex_joni> The "LANGUAGE" environment variable is used to set a
[22:01:23] <alex_joni> prioritised list of languages, so GNU Gettext doesn't have
[22:01:23] <alex_joni> to fall directly back to the POSIX locale, if there are
[22:01:23] <alex_joni> translations available in a (for the user) more appropriate
[22:01:25] <alex_joni> language.
[22:01:49] <alex_joni> -> that makes some sense
[22:01:58] <cradek> I can sure see why you would want a list
[22:02:00] <jepler> alex_joni: yes, it does. Where did you find that documentation?
[22:02:12] <jepler> alex_joni: It's not in 'info gettext' on ubuntu, which was where I was looking.
[22:02:16] <cradek> good thing ubuntu does all that properly for us already
[22:02:57] <jepler> it looks like Python's gettext implementation would split LC_ALL, LC_MESSAGES and LANG at colons too
[22:03:01] <jepler> I wonder if that's an extension
[22:03:03] <alex_joni> "
[22:03:03] <alex_joni> This is the current behavior. Encoding is taken from LANG, program
[22:03:03] <alex_joni> interface speaks in whatever language is set in LANGUAGE (if not set,
[22:03:03] <alex_joni> fallback to LC_ALL, LC_MESSAGES, LANG), so you just have to take care
[22:03:03] <alex_joni> of setting the "broadest possible encoding" in your LANG variable (or
[22:03:05] <alex_joni> LC_* for that matter), which seems to be UTF-8 these days."
[22:03:19] <alex_joni> jepler: http://lists.debian.org/debian-i18n/2005/03/msg00059.html
[22:03:48] <jepler> alex_joni: I wish important things like this got into documentation, instead of languishing in mailing list archives.
[22:04:31] <cradek> *cough cough*RTAI*cough*
[22:04:51] <jepler> no kidding
[22:05:17] <alex_joni> * alex_joni passed cradek some cough siroup
[22:05:31] <alex_joni> what's wrong about RTAI documentation? ROFL
[22:06:04] <alex_joni> jepler: It is documented in libc info pages.
[22:06:14] <alex_joni> no idea what it's doing there..
[22:09:28] <alex_joni> * alex_joni wonders what would happen if all what we discuss here would make it into documentation
[22:09:49] <cradek> we'd have documentation with curse words
[22:10:40] <cradek> but seriously, you'd get honest documentation about what works and what doesn't, and how and why
[22:10:42] <jepler> pifticle
[22:11:24] <cradek> I suppose the biggest problem is the documentation not keeping up
[22:11:27] <alex_joni> jepler: is that a word?
[22:11:52] <jepler> alex_joni: not usually
[22:12:04] <alex_joni> cradek: I'm afraid I'm just not fluent with the documentation implementation
[22:12:26] <alex_joni> jepler: ok ;) thought I missed that one untill now
[22:12:54] <alex_joni> cradek: although that probably shouldn't stop me from writing it in something else..
[22:13:17] <cradek> alex_joni: like html? wiki?
[22:13:28] <alex_joni> pdf?
[22:13:29] <alex_joni> :D
[22:13:36] <cradek> alex_joni: having it in pdf or lyx or whatever contributes to the problem.
[22:13:52] <alex_joni> well, I can give it in .doc, but you'll barf at me ;)
[22:14:32] <alex_joni> I guess nowadays openoffice works just as good
[22:14:43] <cradek> wiki sucks but it sure is easiest to keep up to date
[22:15:07] <alex_joni> yeah, but it's not proper for documenting code (internals)
[22:15:15] <alex_joni> it's ok for documenting how it works
[22:15:25] <alex_joni> or what the user wants to read
[22:26:21] <skunkworks> How do you kill emc2 when it is loading a file that is in a loop?
[22:26:34] <cradek> exit the gui
[22:26:35] <skunkworks> Don't ask
[22:26:49] <skunkworks> I click on the x and nothing.
[22:26:52] <cradek> exit/kill the gui
[22:27:21] <skunkworks> Ok how do I do that?
[22:27:51] <cradek> in a shell, type "killall axis"
[22:28:50] <jepler> skunkworks: in the future I suggest you refrain from writing infinite loops
[22:31:01] <skunkworks> Thanks cradek -- It is not my fault I swear - I think I was pushing the owords to the limit.
[22:31:41] <jepler> I was just thinking the other day it would freeze axis if an O-word program had an infinite loop
[22:31:48] <jepler> I'm not sure what to do about this
[22:31:55] <skunkworks> It does - I have done it more than once ;)
[22:34:04] <alex_joni> skunkworks: when will you realize you can stop?
[22:34:49] <skunkworks> stop?
[22:34:59] <alex_joni> skunkworks: doing it more than once ;)
[22:35:07] <mike> hi, anyone experience undefined symbol: _Z31GET_EXTERNAL_SELECTED_TOOL_SLOTv with Axis 1.2rc1?
[22:35:24] <alex_joni> * alex_joni hides again
[22:35:37] <skunkworks> http://www.electronicsam.com/images/KandT/spiro.ngc
[22:36:09] <skunkworks> works "ok" but part of it doesn't work ok with decemals for r and R
[22:36:13] <alex_joni> mike: during running it? or at compile time?
[22:36:20] <mike> running
[22:36:22] <alex_joni> what emc2 version are you running?
[22:36:29] <mike> emc2-testing
[22:36:34] <skunkworks> o150 while [[fix[#6] NE #6] or [fix[#7] NE #7]]
[22:36:34] <skunkworks> #6=[#9*#11]
[22:36:34] <skunkworks> #7=[#10*#11]
[22:36:34] <skunkworks> o150 endwhile
[22:36:42] <alex_joni> mike: getting it every time?
[22:36:46] <mike> yup
[22:36:48] <skunkworks> this part doesn't work all the time
[22:36:57] <alex_joni> without touching M6 Txx ?
[22:37:04] <alex_joni> or only when you get to that part?
[22:37:50] <alex_joni> mike: I mean, does the error show up when you start AXIS, befor you do anything?
[22:38:36] <mike> i put axis in the DISPLAY variable in sim.ini and run scripts/emc
[22:39:02] <alex_joni> mike: would it be too much if I ask you to get and try another AXIS ?
[22:39:23] <alex_joni> mike: http://axis.unpy.net/files/downloads/nightly/axis-latest.tar.bz2
[22:39:26] <mike> i also tried 1.1.1 but it wouldnt make cleanly
[22:39:37] <mike> i'll try that, thx
[22:40:02] <alex_joni> mike: np
[22:41:12] <mike> now i see 1.2rc3 also
[22:42:22] <skunkworks> if I have say 10 for 6 and .2 for 7 it should end with 30 and 1 respectively. but it gets into an infanant loop - maybe a rounding error - going to have to put in some stops so I can step though
[22:42:45] <alex_joni> "A change in the interface to the emc2 rs274ngc interpreter" <- that's what you were seeing
[22:42:54] <alex_joni> and I'm responsible for that ;)
[22:44:25] <jepler> mike: the newest 1.1 and 1.2 rc (release candidates) should both work on the newest emc2
[22:44:54] <alex_joni> jepler: it's not quite the newest, it's TESTING.. but new enough I guess
[22:46:50] <jepler> skunkworks: "algerithum"?
[22:47:04] <jepler> skunkworks: I think you mean "algorithm".
[22:47:51] <mike> alex_joni:, jepler: axis-latest works, thanks.
[22:48:56] <alex_joni> mike: yay
[22:48:57] <jepler> mike: glad to hear it. axis-latest does have a few experimental features, so if you run into trouble I suggest you try axis 1.2rc3 or 1.1.3rc1, which are from the "stable" branches of AXIS.
[22:51:04] <alex_joni> mike: or save yourself the hassle and use emc2-axis.deb and emc2.deb
[22:52:11] <skunkworks> jepler: yes :)
[22:54:37] <skunkworks> I tried round and fix
[22:54:53] <skunkworks> .5 works but .2 doesn't - going to have to play some more
[22:54:58] <alex_joni> dmessier: bon soir
[22:55:12] <skunkworks> Just playing around - it has no real purpose
[22:56:08] <dmessier> ca va??
[22:56:32] <skunkworks> bbl
[22:56:50] <alex_joni> dmessier: je suis tres fatigu�e
[22:57:09] <alex_joni> c'etait une journee infernale
[22:57:32] <dmessier> pour quoi??
[22:57:52] <alex_joni> travaille ;)
[22:58:02] <dmessier> j'ai u elle hier
[22:58:11] <alex_joni> elle?
[22:58:26] <dmessier> ta jounee
[22:58:44] <alex_joni> ah..
[22:58:46] <dmessier> journee
[22:58:55] <alex_joni> c'est pas bon :/
[22:59:37] <dmessier> comme c'est la ja l'esspoir de une bonne idea
[22:59:58] <alex_joni> quelle idea?
[23:00:14] <dmessier> c'est un secret...
[23:00:19] <jepler> alex_joni: dmessier: looks like one of you is about to offer to contribute a French translation of AXIS.
[23:00:23] <alex_joni> dmessier: :(
[23:00:37] <alex_joni> jepler: I'm just fooling around.. my french sux ;)
[23:00:56] <jepler> better than mine
[23:01:34] <alex_joni> it's been too long since I took french in school ;)
[23:01:42] <alex_joni> dmessier can confirm ;)
[23:01:59] <dmessier> si j'echape un emae... dans un tube de fille en copre.. j'ai du current
[23:02:15] <alex_joni> dmessier: ok, et ?
[23:02:45] <dmessier> se current peux charger une pile
[23:02:57] <alex_joni> naturalement
[23:03:17] <alex_joni> jepler: what kinds of temperature do you think were achieved on earth?
[23:03:48] <alex_joni> jepler: http://www.livescience.com/technology/060308_sandia_z.html
[23:03:59] <dmessier> si sa tombe ou sa mont ne fait pas de diferance... tand dis que sa bouge...
[23:04:32] <jepler> alex_joni: bah. science. what use is it?
[23:04:47] <dmessier> j'ai un mechanism qui peux accomplier sa
[23:05:37] <alex_joni> dmessier: je pense que ce francais et un peux trop compliquee pour mois ;)
[23:05:58] <dmessier> 1 charge d'eau est du current pour des ans
[23:06:29] <dmessier> english then... ; ) but no secrets... ; )
[23:08:11] <alex_joni> dmessier: Je vais me coucher maintenant...
[23:08:13] <dmessier> i could always speak french BETTER than my teachers....native spoken.. but i cant write it for beans.. ; (
[23:08:32] <alex_joni> dmessier: I cant do either properly
[23:08:47] <alex_joni> I would probably starve to death in france :D
[23:09:03] <alex_joni> well, maybe they know some german
[23:09:03] <dmessier> you do a VERY good impression then.. that'll get ya babes... ; )
[23:09:16] <alex_joni> lol
[23:09:26] <alex_joni> ok, I'm off to bed
[23:09:32] <alex_joni> need to wake up in about 6 hours
[23:09:40] <alex_joni> night all
[23:09:51] <dmessier> square headed girlfriends dont go the distance
[23:10:16] <alex_joni> yeah, but square headed is very practical for a beer mug :D
[23:10:20] <alex_joni> to rest on
[23:11:25] <alex_joni> except if you meant 'puters
[23:11:45] <dmessier> fold back teeth should be involved in that dream to.. dude..
[23:12:16] <dmessier> oh shit handles instead of ears
[23:12:35] <dmessier> opps did i say that out loud
[23:12:43] <alex_joni> dmessier: nope ;)
[23:13:03] <alex_joni> and 0.8-1.2m high
[23:13:38] <alex_joni> ok, I'll leave on that funny note..
[23:13:50] <alex_joni> but this is nice: http://livesciencestore.com/56720.html
[23:15:16] <dmessier> bonne nuit mon frere... ; )
[23:15:22] <alex_joni> bonne nuit
[23:15:58] <dmessier> right idea...
[23:31:46] <jepler> cradek: should not generate arcs with rotational axis motion: http://emergent.unpy.net/index.cgi-files/sandbox/torture-xyza.py

#emc | Logs for 2006-03-09