Back
[00:04:06] <cradek> MichelG: I'd happily review your probing patch
[00:04:57] <cradek> MichelG: there was lots of talk about probing a while back but I don't think anyone involved was actually using it.
[00:05:58] <MichelG> cradek: ok, I will make it available next tuesday.
[00:07:39] <cradek> MichelG: was it a recent or old emc2 that you patched?
[00:14:43] <MichelG> cradek: everything was still there, except connecting a hal pin in the parport.hal and adding 10 lines to manage the trip of the probe
[00:15:47] <MichelG> cradek: as my hard drive broke, I have to redo it again. I can take either emc 2.03 or the CVS as you like.
[00:18:02] <MichelG> I have a TP-100 probe on my sherline mill and I have many uses for it.
[00:18:10] <cradek> ok, let's patch cvs head first, and then afterward decide whether it can go in 2.0 branch.
[00:19:00] <MichelG> cradek: OK; I'll do that on Monday.
[00:19:16] <cradek> thanks
[00:37:19] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/image-to-gcode.py:
[00:37:19] <CIA-8> support choice of direction (positive, negative, or alternating)
[00:37:19] <CIA-8> support milling in rows, columns, or both
[00:49:04] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/image-to-gcode.py: combobox looks better than optionmenu
[01:43:58] <LawrenceG> anyone around this evening?
[01:45:25] <LawrenceG> is dsplabs.cs.upt.ro down?... I am trying to set up a new box and that ip isnt resolving anymore
[01:49:17] <jepler> LawrenceG: a DNS server is down and apparently won't be fixed this weekend. There's an alternate URL you can use and I'm looking for it in my scrollback.
[01:50:20] <jepler> LawrenceG: the alternate location is
http://dsplabs.utt.ro/emc2/
[01:54:27] <LawrenceG> thankyou... I will give that a try
[01:56:14] <LawrenceG> do you know waht debs are needed for the latest install.... I have bwidget, emc2-axis and and emc2 debs in cache from an older install
[01:56:29] <LawrenceG> they are version 2.0.3
[01:56:51] <LawrenceG> and axis 1.4a0-0
[01:56:55] <SWPadnos> all the requirements should be pulled in automatically when you install emc2 and emc2-axis
[01:57:05] <SWPadnos> or was that not the question?
[01:58:13] <LawrenceG> will try the apt install first with the backup repository.... was looking to see if I had all the needed debs on another box as an alternate way to get things installed
[01:58:37] <SWPadnos> ah. ok. if you look in Synaptic, you should be able to see the list of dependencies
[01:58:44] <SWPadnos> I'm not sure what they are now
[01:59:36] <LawrenceG> I reformatted an old bdi 4.2 install and updating to ubuntu and emc2
[01:59:49] <SWPadnos> cool
[02:00:00] <SWPadnos> oooh - gotta run - fireworks are starting :)
[02:00:20] <LawrenceG> have fun... cheers
[02:02:46] <SWPadnos> hmm - hard to see them through the trees
[02:04:24] <LawrenceG> jepler: backup repository working like a charm... nice fast downloads as well about 300K/sec
[02:04:41] <SWPadnos> it's the same server, just a different DNS path
[02:20:27] <jepler> LawrenceG: glad you were able to get going
[06:35:42] <zbyte_> hello, just a minor question
[06:36:10] <zbyte_> theoretically could i just use the rtai modules to develop a rt app other then emc2?
[06:36:21] <zbyte_> probably a stupid question....
[06:36:30] <A-L-P-H-A> zbyte_, you can. no one is stopping you.
[06:36:40] <zbyte_> cool :), thx
[06:36:41] <A-L-P-H-A> rtai is not made by emc.
[06:37:00] <A-L-P-H-A> its' GNU... you can do what you want... as long as it's within the liscense of the GNU.
[06:37:01] <zbyte_> k
[06:37:26] <A-L-P-H-A> time to sleep
[06:37:28] <A-L-P-H-A> ciao
[07:05:37] <Lerneaen_Hydra> 'lo
[08:18:32] <alex_joni> morning all
[08:25:56] <Lerneaen_Hydra> hi alex
[08:55:26] <alex_joni> does anyone know of data recovery methods for EXT3 or EXT2?
[08:55:32] <alex_joni> especially deleted files..
[09:41:41] <jtr> alex_joni: No firsthand experience, but a google on ext2 deleted file recovery
[09:42:45] <jtr> alex_joni:gave a promising hit on using midnight commander - third from the bottom on the first page.
[09:46:32] <alex_joni> jtr: thanks, looking
[09:49:16] <alex_joni> jtr:
http://www.ists.dartmouth.edu/classroom/file-recovery.v0.81.php sounds promising
[10:35:11] <robin_sz> meep?
[10:47:29] <CIA-8> 03alex_joni 07HEAD * 10emc2/configs/stepper/stepper_mm.ini: typo
[11:06:07] <robin_sz> I forget .. what #<number> ranges are available to users in emc for random variables within programmes?
[11:15:24] <alex_joni> check the manual? I have no clue :D
[11:28:23] <robin_sz> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TubeCutter
[11:28:26] <robin_sz> random thoughts
[11:33:33] <robin_sz> sigh ... not where I thought it would be .. on the gcode page.
[11:39:34] <robin_sz> so, explain this to me .. in the manual in "gcode best practice" it says:
[11:39:34] <robin_sz> 18.6 DONT USE LINE NUMBERS
[11:39:37] <robin_sz> and then every example in the book has 'N' words for line numbers ...
[11:41:26] <alex_joni> lol
[11:41:33] <alex_joni> no idea why it says that
[11:42:32] <robin_sz> mainly it syas that because EMC reports errors by line number
[11:42:40] <robin_sz> but not the line number set inthe N word
[11:42:53] <robin_sz> the line number in the file
[11:43:39] <robin_sz> fixing emc to report the N word (if one is set for the line) might solve that
[11:48:21] <robin_sz> bah, can't seem to find it inthe manual ... I'll assume the ones from #5000 on are system related, and the rest are free for me to use.
[11:49:25] <robin_sz> I'll probably end up hi-jacking G54,55,56,57 that are used for workspace selection for face selection
[11:49:46] <robin_sz> seems the most logical choice
[13:13:19] <jepler> robin_sz: also, the phrase "n-word" is offensive
[13:14:28] <jepler> seriously, I wrote that part of the manual and it's probably up for debate. However, I see no benefit to N-numbers but they can be the cause of confusion for the reason you mentioned.
[13:19:31] <Lerneaen_Hydra> jepler: how is n-word offensive O.o
[13:19:31] <alex_joni> it's like the F-word :D
[13:19:31] <Lerneaen_Hydra> huh?
[13:19:31] <Lerneaen_Hydra> oh!
[13:19:31] <alex_joni> but for coloured people :D
[13:19:31] <Lerneaen_Hydra> like that
[13:19:31] <Lerneaen_Hydra> right
[13:19:41] <Lerneaen_Hydra> in borkland you don't tend to censor swear words nearly as much
[13:19:49] <Lerneaen_Hydra> not even in the news IIRC
[13:20:38] <Lerneaen_Hydra> there's even a baked candy-esque good called n-word ball
[13:21:03] <Lerneaen_Hydra> http://en.wikipedia.org/wiki/Chokladboll
[13:21:28] <Lerneaen_Hydra> though the politically correct term is chocolate ball nowadays
[14:42:46] <Lerneaen_Hydra2> 'lo
[14:43:12] <Lerneaen_Hydra2> sanity check, TTL output is 0.35V low, 2.0V high?
[14:43:19] <alex_joni> something like that
[14:43:28] <Lerneaen_Hydra2> any idea of minimum assertion time?
[14:43:34] <Lerneaen_Hydra2> 1µs?
[14:43:46] <Lerneaen_Hydra2> 100µs?
[14:43:53] <Lerneaen_Hydra2> 10µs?
[14:43:58] <alex_joni> 10µs?
[14:44:02] <Lerneaen_Hydra2> ok
[14:44:04] <alex_joni> what's that?
[14:44:11] <alex_joni> I see some funny letters :D
[14:44:13] <jepler> microsecond
[14:44:16] <Lerneaen_Hydra2> oh
[14:44:17] <Lerneaen_Hydra2> yeah
[14:44:31] <alex_joni> * alex_joni curses UTF for beeing so late
[14:44:42] <Lerneaen_Hydra2> that would be parport specific
[14:44:45] <Lerneaen_Hydra2> i assume
[14:45:02] <alex_joni> Lerneaen_Hydra2: a definate answer is in the datasheet
[14:45:14] <Lerneaen_Hydra2> which datasheet?
[14:45:17] <alex_joni> depends on the family you're using (L, LS, HC, HCT)
[14:45:25] <alex_joni> oh, you mean on the parport?
[14:45:32] <Lerneaen_Hydra2> yeah
[14:45:35] <alex_joni> thought you want to place another TTL chip there
[14:45:50] <alex_joni> 10usec sounds slow then
[14:46:41] <Lerneaen_Hydra2> nonio, this is just what the parport needs for input
[14:46:59] <Lerneaen_Hydra2> it's for my encoder, so I get the needed voltage & timing window
[14:48:16] <jepler> Lerneaen_Hydra: if you're reading the quadrature signal with hal_parport, then there can't be more than one transition per BASE_PERIOD
[14:48:22] <jepler> nothing to do with the inherent speed of TTL
[14:49:53] <Lerneaen_Hydra2> the encoder doesn't output perfect square wave at my max spindle speed, it's a form of sawtooth form
[14:49:53] <jepler> this page gives TTL voltages, though I don't know if it's correct:
http://www.allaboutcircuits.com/vol_4/chpt_3/11.html
[14:50:08] <Lerneaen_Hydra2> so I wanted to know the minimum voltage and time for a high to be registered
[14:51:05] <Lerneaen_Hydra2> as it is now the top of the sawtooth reaches 3V
[14:51:13] <SWPadnos> if you're not getting a square-ish wave, you probably have a grounding problem
[14:51:19] <Lerneaen_Hydra2> but the time that is asserts fully 2.7V is less
[14:51:27] <Lerneaen_Hydra2> SWPadnos: I've got optocouplers :/
[14:51:31] <SWPadnos> a sawtooth sounds like capacitive decay
[14:51:58] <Lerneaen_Hydra2> the optocouplers have that behavior
[14:52:12] <SWPadnos> maybe they need a pull-up
[14:52:17] <Lerneaen_Hydra2> it's just more prominent when running at high speed
[14:53:08] <jepler> so it's about the Tr and Tf of the optocoupler?
[14:53:08] <Lerneaen_Hydra2> yeah they do, but the pullup current is limited becuase I'm using a parport output as power for the pullup
[14:53:11] <Lerneaen_Hydra2> by changing the pullup current I can get either better voltage or faster times
[14:53:28] <Lerneaen_Hydra2> I have a 220µF cap to smooth it out too
[14:53:34] <SWPadnos> heh - well, I shouldn't be talking like I know anything - I haven't gotten my parallel port to work at all :)
[14:53:56] <SWPadnos> 220 uF - that sounds huge for smoothing
[14:54:05] <Lerneaen_Hydra2> I had it lying around in a box ;)
[14:54:10] <Lerneaen_Hydra2> so I think, why not
[14:54:18] <SWPadnos> maybe you should put it back in the box :)
[14:54:27] <Lerneaen_Hydra2> there's plenty left
[14:54:35] <SWPadnos> what value pull-up resistor do you have?
[14:54:40] <Lerneaen_Hydra2> it's not like they're expensive or anything
[14:54:48] <jepler> $ units "220 micro F * 1 kilo ohm"
[14:54:48] <jepler> Definition: 0.22 s
[14:54:51] <Lerneaen_Hydra2> currently around 16kohm
[14:55:17] <Lerneaen_Hydra2> 5kohm was too little, so the voltage started sagging
[14:55:21] <SWPadnos> gah - that's a 3 second time constant
[14:55:44] <Lerneaen_Hydra2> 22kohm was too much, so it wouldn't reach vmax (the slope was too blunt)
[14:55:54] <Lerneaen_Hydra2> 16kohm seems to be right, assuming that the time is enough
[14:56:09] <SWPadnos> get rid of the cap, or put another 10 in parallel with it :)
[14:56:14] <SWPadnos> err - series
[14:56:42] <Lerneaen_Hydra2> currently I've got 25-30µs at >2.7V
[14:56:52] <Lerneaen_Hydra2> it tops at 3.2V
[14:57:42] <jepler> better to get a real +5V on the computer side of the optos (maybe steal it from a USB port?) and put some schmitt-trigger buffers and appropriate pull-ups
[14:58:06] <alex_joni> yeah, USB port works great
[14:58:06] <Lerneaen_Hydra2> jepler: yeah, I know, but then I have to pull *more* cables (eugh) and it leaves for more stuff to do
[14:58:30] <SWPadnos> at least it'll work
[14:58:51] <Lerneaen_Hydra2> anyway, when I run at sane threading speeds (around 100-500rpm) the asserted time is far greater
[14:59:14] <Lerneaen_Hydra2> 25-30µs is what I get at 3200rpm, which is lathe max
[14:59:41] <jepler> Lerneaen_Hydra2: if the time at >2.7V is longer than BASE_PERIOD then it ought to work.
[15:00:24] <jepler> have you halscoped it?
[15:00:24] <Lerneaen_Hydra2> nope, not yet
[15:00:30] <Lerneaen_Hydra2> when running at 600rpm I get times of >400µs, which is far more than enough
[15:00:42] <jepler> while it's no sure test, you'll have some level of confidence if you get a nice square wave with no visible glitches in halscope
[15:00:42] <Lerneaen_Hydra2> as my base period is 25µs
[15:00:48] <Lerneaen_Hydra2> yeah
[15:01:38] <jepler> Lerneaen_Hydra2: did you see that I added 90 degree lace to image-to-gcode?
[15:02:23] <Lerneaen_Hydra2> ooh
[15:02:30] <Lerneaen_Hydra2> I haven't done an update yet
[15:02:39] <Lerneaen_Hydra2> I'll do that in just a moment
[15:02:46] <Lerneaen_Hydra2> sounds nice :D
[15:03:06] <jepler> you may have to remove ~/.image2gcoderc if it seems confused -- I changed the way the options are saved
[15:04:22] <Lerneaen_Hydra2> the main other thing that may be worth looking into would be the "derivative of the image" thing, but that would be mainly if there happened to be a lib that does that already
[15:04:22] <Lerneaen_Hydra2> ok
[15:08:53] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/lace.png
[15:13:34] <alex_joni> whoa.. nice :)
[15:16:13] <Lerneaen_Hydra2> whoop
[15:16:13] <Lerneaen_Hydra2> whoops
[15:16:13] <Lerneaen_Hydra2> logger_aj: bookmark
[15:16:13] <Lerneaen_Hydra2> See
http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-08-27#T15-16-13-2
[15:16:13] <Lerneaen_Hydra2> he's slow today too :(
[15:17:07] <jepler> 10:11:09 <jepler>
http://emergent.unpy.net/index.cgi-files/sandbox/lace.png
[15:17:25] <jepler> * jepler discovers that row-milling is broken when the image is not square
[15:17:26] <jepler> oops!
[15:18:40] <Lerneaen_Hydra2> I'm glad I didn't update yet ;)
[15:20:22] <Lerneaen_Hydra2> you can see why it's good to have a 90degree rotate, right?
[15:20:37] <Lerneaen_Hydra2> can you config the number and angle of rotation?
[15:20:42] <Lerneaen_Hydra2> and the angle of the lace?
[15:21:04] <jepler> no
[15:21:42] <jepler> you mean, someone might want to mill at 30 and 120 degrees, for instance? or in multiples of 60 degrees?
[15:21:46] <Lerneaen_Hydra2> that may be good, if the part has a certain disposition, though it's not very important
[15:21:51] <Lerneaen_Hydra2> yeah
[15:21:56] <jepler> ugh
[15:21:57] <Lerneaen_Hydra2> maybe the part is hexagonal
[15:22:03] <Lerneaen_Hydra2> or heptagonal
[15:22:07] <Lerneaen_Hydra2> or whatever
[15:22:13] <Lerneaen_Hydra2> still, it's a rare case
[15:22:18] <Lerneaen_Hydra2> so not very important IMO
[15:22:32] <Lerneaen_Hydra2> most of the time a 90 degree rotate is perfect
[15:23:10] <Lerneaen_Hydra2> and if you want to do stuff that nitty-gritty then you'll probably need real CAM for some other reason
[15:24:02] <alex_joni> jepler: if you're coding after Lerneaen_Hydra2's suggestions, you'll never finish
[15:25:07] <Lerneaen_Hydra2> exactly ;)
[15:25:50] <jepler> hm, and here's another bug:
http://emergent.unpy.net/index.cgi-files/sandbox/wronglace.png
[15:26:10] <alex_joni> heh..
[15:26:27] <alex_joni> someone moved the workpiece ;)
[15:26:27] <Lerneaen_Hydra2> haha, nice
[15:26:34] <Lerneaen_Hydra2> what are you using to make the images?
[15:26:55] <jepler> a raytracer
[15:27:01] <Lerneaen_Hydra2> oh, ok
[15:27:04] <alex_joni> poor ray
[15:27:05] <alex_joni> :D
[15:27:06] <Lerneaen_Hydra2> so a 3d model to begin with?
[15:27:10] <Lerneaen_Hydra2> argh
[15:27:51] <jepler> http://runevision.com/graphics/stereo/depthmap/
[15:28:17] <alex_joni> oooh.. stereograms
[15:28:43] <alex_joni> hmm.. axis should load those.. kinda like a stereogram cheat prog
[15:28:49] <Lerneaen_Hydra2> yet another thing to add to "LH's list of features that never stops growing", differing feed between X/Y travel and Z plunge
[15:28:51] <alex_joni> for people who can't see them ... ROFL
[15:30:12] <jepler> you haven't asked for waterlining yet either
[15:30:55] <jepler> get to work on those feature requests!
[15:30:55] <SWPadnos> how about waterlining? ;)
[15:30:55] <Lerneaen_Hydra2> waterlining?
[15:30:55] <Lerneaen_Hydra2> ooh ooh, a roughing sequence ;)
[15:30:55] <SWPadnos> milling around X+Y, at various Z levels
[15:31:14] <SWPadnos> yeah - roughing is actually important, depending on the depth of cut
[15:31:14] <Lerneaen_Hydra2> so first remove first N*X mm of depth, then 2N*X mm depth
[15:31:14] <Lerneaen_Hydra2> etc etc
[15:31:18] <alex_joni> are 3D goggles supported under linux?
[15:31:23] <Lerneaen_Hydra2> and an offset
[15:31:24] <SWPadnos> I think so
[15:31:29] <Lerneaen_Hydra2> which type?
[15:31:39] <SWPadnos> in the NVidia drivers at least (I think)
[15:31:40] <Lerneaen_Hydra2> red/green or the LCD shutter?
[15:31:42] <alex_joni> stereo 3D
[15:31:53] <alex_joni> LCD shutter type
[15:31:58] <Lerneaen_Hydra2> ok
[15:32:01] <Lerneaen_Hydra2> do you have those?
[15:32:14] <alex_joni> I just remembered I have a pair in a bottom drawer
[15:32:34] <SWPadnos> heh
[15:32:37] <Lerneaen_Hydra2> I've always wanted to test them, though I've heard they give headaches becuase of the short focal distance and illusion of distance far away
[15:32:38] <alex_joni> the ones you connect on the VGA out, and uses sync to switch alternatively on/off
[15:32:44] <Lerneaen_Hydra2> oh, nice
[15:32:47] <alex_joni> Lerneaen_Hydra2: not that I noticed
[15:32:58] <Lerneaen_Hydra2> nice!
[15:33:24] <SWPadnos> and with an LCD monitor, the image goes away if you titl your head
[15:33:29] <SWPadnos> tilt
[15:33:40] <alex_joni> yeah
[15:33:47] <Lerneaen_Hydra2> they won't work with LCD at all though, will they?
[15:33:51] <SWPadnos> same with polarized sunglasses
[15:33:59] <SWPadnos> if the orientation is right, they will
[15:34:04] <Lerneaen_Hydra2> don't LCD have far too much latency?
[15:34:11] <SWPadnos> though you may get a negative color image in the wrong orientation
[15:34:41] <SWPadnos> most modern LCDs can do ~80 FPS updates (more, if you listen to the claims of the manufacturers)
[15:35:27] <alex_joni> Lerneaen_Hydra2: not at 3-4msec
[15:35:27] <Lerneaen_Hydra2> hmm, how accurate are those numbers, IIRC it was 3-4ms for a certain grey to a certain white
[15:35:51] <SWPadnos> ok - it looks like I was wrong about that. people think that there are no drivers for stereo glasses for Linux
[15:36:01] <Lerneaen_Hydra2> :(
[15:36:44] <SWPadnos> full-scale changes are maybe 8-10 ms for most medium to high quality LCDs these days. It takes a bit longer to do lesser changes (from 30% to 60% off, for instance)
[15:36:59] <SWPadnos> 8-10 ms is the maximum - most are lower
[15:39:23] <alex_joni> you mena higher?
[15:39:31] <alex_joni> mean
[15:41:02] <SWPadnos> no - most medium-high quality panels tout lower transition times. 16 ms is the highest I've seen lately, but I wouldn't call it a quality panel ;)
[15:42:44] <alex_joni> oh.. right
[15:43:13] <Lerneaen_Hydra2> so how long does a change take in the worst case scenario?
[15:43:20] <Lerneaen_Hydra2> say it's a 8-10ms screen
[15:44:39] <alex_joni> SWPadnos: there might be this:
http://futurelab.aec.at/vrizer/
[15:45:08] <SWPadnos> well, if you can afford a CAVE, I'm sure you can get stereo glasses working ;)
[15:48:13] <alex_joni> http://www.stereo3d.com/discus/messages/24/2648.html?1121890613
[15:48:21] <alex_joni> seems other managed to make it work
[15:50:20] <alex_joni> but those are probably some other type
[15:50:41] <SWPadnos> it sounded like they were talking about a software feature, noit a hardware driver
[15:50:49] <SWPadnos> s/noit/not/
[15:53:37] <alex_joni> heh.. mine are similat to these:
http://www.stereo3d.com/revelator_cable.jpg
[15:55:16] <alex_joni> similar.. argh I hate my typing today :(
[15:55:17] <jepler> Lerneaen_Hydra2: why do you say "argh" when you find out my .pngs come from 3d models?
[16:04:30] <jepler> there, I think I've fixed the bugs.
http://emergent.unpy.net/index.cgi-files/sandbox/lace3.png
[16:06:16] <jepler> eep
[16:06:31] <jepler> wrong image!
[16:06:34] <jepler> and boy is it wrong
[16:06:45] <jepler> try this instead:
http://emergent.unpy.net/index.cgi-files/sandbox/lace2.png
[16:10:06] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/image-to-gcode.py: fixes for non-square images and output orientation
[16:14:13] <EHJ-1> Can someone answer a general linux question about using signals between peer threads?
[16:15:22] <jepler> I can try but I don't use threads much
[16:15:52] <EHJ-1> Is there a way for peer threads to notify eachother, or does the parent need to keep a table of pids of children, then when notified by one child, in thurn send a signal to each of the other children?
[16:16:48] <alex_joni> you can send a list with pids to the children
[16:18:09] <EHJ-1> a list? With what function?
[16:18:09] <alex_joni> but usually (if I remember this right) one opens a pipe from the main process to the spawned one
[16:18:09] <jepler> this is over my head, I'm not sure of the answer.
[16:18:09] <alex_joni> EHJ-1: same here.. no expert by far
[16:19:50] <alex_joni> EHJ-1: are you using pthreads?
[16:20:00] <EHJ-1> k, I thought there was a way to set a general signal that any thread could respond to.
[16:20:09] <EHJ-1> Just using "fork".
[16:21:07] <jepler> there is something called pthread_cond_broadcast, which is apparently similar to pthread_cond_signal but for the case that more than one thread is "in a blocking wait state" .. er, nevermind.
[16:21:08] <alex_joni> if he's using fork() then no pthread
[16:21:08] <EHJ-1> I just want to communicate a single "state" between each peer thread.
[16:22:04] <alex_joni> how about a global var?
[16:22:07] <alex_joni> and some mutexes?
[16:22:28] <Lerneaen_Hydra2> jepler: not argh at that the models are 3d, but alex_joni's awful pun ;)
[16:22:31] <EHJ-1> I thried both fork and vfork, which doesn't push the context. I see how to signal between parent and child, I just thought there would be an easier way than having to maintain a list of pids for each thread spawned by fork.
[16:22:51] <alex_joni> EHJ-1: probably you need to do it yourself
[16:22:57] <alex_joni> get the list from all the children
[16:23:08] <EHJ-1> Yea, I was looking at global vars too. That seemed as hard as maintaining a table of pids.
[16:23:16] <alex_joni> how so?
[16:23:17] <Lerneaen_Hydra2> jepler: nice image/toolpath :D
[16:24:09] <EHJ-1> Just in setting up the shared data space.
[16:25:22] <alex_joni> hmm.. do you really need that?
[16:25:22] <alex_joni> I thought fork()ed children inherit all the rest
[16:25:36] <EHJ-1> I thought I did, based on how things operated. It sure seemed like there should be an easier way.
[16:25:37] <jepler> maybe you should consider use of pthreads instead of fork(). It will help you do stuff like share state among threads.
[16:26:07] <EHJ-1> If you use fork, the entire context (variable space) gets duplicated, so one peer thread can't see the data space of another.
[16:26:56] <EHJ-1> k, I will look that up. I didn't see that in my linux book (linux for Windows programmers <g>).
[16:27:30] <jepler> http://www.llnl.gov/computing/tutorials/pthreads/
[16:27:36] <EHJ-1> thanx
[16:30:45] <Lerneaen_Hydra2> jepler: should a cvs update be safe now?
[16:31:03] <Lerneaen_Hydra2> as safe as head can be that is ;)
[16:31:21] <alex_joni> Lerneaen_Hydra2: yeah..
[16:31:29] <alex_joni> last time I tried it worked
[16:31:37] <Lerneaen_Hydra2> ok
[16:40:03] <Lerneaen_Hydra2> jepler: maybe instead of "ROWS" and "COLUMNS" it should be something with X and Y?
[16:40:24] <Lerneaen_Hydra2> then again, with ROWS and COLUMNS people running special kins won't be affected
[16:41:18] <alex_joni> X and Y are the same for special kins too
[16:41:18] <Lerneaen_Hydra2> oh
[16:41:18] <Lerneaen_Hydra2> ok
[16:41:18] <jepler> I'm sure all the user-interface texts need improvement
[16:41:18] <Lerneaen_Hydra2> haha, ok
[16:41:25] <Lerneaen_Hydra2> maybe some way to save the gcode to a file would be good
[16:42:21] <jepler> to do that, run from the shell: image-to-gcode blah.png > foo.ngc
[16:43:05] <Lerneaen_Hydra2> oh, in which dir?
[16:43:17] <Lerneaen_Hydra2> it assume it uses the previous settings?
[16:43:28] <Lerneaen_Hydra2> still, a GUI method to do that would be good
[16:43:35] <jepler> well for run-in-place just give the path to image-to-gcode
[16:43:52] <Lerneaen_Hydra2> (here I am adding stuff to the feature list again :/ )
[16:45:30] <Lerneaen_Hydra2> something I just noticed, when attempting to zoom in really close (to see blending effects in sim) there seems to be some type of clipping
[16:46:35] <jepler> Lerneaen_Hydra2: yes, there is
[16:47:01] <Lerneaen_Hydra2> IMO it occurs too far away, though I don't really know what I'm talking about
[16:47:21] <Lerneaen_Hydra2> so it may be good to be able to zoom closer by adusting that variable
[16:48:55] <tomp> hello all
[16:49:05] <jepler> hi tomp
[16:49:16] <Lerneaen_Hydra2> hi
[16:49:24] <alex_joni> hi tomp
[16:57:03] <alex_joni> * alex_joni will be back later
[16:58:18] <jepler> see you alex_joni
[16:59:40] <tomp> cul8r
[17:00:51] <Lerneaen_Hydra2> bye alex_joni
[17:01:00] <Lerneaen_Hydra2> hi Bo^Dick
[17:01:43] <dmessier> hi all. chech this machine out
http://www.mecof.it/ING/emcolineaperforma.htm
[17:03:00] <jepler> nice, but out of my budget
[17:04:42] <dmessier> a good friend of mine just commissioned it and has no work for it... but i do... l ; )
[17:29:18] <Lerneaen_Hydra2> a bit over my bbudget too ;)
[17:29:24] <Lerneaen_Hydra2> jepler: what are you using EMC for?
[17:41:25] <jepler> Lerneaen_Hydra2: nothing, really. I don't have a CNC machine aside from my etch-a-sketch.
[17:41:30] <jepler> occasionally I mill PCBs on cradek's maxnc
[17:43:22] <jmkasunich> its good to know I'm not the only EMC developer who doesn't have a CNC machine
[17:43:35] <jepler> hi jmk
[17:43:39] <jmkasunich> hi
[17:44:57] <jepler> Lerneaen_Hydra2: you were telling me that up/down milling is related to the second derivative of the surface, but from that image it looks like it's about the slope (first derivative)...
[17:45:50] <Lerneaen_Hydra2> partly
[17:45:50] <Lerneaen_Hydra2> to find the point where you have to stop, raise the tool, and then move it for a re-placing the second derivative is quite usefull
[17:46:06] <Lerneaen_Hydra2> though you'll need the first derivative to find out which direction to go in the first place
[17:48:36] <Lerneaen_Hydra2> * Lerneaen_Hydra2 hopes that was understandable
[17:51:31] <Lerneaen_Hydra> * Lerneaen_Hydra is back now
[17:52:18] <Lerneaen_Hydra> is someone from here trying to acsess ftp?
[17:52:22] <Lerneaen_Hydra> jepler maybe?
[17:52:29] <Lerneaen_Hydra> looks like it ;)
[17:53:53] <jepler> yes
[17:54:18] <jepler> just downloading those two screen grabs from yesterday
[17:54:45] <Lerneaen_Hydra> yeah, no problem
[17:55:02] <Lerneaen_Hydra> just a bit surprising that's all
[17:56:14] <Lerneaen_Hydra> are you thinking about implementing stuff that advanced?
[17:56:14] <jepler> oh trying to get an idea how hard it would be
[17:56:14] <Lerneaen_Hydra> ok
[17:56:14] <Lerneaen_Hydra> do you know of any image-derivative library?
[17:56:25] <jepler> I was just going to take the 2D derivative of the tool path
[17:56:35] <jepler> that's not too hard
[17:56:58] <Lerneaen_Hydra> hmm yeah that's quite easy actually
[17:57:22] <Lerneaen_Hydra> how hard do you think it would be to implement those two functions?
[17:57:24] <jepler> something like f'(x) ~= (f(x + eps/2) - f(x - eps/2)) / eps, and eps is 1 pixel
[17:57:39] <jepler> I'll know when I'm done or when I give up...
[17:57:42] <Lerneaen_Hydra> haha
[17:57:44] <Lerneaen_Hydra> ok
[17:58:11] <Lerneaen_Hydra> waterlining should be easy too, right? shouldn't it just be an if then with a bit other stuff?
[17:58:52] <jmkasunich> probably gets interesting when you have to deal with "islands"
[18:00:06] <Lerneaen_Hydra> yeah
[18:00:09] <Lerneaen_Hydra> hmm, maybe not
[18:00:21] <jmkasunich> maybe not interesting?
[18:00:21] <Lerneaen_Hydra> if you just set a certain Z depth to be maximum
[18:00:30] <Lerneaen_Hydra> well, maybe not difficult
[18:00:34] <Lerneaen_Hydra> interesting surely
[18:01:14] <Lerneaen_Hydra> one thing that makes this semi-CAM thing easy is that it's very easy to know where G0 is safe and where it's not
[18:01:30] <Lerneaen_Hydra> so islands don't have to be hard as such
[18:02:06] <jmkasunich> how about islands with lagoons in the middle ;-)
[18:03:07] <Lerneaen_Hydra> :p
[18:03:07] <Lerneaen_Hydra> that's the same thing
[18:03:07] <Lerneaen_Hydra> x.x
[18:03:07] <Lerneaen_Hydra> oh, you meant like that
[18:03:26] <jmkasunich> not exactly the same - you can mill all around an island without moving Z at all, but you have to move Z up and back down to get into the "lagoon"
[18:04:26] <Lerneaen_Hydra> oh, like that
[18:04:28] <Lerneaen_Hydra> yeah
[18:04:34] <jepler> I'd have done the simple thing: always move Z up
[18:04:52] <jmkasunich> ?
[18:05:37] <Lerneaen_Hydra> yeah, move Z to predetermined "safe", then plunge in lagoon
[18:05:37] <Lerneaen_Hydra> maybe the config screen could ask for a safe clearance plane
[18:05:37] <jmkasunich> but what is the algorithm for finding the existance of the lagoon in the first place?
[18:06:48] <Lerneaen_Hydra> oh
[18:07:02] <Lerneaen_Hydra> that would have to be if you have waterlining
[18:07:17] <jepler> maybe waterlining isn't the name for what I mean
[18:07:21] <jmkasunich> yeah, I'm talking about waterlining (maybe I should have explicitly said that)
[18:07:39] <jmkasunich> I'm not entirely sure what waterlining is either ;-)
[18:07:40] <Lerneaen_Hydra> what I mean is this; (does a CAM file and screenshot)
[18:07:41] <jepler> I mean simply not descending further than Z=-k in the first pass, Z=-2k in the second pass, and so forth until you reach the bottom depth
[18:07:46] <Lerneaen_Hydra> yep
[18:07:52] <Lerneaen_Hydra> that's what I mean too
[18:07:53] <jmkasunich> oh, ok
[18:08:03] <jmkasunich> but the scan is still lines in X or Y
[18:08:08] <jepler> yes
[18:08:08] <Lerneaen_Hydra> for lagoons to have any meaning you would have to have that effect
[18:08:17] <jmkasunich> I thought you were talking about doing something like contour lines on a map
[18:08:31] <jepler> jmkasunich: did you see the screenshot?
http://emergent.unpy.net/index.cgi-files/sandbox/lace2.png
[18:08:42] <jmkasunich> yeah
[18:09:45] <jmkasunich> waterlining as you've just described is is just multiple runs of that algorithm, with differnet base planes each time, and rapids once Z gets above the previous base plane
[18:10:10] <Lerneaen_Hydra> yeah
[18:10:26] <Lerneaen_Hydra> also it would be nice if you don't remachine the bits you've already done
[18:12:08] <jmkasunich> once Z > previous_base_plane, you want to pull up to avoid touching the part, and rapid to the next time Z < prev_base_plane
[18:12:19] <Lerneaen_Hydra> yeah
[18:13:01] <Lerneaen_Hydra> maybe with a lead-out
[18:13:01] <jmkasunich> the rapid either has to follow the part contour with some Z offset, or just go up to a safety plane
[18:13:06] <jmkasunich> if you follow the contour, blending will be different at high speed, so you need the offset so you don't hit the part during blends
[18:14:09] <jmkasunich> a contour line based approach would probably be faster for many parts (but harder to implement)
[18:16:28] <jmkasunich> jepler: the "depth" in the program is the overall depth, from the whitest pixel to the blackest one?
[18:17:26] <jepler> jmkasunich: it's the depth for the "0" pixel, or the darkest one if "Normalize image" is checked.
[18:17:35] <Lerneaen_Hydra> ftp://basic:basic@lerneaenhydra.shacknet.nu/waterlining_example.ngc
[18:18:01] <Lerneaen_Hydra> though that profile is not quite the same as the one we are discussing, as it doesn't smooth out the missing bits
[18:18:05] <jepler> (No such file `waterlining_example.ngc'.
[18:18:08] <Lerneaen_Hydra> and it has some other logics
[18:19:06] <Lerneaen_Hydra> funny...
[18:19:06] <Lerneaen_Hydra> oh
[18:19:06] <Lerneaen_Hydra> wrong folder
[18:19:06] <jepler> no, really
[18:19:06] <Lerneaen_Hydra> there
[18:20:00] <jepler> well there are a whole lot of things there my program doesn't do .. and won't anytime soon
[18:20:48] <Lerneaen_Hydra> oh, I don't mean to say that everything I'm talking about should be added
[18:20:58] <Lerneaen_Hydra> even as it is now it's extremely usefull
[18:21:14] <jmkasunich> if the part is too deep to cut in one pass, the existing program could still be used, with some preprocessing
[18:21:29] <Lerneaen_Hydra> yeah
[18:21:42] <jmkasunich> take the original image, and use some image processing program to make every pixel less than some value = that value
[18:21:46] <jmkasunich> use that image for the first pass
[18:22:20] <Lerneaen_Hydra> yeah that would work
[18:22:30] <Lerneaen_Hydra> and the second image would exclude the bits you've alread done
[18:22:57] <Lerneaen_Hydra> ftp://basic:basic@lerneaenhydra.shacknet.nu/f''(x)_example.ngc
[18:23:16] <Lerneaen_Hydra> is that link valid?
[18:23:41] <Lerneaen_Hydra> I'll fix it
[18:24:08] <Lerneaen_Hydra> updown_example.ngc
[18:24:40] <Lerneaen_Hydra> ftp://basic:basic@lerneaenhydra.shacknet.nu/updown_example.ngc
[18:26:10] <jepler> if you don't want to cut the final surface except in the last pass, why not make sure each waterlining pass goes no closer than TOL to the surface .. so it's not min(model_z, waterline_z) in those passes, but min(model_z + TOL, waterline_z)
[18:26:25] <Lerneaen_Hydra> TOL, is that tolerance?
[18:27:01] <jepler> it's some value
[18:27:04] <jmkasunich> sure
[18:27:06] <Lerneaen_Hydra> AFAIK when running with a roughing and then a final pass you want around 0.2-0.5 mm
[18:27:09] <Lerneaen_Hydra> oh, ok
[18:27:14] <Lerneaen_Hydra> yeah that's good
[18:27:26] <jmkasunich> I was thinking something completely different (and worse)
[18:27:36] <Lerneaen_Hydra> hmm, one thing that's harder to add (and less important) is offsetting in X
[18:27:51] <jepler> in X?
[18:27:54] <Lerneaen_Hydra> yeah
[18:28:06] <Lerneaen_Hydra> so a straight wall would have some material left for the final pass
[18:28:07] <jmkasunich> I thought that pass 1 would do the finish cut for everything above its base plane, and pass 2 would do the finish cut for everything below pass 1
[18:28:52] <jmkasunich> but the transition would probably be visible and ugly
[18:28:52] <Lerneaen_Hydra> sometimes that's good, but the transition is ugly
[18:28:52] <Lerneaen_Hydra> ^^^^ what you said
[18:28:52] <Lerneaen_Hydra> so if you leave a bit unmachined that can be removed in the last pass
[18:29:38] <jmkasunich> if the total part depth is such that it would take three passes, the total job would require four do get nice results
[18:29:43] <jmkasunich> three roughing, then a finishing
[18:29:50] <Lerneaen_Hydra> yeah
[18:29:52] <Lerneaen_Hydra> exactly
[18:30:02] <Lerneaen_Hydra> usually you'd even have higher feed on the roughing
[18:30:37] <jmkasunich> as written, all the roughing passes would run at F1 feed all the time
[18:30:46] <Lerneaen_Hydra> yeah
[18:30:49] <jmkasunich> G1 feed, not F1
[18:31:15] <Lerneaen_Hydra> so ideally you would have four feeds, roughing plane movement, roughing plunge, finish plane, finish plunge
[18:31:53] <jmkasunich> plunging is gonna be ugly
[18:32:10] <Lerneaen_Hydra> if you set waterlineing to sane values it's not that bad
[18:32:24] <jmkasunich> if the part has a vertical wall and you are moving from the high side to the low side, it will be straight down, and many end mills won't cut that way
[18:32:29] <Lerneaen_Hydra> CAM apps have ramping stuff though
[18:32:45] <Lerneaen_Hydra> you'd need a center cut mill
[18:33:29] <Lerneaen_Hydra> poor jepler, we just keep adding stuff to the list of features...
[18:33:29] <jmkasunich> heh, we're not doing that
[18:33:31] <jmkasunich> we're talking about a generic problem
[18:33:41] <jmkasunich> he's free to choose any subset of the problem he wants to solve
[18:34:00] <Lerneaen_Hydra> yeah, of course
[18:34:09] <jmkasunich> I think for best roughing performance (speed) you'd want a contour line approach
[18:34:21] <jmkasunich> that way the depth of cut remains constant
[18:34:53] <jmkasunich> no ramping
[18:35:24] <jmkasunich> oops, thats not so efficient after all
[18:35:44] <jmkasunich> assuming large Z steps, you'd have a lot of uncleared material if the slope was shallow
[18:38:03] <Lerneaen_Hydra> yeah
[18:38:13] <Lerneaen_Hydra> like the first example program
[18:38:20] <Lerneaen_Hydra> lots of material left behin
[18:38:42] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/by_sign.ngc
[18:39:29] <jepler> you could use a "bigger" tool on the other passes to make sure you don't get too close to a wall
[18:40:19] <jepler> is this correct "up milling"?
[18:40:36] <jepler> (if suboptimal)
[18:40:50] <jmkasunich> you are starting at the arrow?
[18:41:01] <jmkasunich> so you plunge straght down and ramp up?
[18:41:35] <jepler> yes
[18:41:36] <jmkasunich> duh, stupid question, riunning the program shows what you are doing
[18:41:41] <jepler> yes
[18:42:09] <jmkasunich> that assumes a tool that can plunce straight down
[18:42:21] <jmkasunich> usually ramping is preferred
[18:42:23] <Lerneaen_Hydra> jepler: I don't have an emc machine here now, could you screengrab?
[18:42:38] <Lerneaen_Hydra> you can paste in ftp://basic:basic@lerneaenhydra.shacknet.nu/upload
[18:42:44] <jmkasunich> although that particular profile is so steep its almost plunging anyway
[18:42:48] <Lerneaen_Hydra> ramp or helix
[18:43:18] <Lerneaen_Hydra> I think I get it though
[18:43:29] <jmkasunich> the part is basically a sine wave, with about 60-70 degree slopes
[18:43:30] <Lerneaen_Hydra> up milling is better for shallow objects
[18:43:35] <jepler> by
http://emergent.unpy.net/index.cgi-files/sandbox/by_sign.png
[18:43:41] <Lerneaen_Hydra> down milling for deep parts
[18:43:52] <Lerneaen_Hydra> oh
[18:44:01] <Lerneaen_Hydra> for something like that you'd definetly want down milling
[18:44:09] <jepler> well my point wasn't whether up or down milling is right in this case
[18:44:24] <jepler> but whether this file is an example of up milling
[18:44:26] <Lerneaen_Hydra> if you squashed the Zscale so the trough was the same as the ball radius then up would be better
[18:44:30] <Lerneaen_Hydra> yes it is
[18:45:29] <jmkasunich> Lerneaen_Hydra: what do you mean by down milling?
[18:45:33] <Lerneaen_Hydra> how does it return to the bottom to do the other half?
[18:45:38] <jmkasunich> I'd think that down on a steep ramp is bad
[18:45:54] <Lerneaen_Hydra> jmkasunich: ftp://basic:basic@lerneaenhydra.shacknet.nu/
[18:45:58] <Lerneaen_Hydra> up down mill.png
[18:46:00] <jmkasunich> each vertical line is traveled twice
[18:46:08] <Lerneaen_Hydra> oh, ok
[18:46:19] <Lerneaen_Hydra> yeah that makes sense
[18:47:06] <jmkasunich> ok, down milling only works when the material to be removed is less than the tool radius, so you're not trying to cut at the center of the tool
[18:47:43] <Lerneaen_Hydra> well, that was their example. in that cam app you usually do a roughing first and have the paralell lace as finishing
[18:52:19] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/upmill.png
[18:52:43] <Lerneaen_Hydra> that looks good actually
[18:52:55] <jepler> like you might actually be able to mill it?
[18:53:18] <Lerneaen_Hydra> except for the excess left near the g0 bit (becuase of blending)
[18:53:23] <Lerneaen_Hydra> it looks millable
[18:55:06] <jepler> would I actually want to dwell or exact-stop at the end of the plunge or before the g0 out?
[18:57:33] <Lerneaen_Hydra> hmm
[18:57:41] <Lerneaen_Hydra> the best solution is a lead out
[18:57:56] <Lerneaen_Hydra> the updownmill_example file has that
[18:58:05] <Lerneaen_Hydra> 45° of 5mm radius
[19:40:47] <alex_joni> 'lo
[19:40:50] <Lerneaen_Hydra> 'lo
[19:42:28] <alex_joni> did I miss anything?
[19:43:50] <Lerneaen_Hydra> how could tyou?
[19:44:33] <Lerneaen_Hydra> you were connected the whole time
[19:44:33] <alex_joni> well.. was just reading back now ;)
[19:44:33] <Lerneaen_Hydra> mostly it was discussion about possible features in jepler's image-to-gcode
[19:44:33] <Lerneaen_Hydra> oh, right ;)
[19:44:33] <alex_joni> was hoping for a summarize :)
[19:45:02] <Lerneaen_Hydra> not sure if there was a conclusion as such, but mainly a discussion of possible features
[19:45:02] <alex_joni> ok, that's probably more than enough ;)
[19:47:02] <Lerneaen_Hydra> 'night
[19:47:15] <alex_joni> night
[19:50:43] <pier> hi all
[19:50:43] <alex_joni> hi pier
[19:50:43] <pier> hi alex
[19:51:03] <alex_joni> how was F1 ?
[19:51:15] <alex_joni> wasn't it in italy this weekend?
[19:51:17] <pier> was wondering... a possible use of my cnc code before
[19:51:21] <pier> F1..
[19:51:31] <pier> I don't know :)
[19:51:46] <pier> prefer motorbykes
[19:52:15] <alex_joni> oh.. I see it was turkey ;)
[19:52:25] <alex_joni> what cnc code where you wondering about?
[19:52:52] <pier> I wrote a CNC code (that I still use under dos)
[19:53:51] <pier> that cut 2D pieces from dxf cad drawings
[19:53:55] <pier> now that I want to use just plain linux (and EMC of course)
[19:54:18] <pier> I need a translator of my old drawings into G-code
[19:54:45] <pier> and, as I already ported this code to linux c code
[19:54:48] <alex_joni> pier: there are a few noted here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Cam
[19:55:09] <pier> going to have a look at it
[19:57:21] <pier> ok... so my code is completely useless.. thank you :)
[19:58:10] <alex_joni> pier: not useless.. I wouldn't say that
[19:58:18] <alex_joni> does it properly convert to G-code ?
[19:58:40] <pier> not yet... I was thinking that writing some more lines
[19:58:41] <alex_joni> can you release under GPL? or any other Open Source license?
[19:59:20] <alex_joni> if so.. it might be interesting ;)
[19:59:39] <pier> I really don't care about putting the source code on a site
[19:59:39] <alex_joni> but I think I saw some dxf-lib out there, so it shouldn't be hard to write :D
[20:00:07] <pier> but I am afraid that it is not professionally written
[20:00:13] <alex_joni> pier: too bad it's not python.. bet jepler would have wanted it to use as a filter for AXIS
[20:00:43] <pier> plain C
[20:00:50] <alex_joni> that's not that bad ;)
[20:01:42] <pier> I think I'll put it on a page once it is ready
[20:01:52] <pier> the source I mean
[20:02:43] <alex_joni> you decide that ;)
[20:02:43] <alex_joni> take a look at other available stuff, and then decide if it's worth to invest more time/energy or noe
[20:02:43] <alex_joni> not
[20:03:24] <pier> you know... it is just putting the output to svga (in the graphic preview)
[20:03:32] <jepler> alex_joni: there's no need for AXIS filters to be written in Python
[20:03:43] <alex_joni> jepler: oh..
[20:03:44] <jepler> they are any Unix program that takes a filename as a parameter and writes g-code to standard output
[20:04:00] <alex_joni> then this may be interesting for emc2/AXIS
[20:04:02] <pier> in terms of writing the proper G1 movement
[20:04:07] <jepler> * jepler disappears again
[20:05:38] <pier> es:line(100, 200, 0, 20) -> writeln to a file "G1 X100 Y200 Z20 F20"
[20:06:16] <pier> but it would be probably discovering hot water again
[20:08:32] <jepler> there's also no reason that the other GUIs couldn't use the same ini-file entries to allow filters to work
[20:16:09] <alex_joni> jepler: I know of one reason
[20:16:23] <alex_joni> nobody motivated enough to code it..
[20:20:12] <pier> I am having a look at
http://www.mgl.ca/~ecp/gobweb/cnc.c
[20:21:08] <pier> very short code.... it took me more than 1000 lines... perhaps I am not so good at coding
[20:21:24] <pier> but reordering the entities took me a lot
[20:21:47] <pier> to optimize the lenght of the tool treck
[20:21:51] <pier> track
[20:22:35] <pier> and then cutting the internal holes first
[20:26:06] <jepler> pier: what language is that (e:line ...)?
[20:26:10] <jepler> er, es:line
[20:26:23] <pier> 1 sec
[20:27:43] <pier> sorry gl_line
[20:28:28] <pier> C
[20:28:57] <pier> peorting from borland
[20:29:01] <pier> porting
[20:29:13] <jepler> ah
[20:29:20] <jepler> : confused me
[20:29:25] <pier> sorry
[20:30:07] <pier> after porting the whole lot under linux
[20:31:44] <pier> I discovered it wasn't all that easy to write to parport
[20:31:44] <pier> as it was in dos
[20:31:44] <jepler> no, it's not
[20:31:44] <pier> :)
[20:32:35] <pier> for timing I just wrote few asm lines for timing the 8253
[20:34:07] <pier> so now my code is useless unless I could use it as a dxf to G-code translator
[20:35:19] <jepler> it sounds possible
[20:35:29] <alex_joni> even interesting
[20:39:14] <pier> I woudd just have to remove all the writing instructions to the parport address and substitute the function that moves the tool dx, dy, dz, f with the corresponding G string (no pun here)
[21:01:38] <davidf> hi
[21:02:56] <davidf> Well, darn it, I thought I had everything working great. input_scale = 40000, 2000 uSteps, very smooth travel etc.
[21:03:33] <davidf> Just now as I was homing the y axis, it stopped midway and sounded like a car horn.
[21:03:53] <davidf> Just kept that up, motionless, till I hit the e-stop.
[21:04:05] <davidf> Anybody ever had this happen?
[21:04:16] <robin_sz> steppers?
[21:04:21] <davidf> yes.
[21:04:25] <davidf> Hi robin_sz
[21:04:27] <robin_sz> yes, they do that all the time
[21:04:41] <davidf> increase current?
[21:04:47] <robin_sz> nope
[21:04:49] <davidf> I have plenty left.
[21:04:53] <davidf> ok...
[21:05:45] <davidf> Any suggestions?
[21:05:45] <davidf> Besides lump it?
[21:05:45] <davidf> :)
[21:05:45] <robin_sz> is this your low geared dividing head?
[21:06:01] <davidf> No, this is the mill Y axis. 20 TPI lead screws.
[21:06:07] <robin_sz> right ...
[21:06:26] <robin_sz> and these are standard ACME type screws?
[21:06:35] <davidf> It really sounds real good 99% of the time.
[21:06:52] <davidf> no theyre triangular thread
[21:07:01] <robin_sz> whatever, not ball screws
[21:07:32] <davidf> no.
[21:07:39] <robin_sz> are you running the motors close to their design current?
[21:08:12] <davidf> I truned off the driver and tried turning the shaft. It was free.
[21:08:26] <robin_sz> as expected ...
[21:08:39] <robin_sz> are you running the motors close to their design current?
[21:09:37] <davidf> Thgey are at 2 amp. I think the rating is 3.0 have to check. They are cool.
[21:10:18] <robin_sz> in that case, yes, do turn it up
[21:11:09] <robin_sz> I was assuming you were at rated current
[21:11:10] <davidf> no
[21:11:16] <robin_sz> anything up to 70~80c is considered normal for case temperature for steppers
[21:11:45] <davidf> This was so strange. just really smooth & sounds perfect, then this very rare out of the blue
[21:11:55] <robin_sz> how many Nm are the motors?
[21:12:12] <davidf> 282 oz in,
[21:12:21] <davidf> plenyty for this mill.
[21:12:28] <robin_sz> ummm ... whats that? 2.5nm?
[21:12:40] <robin_sz> and what dia are the screws?
[21:12:44] <robin_sz> .5in?
[21:12:56] <davidf> But with uStepping you're not at full power between detents though.
[21:13:10] <davidf> have to look it up...
[21:13:20] <davidf> 1/2 inch shafts
[21:13:40] <robin_sz> and I assume they are direct drive to the screws?
[21:14:07] <davidf> yes.
[21:14:08] <robin_sz> no, you have mroe power ...
[21:14:31] <robin_sz> think about it ... on coil on = full step
[21:14:47] <davidf> What I meant is ...
[21:14:53] <robin_sz> mid step you have two coils at about 71% ...
[21:15:34] <robin_sz> actually, most good drives trasition to full step mode over about 600 rpm
[21:16:02] <davidf> when the rotor is 1/2 way between two poles, the rotor is being held between them, and not directly as close to either one as with a full step
[21:16:19] <davidf> oh, didn't know that.
[21:16:22] <alex_joni> * alex_joni heads to bed..
[21:16:25] <alex_joni> g'night all
[21:16:31] <davidf> nite alex_joni
[21:16:40] <robin_sz> parker have patent on it, so I assume the use it ...
[21:16:57] <davidf> How bout that.
[21:17:11] <robin_sz> they transition to a trapezoidal and then a square wave from a sine wave at low revs ...
[21:17:23] <robin_sz> anyway ...
[21:18:31] <robin_sz> the other option is to either limit the speed, or gear the motors
[21:19:00] <robin_sz> it CAN also be the controller .. if it has a delay and fails to send pulses and then catches up in a hurry .. it stalls the motr and it never recovers
[21:19:04] <alex_joni> robin_sz: this was during homing..
[21:19:13] <alex_joni> so I doubt speed was involved
[21:19:18] <robin_sz> right ....
[21:19:27] <alex_joni> * alex_joni really heads to bed now
[21:19:53] <davidf> speed was 20 in/min.
[21:20:07] <robin_sz> mmm 400 rpm
[21:20:12] <davidf> 282 oz in = 1.99 NM
[21:20:50] <davidf> too fast?
[21:21:08] <davidf> X can do 120 in/min in this config.
[21:21:08] <robin_sz> 400 rpm on screws like that is a bit hard for such a small motor I suspect .. try limiting the speed
[21:21:14] <robin_sz> coo.
[21:21:20] <robin_sz> 2400 rpm?
[21:21:35] <davidf> looks like it.
[21:21:36] <robin_sz> thats pretty impressive
[21:21:44] <robin_sz> and it does that reliably?
[21:21:58] <davidf> I've actually had it up to 136 in/min before it complained.
[21:22:07] <robin_sz> wow ... thats impressive
[21:22:17] <davidf> I run 30 all the time.
[21:22:22] <robin_sz> forget the motors not being up to turning that screw then
[21:22:34] <robin_sz> must be very free running
[21:22:45] <davidf> The factory motors are smaller than mine and the specs for the mill with those are 30 in/min.
[21:22:54] <robin_sz> fairy nuff
[21:23:05] <robin_sz> so, probably a pulse glitch of some flavour
[21:23:18] <robin_sz> are you opto isolated on the inputs?
[21:25:10] <davidf> That's what I'm thinking too, since it has only happened once after about an hour running time all together in this config
[21:25:10] <davidf> yes.
[21:25:10] <robin_sz> hmmm
[21:25:10] <robin_sz> might just have been a latency thing in the RT side for a moment ...
[21:25:10] <robin_sz> glitched, stalled em and sat there.
[21:25:10] <davidf> Oh, I'm using an old Heathkit prototyping hobby box for the power supply to the interface.
[21:25:10] <robin_sz> uhhh ...
[21:25:12] <robin_sz> oh not for the motors?
[21:25:14] <davidf> I have hex inverters after the par port & then on to the Parkers.
[21:25:16] <robin_sz> thats prolly OK
[21:25:30] <davidf> I really don't need the inverters though.
[21:25:44] <davidf> Maybe the power supply wigged out or something...
[21:25:49] <robin_sz> mmmm
[21:26:00] <robin_sz> stick a bigger C on it
[21:26:19] <davidf> yeah.
[21:26:51] <robin_sz> * robin_sz gets annoyed with some idiot on Groklaw
[21:26:53] <davidf> not for the motors. The Parkers use 120 V chopped direct from the line.
[21:27:03] <davidf> No Xfrmrs
[21:28:03] <davidf> robin_sz, what is RT side?
[21:28:09] <davidf> Real Time?
[21:28:44] <robin_sz> the real time side of the system ... if the rt scheduler doesnt have the resources to perform the task in the time it needs, well it gets messy
[21:28:57] <robin_sz> normally its rock solid
[21:29:08] <davidf> Can any process interrupt it?
[21:29:09] <robin_sz> but near the limits "bad things" can hppen
[21:29:25] <robin_sz> mmm ... user side processes no
[21:29:25] <davidf> Well I am near the limit...
[21:29:34] <robin_sz> its upstream of the linux kernel in effect
[21:30:08] <robin_sz> but, during an rt timeslot, as I understand it, it has to be able to complete all the things it needs to do ... if it hangs on too long "bad things" can happen
[21:30:11] <davidf> I kept lowering BASE_PERIOD till bad things happened, then put it up some.
[21:30:27] <robin_sz> maybe a bit close?
[21:30:55] <davidf> I think I had problems below 10000 ns.
[21:31:39] <davidf> Actually I think 10000 was ok, 8000 was not. I put it at 12000, => input_scale = 40000,
[21:31:51] <robin_sz> shrug
[21:31:53] <davidf> 1/(2* 12000) = 41600.
[21:31:55] <robin_sz> no clues
[21:32:44] <davidf> SWPadnos, here?
[21:34:04] <davidf> I need at least 40000 for 2000USteps. I could run at 1000 USteps & half the RT speed. Maybe I'll try that. What do you think?
[21:34:55] <jmkasunich> I would do 1000uSteps and base_period = 20000
[21:35:10] <jmkasunich> or maybe 16000 or 18000
[21:35:25] <davidf> OK. The box is pretty slow for other things at 40000 anyway.
[21:36:09] <davidf> As I understand it, (or misunderstand it)...
[21:36:46] <davidf> My choices on the drive are 1000, 2000, 5000, etc...
[21:36:55] <jmkasunich> right
[21:37:05] <jmkasunich> you just said you were running 2000
[21:37:12] <jmkasunich> which requires an input scale of 40000
[21:37:23] <davidf> So I have to use either 20000 scale or 40000 scale to make the numbers work.
[21:37:29] <jmkasunich> right
[21:37:43] <davidf> so cant do 16000 or 18000...
[21:37:45] <jmkasunich> drive uSteps/rec = 1000, input_scale = 20000
[21:37:59] <davidf> rec?
[21:38:08] <jmkasunich> rev
[21:38:10] <jmkasunich> sorry
[21:38:14] <davidf> k
[21:38:27] <jmkasunich> anyway, the 16000, 18000 I was talking about was for base_period
[21:39:01] <davidf> ok,
[21:39:08] <jmkasunich> smaller values of base period allow higher step frequencies, _but_ they put a heavier load on the computer
[21:39:29] <davidf> But SWPadnos told me input_scale = 1/(2* BASE_PERIOD)
[21:39:30] <jmkasunich> you did trial and error, found out the computer got very unhappy at 8000, kinda OK at 10000
[21:39:47] <davidf> yes...
[21:40:00] <davidf> seemed ok at 10K
[21:40:04] <jmkasunich> the highest possible value of input scale is a little less than 1/(2*base_period)
[21:40:12] <davidf> oh I see...
[21:40:15] <jmkasunich> that'd not the same as =
[21:40:21] <davidf> ah.
[21:40:39] <jmkasunich> actually even that is a huge oversimplification
[21:40:44] <davidf> SWPadnos should have said <= not =
[21:41:13] <davidf> why am I not surprised...
[21:41:32] <davidf> it's more complicated than that...
[21:41:35] <jmkasunich> its not really that complicated
[21:41:36] <davidf> :)
[21:41:55] <davidf> Just esoteric.
[21:42:04] <jmkasunich> not even esoteric
[21:42:17] <jmkasunich> you just have to be willing to do some math, and understand a few simple facts
[21:42:28] <davidf> How do I find out the whole story?
[21:42:40] <jmkasunich> I'm gonna try to 'splain it
[21:42:43] <davidf> willing & able :)
[21:42:57] <jmkasunich> ok, first - base period
[21:43:07] <davidf> I'll try to 'stand it
[21:43:13] <jmkasunich> the code that makes steps runs periodically
[21:43:21] <jmkasunich> base_period is the time between each run
[21:43:25] <jmkasunich> in nanoseconds
[21:43:49] <jmkasunich> so if you set base_period to 50000, then the step code will run 20,000 times per second
[21:44:01] <jmkasunich> because 1 second divided by 50000nanoseconds = 20000
[21:44:05] <davidf> run being a group of output pulses?
[21:44:13] <jmkasunich> no
[21:44:21] <jmkasunich> it has nothing to do with output at this point
[21:44:28] <davidf> k
[21:44:28] <jmkasunich> that is just how often the code runs
[21:44:34] <davidf> oh.
[21:44:49] <jmkasunich> the code runs at the same speed all the time, and every time it runs it decides "should I make a pulse now?"
[21:45:23] <davidf> ok
[21:45:46] <jmkasunich> so if the base period is 50000, the code is running 20,000 times per second, whether you are making one pulse per second, or 100, or 10000
[21:46:00] <davidf> I see
[21:46:53] <jmkasunich> in order to make a single pulse, the code has to decide "its time to make a pulse", and turn the output on
[21:46:59] <jmkasunich> the next time it runs, it turns the output off
[21:47:10] <davidf> Ah, so there is overhead for the code, and so input_scale needs to be enough below the base frequency to allow for that.
[21:47:12] <jmkasunich> the soonest it can make another pulse is the time after that
[21:47:25] <jmkasunich> you're getting ahead... be patient
[21:47:31] <davidf> sorry.
[21:47:35] <jmkasunich> k
[21:48:10] <jmkasunich> anyway, if the code is running 20,000 times per second, the fastest it can make pulses is 10,000 times/second
[21:48:20] <jmkasunich> because it needs one run to turn the pulse on and one to turn it off
[21:48:44] <jmkasunich> if you want faster pulses, you have to run the code more often
[21:48:55] <jmkasunich> thats why you use shorter base_period
[21:49:14] <jmkasunich> with a base period of 10000 nanoseconds, the code is running 100,000 times every second
[21:49:30] <jmkasunich> and you can in theory make 50,000 step pulses per second
[21:50:09] <jmkasunich> but when that code is running 100,000 times per second, it doesn't leave the CPU much time for anything else - thats why your computer starts to get slow when you have very small base_period
[21:51:02] <jmkasunich> got it so far?
[21:51:02] <davidf> yes.
[21:51:06] <jmkasunich> what SWP told you was the absolute theoritical maximum step pulse frequency you can get for any given base_period
[21:51:23] <jmkasunich> but you _don't_ really want to ask for that high of a frequency
[21:51:50] <jmkasunich> let's use your numbers - base_period is 10000, the code is running 100,000 times a second
[21:52:02] <jmkasunich> and the maximum frequency is 50,000 steps/sec
[21:52:26] <davidf> at BP = 12000, max = 41600, I'm at 40000 ... That ok you think?
[21:52:43] <davidf> I'm running at 12000...
[21:52:47] <jmkasunich> it depends
[21:53:23] <jmkasunich> you keep trying to connect BP to input scale, but thats not all there is
[21:53:32] <jmkasunich> machine velocity also matters
[21:53:33] <robin_sz> 50k steps .... 2000 steps per rev ... 25 revs/second ... thats 1.25 in/ second on 20 tpi screws
[21:53:44] <robin_sz> 80 ipm ...
[21:53:53] <robin_sz> yes?
[21:54:05] <davidf> yes...
[21:54:37] <robin_sz> umm I thought you said it did 120 ipm?
[21:54:37] <davidf> But I'm running 40000, not 50000
[21:54:37] <jmkasunich> stop!
[21:54:37] <robin_sz> * robin_sz estops
[21:54:44] <davidf> not now, I've reconfigured for max vel = 60 ipm.
[21:54:48] <jmkasunich> stopping davidf
[21:55:03] <jmkasunich> 40000 is your input scale, right?
[21:55:08] <robin_sz> indeed. I did notice he was changing stuff halfway through the explanation
[21:55:10] <davidf> yes
[21:55:20] <jmkasunich> that has absolutely nothing at all to do with the 50000 steps/sec in robins math
[21:55:27] <robin_sz> * robin_sz suspects hes fiddling instead of reading.
[21:55:45] <jmkasunich> you keep confusing scale and step-rate
[21:56:00] <robin_sz> * robin_sz nods
[21:56:23] <davidf> ok sorry. I am trying & don't mean to be a pain...
[21:56:36] <jmkasunich> just listen for a while
[21:56:41] <jmkasunich> don't fiddle with anything
[21:56:45] <robin_sz> scale is a physical thing .. how many pulses per inch. not a speed thing. its fixed by physucal properies like gearing and tpi
[21:56:51] <robin_sz> * robin_sz nods
[21:57:19] <davidf> me too.
[21:57:23] <jmkasunich> I'm trying to do this step-by-step, so you actually _understand_ what you are doing (and can do it yourself), instead of blindly taking advice from us
[21:57:38] <davidf> please.
[21:58:03] <jmkasunich> robin has a good idea, lets start with scale (I was starting with base period, maybe this is better)
[21:58:19] <jmkasunich> like he said, scale is nothing more than pulses per inch
[21:58:38] <jmkasunich> so it is determined by your screw, motor, and drive, and nothing else
[21:58:49] <jmkasunich> it has nothing to do with base_period at all
[21:59:17] <jmkasunich> (but once you understand how everything interacts, you can tweak things for the best combination)
[21:59:33] <jmkasunich> lets forget for the moment that you can change the steps/rev on your drives
[21:59:50] <jmkasunich> so, the screw pitch is fixed, the gear ratio is fixed (you don
[21:59:56] <jmkasunich> oops
[22:00:14] <jmkasunich> so, the screw pitch is fixed, the gear ratio is fixed (you don't have any gears, right), and the steps per rev are fixed
[22:00:27] <davidf> right.
[22:00:35] <jmkasunich> therefore, there can be only one value of scale
[22:00:54] <robin_sz> steps per rev are selectable in his case ... which is kinda relevant
[22:01:01] <jmkasunich> 20 revs per inch times 2000 steps per rev = 40000 steps/inch
[22:01:07] <jmkasunich> yeah, I know, and I'll get back to that
[22:01:20] <robin_sz> yep, just reminding for the later calculation
[22:01:20] <davidf> yes
[22:01:27] <jmkasunich> once we see the limits of 2000 steps per rev, he'll be able to see the reason for changing to something else
[22:02:19] <robin_sz> * robin_sz nods sagely
[22:02:19] <jmkasunich> anyway, as long as the drive is set for 2000 steps/rev, scale _must_ be 40000 steps/inch
[22:02:24] <davidf> yes I do understand that aleady jmkasunich
[22:02:36] <jmkasunich> now going back to base period, if its 12000, then the code runs 1e9/12000 times per second
[22:02:52] <jmkasunich> 83,333
[22:03:23] <jmkasunich> that gives you a max step rate of 83,333 / 2 = 41667 steps per second
[22:03:54] <davidf> That's what I meant to say above.
[22:04:13] <jmkasunich> _if_ you are gonna run right up to the theoritical limit, your max speed is 41667 steps/sec divided by 40000 steps/inch, or 1.0417 inches/second
[22:04:23] <jmkasunich> 62.5 inches/min
[22:04:42] <davidf> Im with you...
[22:05:02] <jmkasunich> in practice, I don't think its wise to ask for more than about 2/3 of the theoritical maximum, 1/2 is even better
[22:05:10] <davidf> ah.
[22:05:20] <jmkasunich> do you want me to explain why? or skip that and move on?
[22:05:30] <davidf> Please do explain.
[22:05:33] <jmkasunich> ok
[22:05:40] <davidf> If you don't mind...
[22:05:48] <jmkasunich> at the max step rate, the code is flipplng the step bit every time it runs
[22:05:56] <jmkasunich> on, off, on, off, on, off, etc
[22:06:47] <jmkasunich> suppose you ask for a slightly lower frequency
[22:06:47] <jmkasunich> I need numbers for this
[22:06:47] <jmkasunich> lets assume BP = 10000, the numbers are simpler
[22:06:57] <davidf> k
[22:07:29] <jmkasunich> if you are doing on, off, on, off, on, off, etc, with each on and off lasting 10000nS, that is 20000uS between rising edges, or 50,000 steps/second
[22:07:37] <jmkasunich> suppose you want 45000 steps/second
[22:08:09] <jmkasunich> 45000 steps/sec = 22,222nS between steps
[22:08:17] <jmkasunich> but our code is running every 10,000nS
[22:08:28] <jmkasunich> so it can't do exactly 45000 steps/sec
[22:08:53] <davidf> uh huh.
[22:09:20] <jmkasunich> it can do on,off,on,off,on,off,on,off, for 20,000nS per step, or it can do on,off,off,on,off,off,on,off,off,on,off, etc, for 30,000nS between steps
[22:10:33] <davidf> does get more complicated, I see.
[22:10:43] <jmkasunich> if you want something in between, the best it can do is flip back and forth between on/off/on and on/off/off/on so that the average speed is what you want
[22:10:50] <jmkasunich> and thats exactly what it does
[22:11:14] <jmkasunich> but that flipping makes pulse jitter
[22:11:29] <jmkasunich> the closer you go to the theoritical maximum speed, the worse the jitter gets
[22:11:59] <davidf> The light is dawning... :)
[22:12:36] <jmkasunich> in the case I just mentioned, you have to jitter between 20000nS (50000 steps/sec) and 30000nS (33333 steps/sec)
[22:12:50] <jmkasunich> suppose instead of 45000 steps/sec you were asking for 4500
[22:13:00] <jmkasunich> that means a period of 222,222nS
[22:13:04] <jmkasunich> it still can't do that exactly
[22:13:33] <jmkasunich> it will have to flip between 220000nS and 23000nS
[22:13:54] <davidf> is that a typo?
[22:13:59] <jmkasunich> 220000nS = 4545 steps/sec
[22:14:00] <jmkasunich> yes
[22:14:07] <davidf> k
[22:14:24] <jmkasunich> 230000nS = 4347 steps/sec
[22:14:37] <davidf> much smoother
[22:14:41] <jmkasunich> right
[22:14:50] <robin_sz> mm .. can I interject?
[22:14:54] <jmkasunich> sure
[22:15:06] <robin_sz> I tink they will both be about as smooth ..
[22:15:33] <robin_sz> the usteppign will tend to average out the jitter
[22:15:50] <jmkasunich> hush you
[22:16:36] <jmkasunich> I'm trying to explain to him, not confuse him
[22:16:36] <jmkasunich> ;-)
[22:16:36] <robin_sz> k
[22:16:56] <jmkasunich> with EMC1, my explanation was definitely correct, because it would run at one speed or the other for a full millisecond, then flip to the other speed trying to average out to the right value
[22:17:14] <robin_sz> true ...
[22:17:20] <jmkasunich> for emc2 its more complex, because emc2 flips between speeds on a pulse-by-pulse basis
[22:17:27] <jmkasunich> that is better, but more complicated to understand
[22:18:05] <jmkasunich> anyway, I think davidf now understands why you don't want to use every last bit of the theoritical speed
[22:18:23] <robin_sz> but, basically, its smoother, and we all know smoother is better, because jitter saps power.
[22:19:00] <jmkasunich> right
[22:21:06] <jmkasunich> I forget where I was going with all this :-(
[22:21:07] <jmkasunich> damn senility
[22:21:07] <davidf> You were going right here, I think.
[22:21:07] <jmkasunich> heh
[22:21:07] <davidf> No really.
[22:21:15] <jmkasunich> so, you now know how to calculate scale for any given screw/gear/motor/drive combo
[22:21:33] <jmkasunich> and you know how to calculate max step frequency for any given base period
[22:21:47] <jmkasunich> and you know that you _don't_ want to use the absolute max frequency
[22:22:09] <jmkasunich> so, at BP = 12,000, max_freq = 41,600
[22:22:56] <davidf> yes. I sort of did already, but I just didn't understand that I shouldn't be working so near the max step frequency.
[22:22:57] <jmkasunich> if you decide you are willing to go to 2/3 of that, max_working_freq = 27730 steps/sec
[22:23:03] <davidf> 'k
[22:24:16] <jmkasunich> 27730/40000 steps/inch = 0.693 inches/sec, or 41.6 inches/min
[22:24:16] <robin_sz> fast enough for a small mill for sure
[22:24:16] <davidf> That would be ok.
[22:24:16] <davidf> Yes.
[22:24:16] <jmkasunich> good
[22:24:18] <jmkasunich> now - you are getting that with a base period of 12000nS
[22:24:33] <jmkasunich> the code is running 83,000 times per second, which loads the PC quite a bit
[22:24:46] <davidf> yes a lot.
[22:24:58] <jmkasunich> it doesn't take much to delay the PC by 12000nS (thats only 1.2 millionths of a second)
[22:25:07] <jmkasunich> oops, 12 millionths
[22:25:18] <jmkasunich> still, pretty damned quick
[22:25:27] <jmkasunich> so, what can we do?
[22:25:40] <jmkasunich> your drive can be changed from 2000 steps/rev to 1000steps/rev
[22:25:45] <robin_sz> buy a motion controller?
[22:25:46] <davidf> lower the uSteps yes.
[22:25:48] <robin_sz> oops ;)
[22:25:55] <jmkasunich> that changes your scale from 40000 steps/inch to 20000steps/inch
[22:26:00] <davidf> Cut the pulse rate in half.
[22:26:06] <jmkasunich> if you want to keep the speed the same, the pulse rate is cut in half
[22:26:16] <jmkasunich> so you can double the base period
[22:26:27] <davidf> yes.
[22:26:38] <davidf> I had all that actually.
[22:26:59] <jmkasunich> (or split the difference - multiply the base period by 1.5 or so, that way you reduce the CPU load, and instead of going at 2/3 of the theoritical frequency you will only go at about 1/2
[22:27:06] <robin_sz> such a nice and complete explanation though ...
[22:27:21] <davidf> very, on both counts.
[22:28:25] <jmkasunich> of course, its still all speculation as far as why your machine stopped and whined at you
[22:28:25] <davidf> hence the suggestion of 16000 or 18000?
[22:28:25] <jmkasunich> yeah
[22:28:25] <davidf> Yes. That was really strange.
[22:28:27] <robin_sz> logger_aj, bookmark?
[22:28:27] <robin_sz> See
http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-08-27#T22-28-27
[22:28:44] <jmkasunich> question: were you doing _anything_ at all on the PC when it happened? moving the mouse? resizing a window?
[22:29:26] <davidf> nothing.
[22:29:31] <jmkasunich> darn
[22:29:44] <robin_sz> gah, why is the logger serving up ".bin" files all of a sudden?
[22:30:19] <jmkasunich> we've seen some graphics cards basically take over the PC for hundreds of microseconds, sometimes several milliseconds, when you do windowy stuff like resize or move a window
[22:30:41] <jmkasunich> usually not "cards" actually, graphics on the motherboard seem to be the worst for that
[22:30:55] <jmkasunich> the answer is to replace with a real graphics cards
[22:31:37] <davidf> Oh, hey...
[22:31:40] <davidf> I have the default screen saver thing that Brezzy ships with...
[22:31:51] <jmkasunich> the Mazak at the CNC workshop had onboard video with that problem - its a servo machine, so it didn't lose steps, but when you changed windows while the machine was moving, you could hear a clunk as it tried to stop for a few milliseconds
[22:31:56] <davidf> Could the timer for that be the prob?
[22:32:02] <jmkasunich> a $5 matrox video card fixed it
[22:32:14] <jmkasunich> did the screensaver kick in at that instant?
[22:32:37] <davidf> Unfortunately I wasn't looking at the screen.
[22:32:46] <jmkasunich> cradek also had a laptop that would have RT problems when the fan kicked on or off
[22:32:47] <davidf> Just the machine in dismay.
[22:33:00] <jmkasunich> are you using ubuntu?
[22:33:18] <jmkasunich> rtai has a "latency test" that can be used to see if your hardware does nasty stuff like that
[22:33:36] <davidf> This box has heat mgt I think. I notice the fan speeding up and slowing down occasionally.
[22:33:42] <davidf> Yes ubuntu.
[22:33:53] <jmkasunich> ok, I know the latency test is on there
[22:34:00] <jmkasunich> just have to figure out how to run it
[22:34:02] <robin_sz> * robin_sz preserves the discussion for posterity
[22:34:15] <robin_sz> never know, someone else may find it useful ...
[22:34:26] <jmkasunich> its just a program you run, let it go for hours if you want, and it records the worst case latency (delay) in executing RT code
[22:34:31] <davidf> I think cradek and I did that once.
[22:34:59] <davidf> Let it go awhile with no prob, but I had slower settings then
[22:35:01] <jmkasunich> the idea is to run it, then wiggle the mouse, click on windows, surf the web, let the screensaver do its thing, wait for the fan to come on, etc
[22:35:09] <davidf> BP = 50000 I think.
[22:35:15] <jmkasunich> the latency test has nothing to do with EMC's settings
[22:35:19] <davidf> ok.
[22:35:19] <robin_sz> indeed
[22:35:36] <jmkasunich> (although a small BP will make the system less tolerant of latency)
[22:35:55] <davidf> yeah, we did that
[22:36:12] <jmkasunich> the exact list of things that can cause RT problems is hard to define
[22:36:18] <robin_sz> heres an idea ....
[22:36:24] <robin_sz> try servos!
[22:36:27] <jmkasunich> I try to disable power management and such in the BIOS, but that may or may not actually matter
[22:36:58] <davidf> Servos would be real nice.
[22:37:05] <robin_sz> uh huh
[22:37:09] <jmkasunich> servos are fine if that is the class of machine you are building
[22:37:23] <jmkasunich> but the cheapest servo solution I know of (besides Jepler
[22:37:36] <jmkasunich> jepler's PWM servo) is $200 for the card
[22:37:52] <jmkasunich> davidf already has significant $ in the stepper drives
[22:37:56] <davidf> I'll try the 1000 uStep setting and scale = 20000
[22:37:59] <robin_sz> hes trying to get angular accuracies of .001 degree ....
[22:38:01] <davidf> big time.
[22:38:11] <davidf> $900.00 for 5.
[22:38:17] <robin_sz> ouch
[22:38:23] <jmkasunich> degrees? I thought we were talking about a linear axis here?
[22:38:56] <davidf> Not bad, retail = $5500.00 for 5.
[22:38:56] <robin_sz> on his rotary axis
[22:39:10] <jmkasunich> 0.001 degrees = 360000 steps/rev
[22:39:19] <davidf> no, not exactly.
[22:39:28] <jmkasunich> so uS the motors at 1000 steps/rev, and use a 360:1 worm gear
[22:40:00] <davidf> robin_sz, I have two separate machines.
[22:40:03] <robin_sz> I forget exactly what it was .. Il stop distracting ...
[22:40:06] <robin_sz> ahh.
[22:40:07] <davidf> mini lathe and mini mill.
[22:40:10] <robin_sz> that explains some of it
[22:40:27] <robin_sz> ill shut up ;)
[22:40:28] <davidf> The rotarty axis on the mill is a 72:1 table.
[22:40:34] <robin_sz> nice
[22:40:59] <davidf> The spindle on the lathe is just for utility, to roughly position stuff...
[22:41:01] <robin_sz> * robin_sz adds "rotarty" to his dictionary
[22:41:23] <jmkasunich> so with 1000/rev uStepping, and 72:1 you get 0.004 degrees/step
[22:41:28] <davidf> good. It's a very useful aberation to know.
[22:42:37] <jmkasunich> make that 0.005 degrees/step
[22:42:38] <robin_sz> + backlash
[22:42:38] <jmkasunich> (I should know better than to do math in my head)
[22:42:38] <robin_sz> + error in the worm drive
[22:42:38] <davidf> Actually I haven't yet retro'ed the rotary table for cnc.
[22:42:38] <robin_sz> + loads of other stuff
[22:42:38] <jmkasunich> robin_sz: all that goes without saying
[22:42:44] <davidf> Only if you don't say it. :)
[22:43:02] <jmkasunich> likewise, 40000 steps/inch is ridiculous for a linear axis using all-thread for a screw
[22:43:15] <davidf> ha.
[22:43:18] <robin_sz> jmkasunich, indeed, but you do have to sorta remember it ... otherwise its easy to believe you actually have that level of accuracy ...
[22:43:27] <robin_sz> exactly.
[22:43:28] <jmkasunich> when the real mechanical limitations are probably 0.001 or so
[22:43:40] <davidf> about right.
[22:44:02] <davidf> .001 - .0025 error in an inch
[22:44:17] <robin_sz> * robin_sz writes a bit more gibberish to try and sort out his tube cutter madness
[22:44:45] <davidf> The mill ships with those screws. I'll be replacing them with acme soon.
[22:45:25] <davidf> Other than that, it's a pretty nice tool though.
[22:45:46] <robin_sz> im accumulating my madness here
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?TubeCutter
[22:45:54] <robin_sz> keep the craziness in one place
[22:46:21] <davidf> jmkasunich, robin_sz Thanks for the help. You really dug in there & I appreciate it.
[22:47:12] <robin_sz> jmk did, i just talked crap
[22:47:17] <robin_sz> ;0
[22:47:31] <davidf> heh not really.
[22:47:44] <davidf> You're fun
[22:47:47] <robin_sz> hint: use ballscrews
[22:47:52] <jmkasunich> robin_sz: you kept me from going off into left field about base period and such
[22:47:57] <jmkasunich> scale was a good place to start
[22:48:02] <davidf> hint: buy them for me. :)
[22:48:33] <robin_sz> jmkasunich, its good to start with a fixed thing and then work back ...
[22:49:00] <robin_sz> if you shop around and do the ebay thing, you can get them at similar prices
[22:49:37] <davidf> similar to acme?
[22:50:34] <davidf> cradek mentioned $36.00 / 36"
[22:50:34] <robin_sz> jmkasunich, scale is fixed ... mostly. you can work back and see if its sensibly going to work with the processing power youhave, then if not work around again with different jumper settigns for ustep or whatever
[22:50:34] <davidf> Actually that's just what I did...
[22:50:34] <jmkasunich> robin_sz: replacing a 1/2" triangle screw on a minimill with ballscrews is a non-trivial mechanical project
[22:50:48] <jmkasunich> the ballnut is probably twice as large in diameter as the original nut
[22:50:57] <jmkasunich> and might need a _lot_ of work to fit it
[22:51:02] <davidf> Just didn't realize that I shouldn't work so close to the max vel
[22:51:07] <robin_sz> jmkasunich, sounds liek davidf has the gear to lathe it up ...
[22:51:23] <jmkasunich> if there isn't enough space on the casting tho...
[22:51:34] <robin_sz> on say, 12 or 16mm screw, the nuts are small enough
[22:51:36] <davidf> There's not.
[22:51:59] <davidf> 1/2 inch screw barely fits as it is.
[22:52:12] <robin_sz> coo
[22:52:23] <davidf> I think acme threads with adjustable nuts would be fine for me.
[22:53:20] <davidf> hmm, 12 mm ~ 1/2 inch, & how big are the nuts?
[22:54:18] <jmkasunich> I bet the nut is close to 1" over the ball return tube
[22:54:28] <robin_sz> around that
[22:55:30] <davidf> I might be able to fit that.
[22:55:46] <robin_sz> jmkasunich, any clues/suggestions for face selection on the tube cutter?
[22:56:01] <jmkasunich> not really
[22:56:13] <jmkasunich> my strength is in the low level stuff, I don't know much g-code at all
[22:56:16] <robin_sz> was thinking about hijacking the G54,55,56,57 commands ...
[22:56:43] <jmkasunich> you gonna use it for making fishmouths and such?
[22:56:55] <robin_sz> that sort of thing ...
[22:58:02] <jmkasunich> cutting around the corner will be fun
[22:58:02] <robin_sz> exactly ...
[22:58:02] <davidf> dare I ask what a fishmouth is, other than the obvios?
[22:58:02] <davidf> obvious?
[22:58:04] <robin_sz> a jopint between two bits of round pipe
[22:58:06] <jmkasunich> visualize a T fitting made of steel tubes
[22:58:17] <robin_sz> * robin_sz nods
[22:58:25] <jmkasunich> the center leg of the T needs to have a strange shape on the end to mate up to the crossbar
[22:58:29] <jmkasunich> thats a fishmouth
[22:58:39] <robin_sz> now visualise it with a non 90 degree angle ...
[22:58:50] <jmkasunich> and the two tubes not the same diameter
[22:58:53] <robin_sz> and different size tubes
[22:58:54] <jmkasunich> gets non-trivial fast
[22:59:02] <robin_sz> and not onthe centre line
[22:59:05] <davidf> mmm.
[23:00:16] <robin_sz> the generic case is rectangular tube, with radiused corners
[23:00:33] <robin_sz> square tube is just a special case of rectangular tube
[23:00:46] <jmkasunich> so is round ;-)
[23:00:50] <robin_sz> and round tube is just square tube with big radii :)
[23:01:01] <robin_sz> snap.
[23:01:16] <jmkasunich> ?
[23:01:40] <robin_sz> snap .. like the card game ...
[23:01:48] <robin_sz> we both said the same thing ...
[23:01:51] <robin_sz> ach, whatever
[23:01:52] <jmkasunich> oh
[23:01:54] <davidf> So, you can fit a square peg in a round hole, as long as the specs are right then.
[23:02:16] <jmkasunich> UK game maybe (or UK name for something that has a differnet name here)
[23:02:54] <robin_sz> childs card game, each turns up a card, if same value, you shout snap ... first to shout, gets the pile.
[23:03:05] <jmkasunich> would it be reasonable to put a probe on this machine?
[23:03:18] <robin_sz> not really. no need is there?
[23:04:08] <robin_sz> the tube size is known the rest is just maths
[23:04:08] <jmkasunich> assuming the size is _really_ known, and its centered in the machine
[23:04:08] <robin_sz> well yeah
[23:04:11] <robin_sz> its basically a 4 jaw roller chuck
[23:04:25] <jmkasunich> put the tube in, center Y, start probing while rotating A
[23:04:36] <jmkasunich> after one turn, you know everything there is to know about the tube shape
[23:04:46] <robin_sz> and the Z axis has capacitive height sensing too
[23:05:11] <jmkasunich> thats your probe
[23:05:30] <robin_sz> i think accuracy around the corners could be suspect
[23:05:30] <jmkasunich> configure Z to be a height tracker, rotate A
[23:05:47] <davidf> Thanks again guys. 'nite.
[23:05:51] <robin_sz> night
[23:05:54] <jmkasunich> goodnight
[23:06:48] <robin_sz> started building a frame for it .. got some rails for X, a 2m ballscrew and a pair of 3kw AC servos
[23:07:03] <robin_sz> one for X, the other for the rotational axis A
[23:07:06] <jmkasunich> how big is this gonna be?
[23:07:11] <jmkasunich> 2m X travel?
[23:07:16] <robin_sz> well, theres a thing ...
[23:07:23] <robin_sz> initially yes
[23:07:34] <robin_sz> but htats a bit too small to be useful
[23:07:46] <jmkasunich> I was thinking of cutting one end at a time
[23:07:47] <robin_sz> needs to be 6 or 7.5m really
[23:07:53] <robin_sz> so am i ...
[23:07:56] <jmkasunich> but I guess its usefull to be able to do both ends in one clamping
[23:08:00] <robin_sz> no no ...
[23:08:11] <robin_sz> think say, 300mm lengths ...
[23:08:35] <robin_sz> but you put the whole 7.5m slug in and it just chops and chops you a whole pile of them ...
[23:08:41] <robin_sz> then loads itself another length ...
[23:08:49] <jmkasunich> barrfeeder kind of
[23:08:55] <robin_sz> exactly
[23:09:08] <robin_sz> with the far end held in a 4 jaw chuck ...
[23:09:09] <jmkasunich> the travel really only needs to be longer than the longest part you intend to make tho
[23:09:21] <robin_sz> mmm ... possibly
[23:09:32] <robin_sz> that would mean clam and release ...
[23:09:35] <robin_sz> clamp
[23:10:14] <jmkasunich> you need to grab the stick in two places, right?
[23:10:26] <jmkasunich> other wise it will be too wobbly
[23:10:30] <robin_sz> the commercial designs have a huge long X axis ... clamp the tube at one end, fead it through a slaved secondary chuck just infront of the cutting head
[23:10:45] <robin_sz> the far end provides motion in X
[23:10:57] <robin_sz> the cuttign head just moves in Y and Z
[23:11:16] <jmkasunich> the secondary chuck provides support, but isn't so tight that the part can't slide thru it?
[23:11:24] <robin_sz> yeah ... rollers
[23:11:44] <robin_sz> wait .. theres a mpeg ... I thought I already bored you with it once ...
[23:11:48] <jmkasunich> not me
[23:11:53] <jmkasunich> probably bored somebody else
[23:12:00] <robin_sz> oh it is VERY kewl ... wait
[23:13:22] <jmkasunich> how is it loaded? seems the X rails would complicate things
[23:13:33] <jmkasunich> or is it end loaded thru the traveling chuck?
[23:15:00] <robin_sz> dang .. they have changed em to .wmv ... :(
[23:15:25] <jmkasunich> VLC can play some .wmv's but not all
[23:17:10] <robin_sz> wait .. yes
[23:17:15] <robin_sz> they do play on my linux machine ...
[23:17:17] <robin_sz> http://www.alspi.com/videos(tube).htm
[23:17:26] <robin_sz> look at the sqaure tube ones ...
[23:18:35] <robin_sz> the top one is best ...
[23:18:42] <robin_sz> thats exactly what I intend to be able to do
[23:19:31] <jmkasunich> slick
[23:19:35] <jmkasunich> is that actual speed?
[23:20:18] <davidf> jmkasunich, you still there?
[23:20:33] <robin_sz> yep
[23:20:37] <jmkasunich> bizzare, when I play it in VLC there are four windows with the same video
[23:20:44] <robin_sz> bizarre!
[23:20:48] <davidf> Hi
[23:21:03] <davidf> Just wanted to clear something up real quick...
[23:21:09] <jmkasunich> the main window, and three others with just the image
[23:21:12] <jmkasunich> shoot
[23:21:20] <robin_sz> http://www.nick-gmbh.de/detail/images/laser.jpg
[23:21:29] <robin_sz> ^^ the full size machine ...
[23:21:34] <davidf> Just went back & started editing the ini & saw input_scale = 40000 ...
[23:22:29] <davidf> & then realized the source of confusion earlier...
[23:22:29] <davidf> at 1 in/sec,
[23:22:29] <davidf> max vel in terms of steps is 40000 as well.
[23:22:29] <jmkasunich> ah, at 1".sec, scale and steps.sec are the same
[23:23:09] <davidf> Thats what I meant when I said max of 40000, I was talking about the max steps / second, & it happens to be the input_scale as well. :)
[23:23:44] <davidf> Then I got confused when you thought I was confused... well you get the idea...
[23:24:01] <robin_sz> jmkasunich, you see the coordinated Y, Z and A motion as it goes around a corner?
[23:24:31] <jmkasunich> yeah
[23:25:04] <davidf> anyway, that's what happened. thanks again for making the inner workings clearer for me that helps a lot.
[23:25:10] <davidf> 'nite again.
[23:25:17] <jmkasunich> night
[23:26:01] <robin_sz> ive bought a real nice slide and servo for the Y axis
[23:26:55] <robin_sz> http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&ih=002&item=120016762206
[23:27:33] <robin_sz> nice big heavy casting ...
[23:27:37] <jmkasunich> spiffy
[23:28:55] <robin_sz> thats should nicely carry the head for the acroos the tub motion ...
[23:28:55] <robin_sz> I think the ballscrews I have will be too slow for X
[23:29:03] <robin_sz> 4tpi ...
[23:30:46] <robin_sz> i think it will give some little used parts of EMC a workout anyway
[23:31:17] <robin_sz> it will beinteresting to see if it can keep the "cotnrolled poitn" at constant velocity on those combined moves ;)
[23:37:56] <jmkasunich> EMC has no clue about the radius from the corner of the tube to the center of the A axis
[23:38:06] <jmkasunich> you'll have to program that move using CAM or something
[23:39:09] <robin_sz> imgoing to embed that move in emc itself
[23:39:18] <jmkasunich> ?
[23:39:27] <robin_sz> tell the controller the tube dimensions ...
[23:39:37] <robin_sz> move to the start of the rad,
[23:39:46] <robin_sz> ask it to switch to the next face
[23:39:57] <robin_sz> it should track the corner as it moves A
[23:40:07] <jmkasunich> and how is it gonna do that?
[23:40:11] <robin_sz> and end up on the new face, on the edgeof the rad
[23:40:35] <robin_sz> well, you cant program it as Gxx moves from cam
[23:40:51] <robin_sz> because its not circular
[23:40:53] <jmkasunich> you can program anything as G01 moves if you use enough of em
[23:41:03] <robin_sz> well, you could
[23:41:12] <robin_sz> but thats not workable
[23:41:27] <jmkasunich> redesigning the TP and/or interp is?
[23:42:15] <robin_sz> its not that big a deal is it?
[23:42:23] <jmkasunich> lol
[23:42:44] <robin_sz> it just a question of spitting out new Z and Y values as A rotates
[23:43:03] <jmkasunich> emc _is_ the TP and interp - everything else is just window dressing and support code
[23:43:28] <jmkasunich> you gonna add a new canonical for that or what?
[23:43:35] <robin_sz> unsure
[23:43:46] <robin_sz> its a bit of a pain,
[23:44:00] <robin_sz> because it affects the Y values ...
[23:44:52] <robin_sz> the goal is to be able to write a program
[23:45:03] <robin_sz> and if say, the tube is 2mm smaller than it should be,
[23:45:21] <robin_sz> not have to re-write the program from scratch to make it work
[23:45:51] <jmkasunich> in the wiki page (which I've closed and I'm too lazy to find again) you mention the idea of unwrapping the part
[23:45:57] <robin_sz> yeah
[23:46:02] <jmkasunich> is that how you'd like to program it?
[23:46:07] <robin_sz> that was rejected
[23:46:16] <jmkasunich> why?
[23:46:24] <robin_sz> for the varying tube sizes reason
[23:46:38] <robin_sz> say the corner radii are different to what you hoped for ...
[23:46:50] <robin_sz> then the unwrapped version is fubarred
[23:46:59] <jmkasunich> I asked if that was how you'd like to program it - adapting that program to another tube side is a separate issue
[23:47:20] <robin_sz> hmmm
[23:47:21] <jmkasunich> what other way is there to program it? use different coordinate systems for each face or something?
[23:47:31] <robin_sz> something like that
[23:47:48] <robin_sz> I want to be able to say "hole this far from the centreline"
[23:47:52] <jmkasunich> that would limit you when you program a hole that spans two faces (wraps around the corner)
[23:48:09] <robin_sz> or "cut until this far from the edge/face"
[23:48:24] <jmkasunich> well, you have to pick one or the other for a datum
[23:48:49] <robin_sz> not really ...
[23:49:01] <robin_sz> if Y0 is always the centreline ...
[23:49:23] <robin_sz> and you put the Y value of the edge/face in ta variable ... #2001
[23:49:37] <robin_sz> then you can do it easy enough ...
[23:49:54] <jmkasunich> the variable would be set when the tube is loaded/measured?
[23:50:00] <robin_sz> right
[23:50:20] <jmkasunich> holes spanning a corner are still an issue
[23:50:34] <robin_sz> round holes?
[23:50:40] <jmkasunich> any holes
[23:50:44] <robin_sz> nah ...
[23:50:50] <robin_sz> G0 Y0
[23:50:54] <robin_sz> M3
[23:51:33] <robin_sz> G1 Y[#2001 - corner radius]
[23:51:47] <robin_sz> <select face 2>
[23:51:53] <robin_sz> G1 Y0
[23:52:23] <robin_sz> selecting face 2 causes A to rotate and Y and Z to track the corner
[23:52:38] <jmkasunich> so the part where you go around the corner needs to be normal to the axis of the tube
[23:52:56] <robin_sz> so far yes ...
[23:53:01] <jmkasunich> what if you want to v-notch a tube so you can bend it
[23:53:20] <robin_sz> hmmm
[23:53:23] <robin_sz> git ;)
[23:53:40] <jmkasunich> unrolling the tube (IMHO) is a better way to specify stuff
[23:53:48] <jmkasunich> just need to figure out how to correct for size
[23:54:04] <robin_sz> thanks .. that was actually a very good test case
[23:54:48] <jmkasunich> you can have #2001 be the center of face 1, #2002 the transition from face 1 to radius 1, #2003 the transition from ratius 1 to face 2, #2004 center of face 2, etc
[23:55:49] <robin_sz> and as you pass beyond #2002, it roates automagically?
[23:55:57] <jmkasunich> yeah
[23:55:58] <robin_sz> rotates
[23:56:00] <robin_sz> hmm
[23:56:04] <robin_sz> yeah .. ok.
[23:56:14] <robin_sz> one more thought for you ...
[23:56:24] <robin_sz> the special case of round tube
[23:56:26] <jmkasunich> angle is easy, just linear interpolate between #2002 and #2003
[23:56:58] <robin_sz> there are two ways to do a hole in round tube ...
[23:57:05] <jmkasunich> #2001 = #2002 = 0, #2003 = #2004 = pi/2 * tube radius
[23:57:17] <robin_sz> one, as if unwrapped and laid flat then bashed with a cookie cutter
[23:57:38] <robin_sz> the other, as if drilled through whilst still a tube ...
