#emc-devel | Logs for 2008-10-19

Back
[00:40:58] <cradek> BigJohnT: hi
[00:41:11] <BigJohnT> hi cradek
[00:41:35] <cradek> BigJohnT: I got a complaint about overly long messages on the list - would you be sure to trim unneeded stuff, especially when responding to john domville - his messages are really bad.
[00:41:38] <BigJohnT> watching the iditarod
[00:42:02] <BigJohnT> yea, I did a huge snip on the last one
[00:42:11] <cradek> cool, thanks.
[00:42:15] <cradek> what is iditarod?
[00:42:20] <BigJohnT> not sure what caused all the space
[00:42:44] <BigJohnT> dog sled race in Alaska
[00:42:53] <cradek> his steaming-pile of a mailreader I assume
[00:43:12] <cradek> "Microsoft Office Outlook 12.0"
[00:43:17] <BigJohnT> yea, it had tons of extra spaces
[00:43:26] <BigJohnT> just noticed it in the last reply
[00:44:57] <BigJohnT> long ago Nome Alaska was in a tight spot and the dog sled teams mushed 1000 miles to bring the needed medicine to save the town
[00:45:52] <cradek> wow
[00:46:10] <BigJohnT> being from Alaska (born on King Salmon Island) I'm interested in the race
[00:48:08] <BigJohnT> do you have any idea on when 2.2.7 might be released?
[00:48:44] <cradek> it's up to jepler, I haven't heard him say what his plans are
[00:49:03] <BigJohnT> ok, just wondering out loud
[00:49:28] <cradek> it has an important bugfix now - touch off of rotary axes on metric machines is wrong
[00:49:52] <BigJohnT> interesting my chevy Z71 will coast farther than the goldwing
[00:49:55] <cradek> personally I'm starting to feel ready for 2.3.0
[00:50:04] <cradek> BigJohnT: bike tires low?
[00:50:05] <BigJohnT> yea me too
[00:50:14] <BigJohnT> no I checked them
[00:50:27] <BigJohnT> I think it is the mass of the truck vs the windage
[00:50:54] <BigJohnT> the bike is 800 lbs the truck is what 3000 lbs
[00:51:01] <BigJohnT> gravity...
[00:54:17] <jmkasunich> drag to inertia ratio
[00:54:36] <BigJohnT> exactly
[00:55:50] <BigJohnT> kinda surprised me that my truck would coast 1.2 miles down a stretch of road and the bike only .75 miles
[00:56:23] <jmkasunich> I wonder what the weight per square foot of frontal area is for both vehicles
[00:57:20] <BigJohnT> I would think the truck is 3 or 4 times the bike in weight to frontal area
[00:59:33] <BigJohnT> I should ask Hawkins about gravity...
[01:10:01] <BigJohnT> anyhow I just want to make sure the docs are as up to date as possible before 2.2.7 is released
[01:35:26] <cradek> jmkasunich: did you see http://cvs.linuxcnc.org/cvs/emc2/src/emc/motion/command.c.diff?r1=1.113;r2=1.114
[01:35:37] <cradek> I think it was you who always complained about that stupid error
[01:36:00] <jmkasunich> I saw it
[01:36:11] <jmkasunich> I dunno if I "always" complained
[01:36:16] <jmkasunich> I bet I did at least once tho
[01:36:19] <cradek> ok maybe not
[01:36:56] <jmkasunich> I wish I knew which firefox update broke it
[01:37:07] <cradek> ?
[01:37:28] <jmkasunich> for the last month or more, whenever I click on a link in here (or in an email, or whatever), instead of starting FF and opening the page, it simply starts FF
[01:37:34] <jmkasunich> I have to click again to open the page
[01:37:38] <cradek> yeah that broke for me too
[01:37:42] <SWPadnos> what happens if you drag a link into FF?
[01:37:49] <cradek> some time ago it seems
[01:37:54] <jmkasunich> if FF is already open, it works fine
[01:38:04] <SWPadnos> I noticed a problem appear when I upgraded to 3.x
[01:38:27] <jmkasunich> I'm using 1.5.-.12eol
[01:38:43] <jmkasunich> I suppose that "eol" is their way of telling me to upgrade
[01:38:56] <jmkasunich> oops, 1.5.0.12eol
[01:38:57] <SWPadnos> 1.x is older than the hills
[01:39:03] <SWPadnos> (in internet time anyway)
[01:39:05] <cradek> 1.5.dfsg+1.5.0.15~prepatch080614e-0ubuntu3
[01:39:36] <jmkasunich> this is the one that came with 6.06 (and has been updated from the 6.06 repos)
[01:39:47] <cradek> same here
[01:40:43] <SWPadnos> ah. I'm on Windoes or 7.10 or 8.04
[01:40:47] <SWPadnos> windoesn't actually
[02:40:01] <cradek> I'M FREE!!! (...from calculating tool offsets)
[02:40:14] <cradek> this is SO cool
[02:40:20] <SWPadnos> heh
[02:44:30] <cradek> the gui is great. I thought it would have to be more complicated, but to the user it's exactly like touch off. the user wants to change the tool table such that the dro becomes a certain thing.
[02:45:25] <SWPadnos> oh, did you write a tool table GUI? thingie?
[02:45:37] <cradek> no, it works just like touch off
[02:45:46] <cradek> instead of changing the coordinate system, you can change the tool table
[02:46:02] <SWPadnos> ok. I believe I'm lost, but good deal! :)
[02:46:45] <cradek> say you zeroed any old active system to the top of your vise. load a tool, move Z so you can just roll a .5 dowel pin under it, touch off Z, pick tool table on the menu, enter 0.5
[02:47:00] <SWPadnos> oh, cool
[02:47:01] <cradek> it write the tool table entry and the gui shows Z=0.5
[02:47:31] <SWPadnos> ok, so "tool table" is now one of the coordinate systems you can touch off - nice!
[02:47:35] <cradek> yes
[02:47:46] <cradek> it does a somewhat different thing, but the user interacts with it the same way
[02:48:11] <SWPadnos> right, that's nice
[02:48:18] <cradek> wheeee
[02:48:23] <cradek> this kicks butt
[02:48:35] <cradek> the things I think BOSS does better are quickly running out
[02:48:39] <cradek> quickly
[02:48:47] <SWPadnos> great
[02:48:53] <jmkasunich> * jmkasunich doesn't follow, but I guess I should update and try it instead of asking stupid questions
[02:49:22] <jmkasunich> cradek: did you see earlier where swp said he'd do his bport retrofit before I get my gantry built?
[02:49:31] <cradek> ha
[02:49:33] <SWPadnos> I think I asked if I should ;)
[02:49:38] <jmkasunich> what about you?
[02:49:41] <cradek> the question in my mind is when will I do mine?
[02:50:44] <cradek> I'll start mine the minute it stops working, or maybe sooner
[02:51:59] <cradek> jmkasunich: if you can design and build an entire machine faster, that's pretty sad for us
[02:52:46] <jmkasunich> exactly
[02:53:13] <jmkasunich> I got rails and a screw today
[02:53:16] <jmkasunich> one more tiny step
[02:55:44] <jmkasunich> so does this new feature that you wrote add "tool offset" to the list of coordinate systems that you can select when you hit the touch-off button? or does it add another top level button?
[03:00:52] <cradek> adds it to the touch off screen
[03:01:02] <cradek> (when it's appropriate)
[03:01:17] <jmkasunich> meaning whenever tool length offset is in effect?
[03:01:30] <cradek> = when a tool is loaded, and you're touching off an axis that makes sense for TLO
[03:01:50] <cradek> the TLO does not have to be in effect, but after you do the touch off, it will be
[03:01:56] <SWPadnos> ok, so it always operates on "the current tool number"
[03:02:06] <jmkasunich> tool is loaded, meaning TnM6? or lengths in effect meaning you issued G43?
[03:02:15] <cradek> TnM6
[03:02:35] <cradek> SWPadnos: I don't know what it should do in the T1M6 G43H2 case
[03:02:35] <jmkasunich> so people who use G43 without M6 won't see this
[03:02:44] <cradek> I know what it *does*, but not what it should do
[03:02:47] <SWPadnos> heh
[03:02:54] <SWPadnos> yeah, that's a tough one
[03:02:57] <cradek> jmkasunich: that's true.
[03:03:27] <jmkasunich> right now, the offsets come only from G43
[03:03:33] <cradek> jmkasunich: I don't see why you would use G43 without M6
[03:03:43] <cradek> (note I'm not saying nobody does)
[03:03:56] <jmkasunich> I do, but I probably shouldn;t
[03:04:00] <jmkasunich> I write things like:
[03:04:11] <jmkasunich> (MSG load 5/16" endmill)
[03:04:12] <jmkasunich> M0
[03:04:20] <jmkasunich> G43 Hwhatever is that endmill
[03:04:35] <cradek> why not use hal_manualtoolchange?
[03:04:45] <jmkasunich> I should probably be doing that
[03:05:03] <cradek> then you can just write Twhatever M6 G43 (5/16 whatever)
[03:05:04] <jmkasunich> but I don't think it can tell me "load 5/16 endmill", it will just say load too N
[03:05:28] <cradek> oh I guess I just look at the gcode display - that line or one near it will be highlighted.
[03:05:44] <jmkasunich> I write code for stupid operators
[03:05:46] <cradek> I mean to see a comment that describes the tool
[03:06:04] <SWPadnos> is there a comment field in the tool table?
[03:06:20] <jmkasunich> yes
[03:06:31] <jmkasunich> but passing it to halmanualtoolchange would be a challenge
[03:06:33] <SWPadnos> I wonder if hal_manualtoolchange can display that
[03:06:36] <SWPadnos> yes
[03:06:36] <cradek> you can put whatever you want after the useful numbers, but if emc writes the tool table, they are gone
[03:06:44] <jmkasunich> eww
[03:06:45] <SWPadnos> oh
[03:07:03] <jmkasunich> oh, we digressed - my other question about this functionality
[03:07:11] <cradek> that could use improvement (including showing the tool description on the screen, etc)
[03:07:20] <jmkasunich> you hit touch-off, select "tool offset" instead of G54, etc, enter a number, and hit return
[03:07:46] <jmkasunich> does that immediately get written to the tool table and the dro goes to the desired value, or do you have to take some other actiona
[03:07:56] <cradek> immediately
[03:07:59] <jmkasunich> ok
[03:08:07] <KimK_IA> cradek: Thanks, that's a great feature. And would entering 2.0 be in-range if using one of those 2" light-up height setters? http://www1.mscdirect.com/CGI/NNSRIT?PMPXNO=1757370&PMT4NO=52060023
[03:08:11] <jmkasunich> your first description a few mins ago make me think otherwise
[03:08:12] <cradek> tool table is written, new offset is loaded
[03:08:20] <cradek> KimK_IA: sure, any number
[03:08:39] <cradek> actually any gcode expression. you could enter atan[2]/[3] if you want
[03:09:18] <cradek> on the lathe I often enter something like 2.7532/2
[03:09:26] <cradek> ... because I measured a diameter of 2.7532
[03:09:36] <jmkasunich> I have to remember that
[03:09:59] <jmkasunich> I'm often walking over to the other computer to calculate measured diameter / 2 + dowel pin diameter
[03:10:12] <cradek> it says "= 1.3766" at the bottom of the screen
[03:10:48] <cradek> then you hit OK and the DRO will say X: 1.3766 DIA: 2.7532
[03:11:35] <cradek> KimK_IA: I'd save my $127 and use a dowel pin, I bet it's just as fast
[03:12:01] <cradek> lift slowly with the jogwheel until the dowel slips under the tool, you're done
[03:12:08] <jmkasunich> the only way the electronic thing is a win is if you can park it in the corner of the table and wire it to EMC
[03:12:26] <cradek> !!!
[03:12:31] <jmkasunich> then you load a tool and run a subroutine that goes over there and sets the length automatically
[03:12:34] <cradek> now you can write gcode to measure all the tools in the turret
[03:12:41] <cradek> ... and write the tool table
[03:12:46] <cradek> dang, that's cool
[03:13:01] <jmkasunich> how would you do that on the lathe?
[03:13:09] <cradek> not so easily
[03:13:28] <cradek> renishaw makes a thing that mounts to the lathe and swings down where the tools can poke it from several directions
[03:13:29] <jmkasunich> when you said turret I thought you were talking lathe
[03:13:34] <cradek> of course it costs a billion dollars
[03:13:47] <cradek> maybe two billion - I didn't look too close
[03:14:08] <cradek> I actually meant a mill with a tool changer, but same idea
[03:14:11] <KimK_IA> The little tip on the top of the thing has about 0.1" of give after the light comes on.
[03:14:36] <cradek> KimK_IA: I've seem a similar thing with a dial instead of a light
[03:15:11] <jmkasunich> so for a machine like the mazak, if you mounted the widget on the table at a certain spot, you could run "set_tool_len.ngc" and it would cycle thru the entire toolchanger setting all of the lengths
[03:15:12] <cradek> but, I still think the dowel is probably just as fast
[03:15:19] <cradek> jmkasunich: yes
[03:15:25] <cradek> jmkasunich: wouldn't that be slick?
[03:15:47] <jmkasunich> yeah
[03:15:51] <SWPadnos> the doodad is safer for the operator
[03:16:19] <SWPadnos> dowels have to be rolled around near the tool tip while the servos are active
[03:16:34] <KimK_IA> Might take a trick or two for hollow tools (no center) like shell mills, boring bars, etc, but very doable.
[03:16:39] <SWPadnos> (also hard with big-ass tools like the Maxak could have)
[03:16:43] <jmkasunich> it obviously depends on the class of machine
[03:16:43] <SWPadnos> Mazak
[03:17:20] <cradek> KimK_IA: yeah some tools are very hard to measure in the machine...
[03:17:30] <KimK_IA> you mentioned Boss, Dynapath/Autocon has that feature too. Also, entering .001/ will increment the current offset value by .001
[03:18:06] <cradek> BOSS is very basic, it has a TLO=Z button. there are no work offsets, so it's easy
[03:19:08] <KimK_IA> current offset value = whatever value you are *specifically* pointing at in the tool table, it doesn't assume anything based on currently active offsets/fixtures, etc
[03:19:12] <cradek> you can go edit the numbers manually too, but I rarely do
[03:21:51] <KimK_IA> The only way Dynapath edits their offsets (manual or auto) is by what tool table entry the operator is pointing at when he says "enter", no assumptions are made
[03:22:28] <cradek> SWPadnos: I see the stat buffer doesn't tell you which offset is loaded, only the interpreter knows
[03:22:46] <SWPadnos> you mean from which "slot" the offset comes?
[03:23:00] <cradek> well it may not have even come from a slot
[03:23:04] <SWPadnos> right
[03:23:05] <cradek> recall G43.1
[03:23:12] <SWPadnos> yeah, it's an interpreter thing
[03:23:21] <cradek> the interp knows that (G43.1 is slot -1 I think) but nothing else knows
[03:23:49] <cradek> so if it should be smarter, we'd have to do some stuff.
[03:24:16] <SWPadnos> I recall some discussions about whether tool comp belongs in the interp or CANON or wherevere
[03:24:18] <SWPadnos> -e
[03:24:27] <cradek> this is a sure case of 'make the general case easy'
[03:24:40] <cradek> you can always edit the tool table and then file/load tool table
[03:33:00] <jmkasunich> its funny how messing with vismach makes me think I know a bit of python
[03:33:10] <jmkasunich> till I actually try to _program_ something
[03:33:35] <jmkasunich> I want to write a loop to put 12 boxes in a collection
[03:33:41] <jmkasunich> instead of:
[03:33:45] <jmkasunich> Collection ([
[03:33:49] <jmkasunich> Box (blah),
[03:33:54] <jmkasunich> Box (blah),
[03:33:58] <jmkasunich> more
[03:34:02] <jmkasunich> ])
[03:34:33] <jmkasunich> actually, it would be "foo = Collection([" and so on
[03:35:21] <jmkasunich> so, with a loop, do I do something like "foo = Collection([ foo, Box(blah))" inside the loop to add each new box?
[03:39:00] <jmkasunich> ah, I think I want to build a list of Boxes, then stuff that in the collection
[03:45:10] <KimK_IA> jmkasunich, cradek, jepler: would you guys consider giving a seminar on how to use vismach at next year's CNC workshop?
[03:45:51] <jmkasunich> not sure if a seminar is the right way, but I'd be happy to do one-on-one
[03:48:13] <KimK_IA> Many of us have seen your cool art and animations and have absolutely no clue how to do that, even just making a simple groove in a block or something
[03:49:00] <jmkasunich> a lot of it depends on the ability to visualise geometry
[03:49:11] <jmkasunich> vismach models are made by adding together simple shapes
[03:49:18] <jmkasunich> mostly boxes and cylinders
[03:49:37] <jmkasunich> to make a block with a groove in it, you use three boxes
[03:49:45] <jmkasunich> one is the portion of the block under the groove
[03:49:54] <jmkasunich> the other two are the portions on each side of the groove
[03:50:29] <KimK_IA> can you subtract? that would only need two boxes.
[03:50:38] <jmkasunich> nope
[03:51:06] <jmkasunich> that is a real weakness of vismach, but its inherent in the openGL methods used to do the rendering
[03:51:32] <jmkasunich> since you can't subtract, you can't make something like a round bottomed groove, or drill a hole in a box, etc
[03:52:25] <jmkasunich> povray can do subtraction (they call it either intersection or difference), but it is much slower - no way to do realtime panning, zooming, etc, or to make parts of the object move in response to HAL pins
[03:52:53] <SWPadnos> there's got to be some GL meshing tool that will let you use CSG
[03:53:07] <KimK_IA> Wow. So that cool 5-axis-ball animation was built "backwards"(?) (ball and chips coming together to form a cube) and then shown "forwards(?)" (cube coming apart to form chips and ball)?
[03:53:24] <jmkasunich> the yellow one?
[03:53:30] <SWPadnos> that was POVRAY
[03:53:33] <KimK_IA> I think so
[03:53:33] <jmkasunich> right
[03:53:38] <jmkasunich> the yellow one was povray
[03:53:40] <SWPadnos> which can do CSG I think
[03:53:52] <jmkasunich> subtrecting the tool shape from the blank
[03:53:57] <jmkasunich> subtracting
[03:54:16] <KimK_IA> Oh, so POVRAY can subtract, then?
[03:54:22] <jmkasunich> frame 1: calculate initial tool location, subtract from blank
[03:54:46] <jmkasunich> frame 2: calculate tool location a second later, and subtract both tool shapes (1 and 2) from blank
[03:54:53] <SWPadnos> POVRAY can do a lot, but it can't animate (unless you want a 50x50 pixel image)
[03:54:58] <jmkasunich> frame 3, subtract 3 tool locations from blank
[03:55:13] <jmkasunich> each frame took povray a minute or two to render
[03:55:21] <jmkasunich> then they were stuck together to make the video
[03:55:31] <jmkasunich> there is a couple _days_ of rendering time in that video
[03:56:24] <jmkasunich> povray can subtract, add, rotate, and do all kinds of neat stuff - its a very cool program
[03:56:41] <jmkasunich> www.povray.org
[03:57:06] <jmkasunich> some people have WAY too much time on their hands
[03:57:07] <jmkasunich> http://hof.povray.org/office-13.html
[03:57:53] <SWPadnos> damn
[03:58:58] <KimK_IA> that's amazing
[03:59:01] <jmkasunich> there's even smoke rising from the cigarette in the ashtray (front desk)
[03:59:29] <KimK_IA> Ha. Must be a european office?
[03:59:32] <jmkasunich> plants, crumpled paper on the floor
[03:59:43] <KimK_IA> or asian?
[04:00:20] <SWPadnos> http://hof.povray.org/
[04:00:34] <KimK_IA> Now we need to do a time-lapse with the sun moving the blind shadows
[04:02:09] <jmkasunich> cool, the bonsai uses only POV's language, and the source (zipped) is 34K
[04:02:22] <jmkasunich> no imagemaps or other bulky stuff
[04:03:21] <fenn> jmkasunich: http://www.oyonale.com/image.php?lang=en&code=505
[04:04:09] <fenn> wow pov has sure come along since i last looked
[04:06:37] <jmkasunich> Approximately 370 millions of polygons are present in this image. In spite of the radiosity and the area lights, it rendered rather quickly at 6000 x 8000, in a couple of days
[04:07:23] <jmkasunich> POVray is the reason I got a 387 coprocessor for my old 386 computer
[04:08:20] <SWPadnos> yep. PORay and fractint were the coolest things around at the time :)
[04:08:27] <SWPadnos> +V
[04:11:31] <KimK_IA> Reminds me of that classic Dilbert... Dogbert: The company has decided that you only need a 286. Besides, how many times in your life are you going to do a 3-D rendering? Dilbert: Once, if I hurry.
[04:12:37] <SWPadnos> heh
[04:19:11] <jmkasunich> got my loop working, my boring machine table now has 6 t-slots
[04:21:16] <jmkasunich> and on that note, bedtime
[04:21:18] <jmkasunich> goodnight
[04:21:37] <SWPadnos> good idea. night
[04:27:22] <KimK_IA> goodnight. Thanks.
[16:26:47] <jmkasunich> jepler: how difficult would it be to make stepconf use non-doublestep, either by checking (or unchecking) a box, or automatically for step lengths greater than some threshold?
[16:28:30] <jepler> jmkasunich: I've held off on doing it because I fear I'll introduce bugs
[16:28:43] <jepler> If I did it, I'd do it automatically
[16:28:43] <jmkasunich> ah
[16:29:27] <jmkasunich> I just noticed an email from someone who got stung by that, and someone else who managed to figure out how to make it work (perhaps without actually knowing why)
[16:29:34] <jepler> probably I do need to do it
[16:30:10] <jepler> if(port->reset_time > period/4) port->reset_time = period/4;
[16:30:26] <jmkasunich> IMO that is a bug
[16:30:27] <jepler> ^^^ I think this accounts for the reason that a fairly short maximum was seen for reset-time
[16:30:27] <cradek> did we ever get a clear report of what numbers are wrong in the sherline timing defaults?
[16:30:40] <jepler> cradek: no, I looked but didn't find any real timing numbers
[16:30:43] <jmkasunich> cradek: I don't think so
[16:30:56] <jmkasunich> jepler: that line silently violates the timing the user requested
[16:30:58] <jepler> step space/length 22/22, direction hold/setup even bigger
[16:30:59] <cradek> phooey
[16:31:12] <jepler> is what I saw in emc1 configurations
[16:31:23] <jepler> jmkasunich: yeah it does
[16:31:30] <jepler> I expected values like 1us, not like 22us
[16:33:34] <jmkasunich> quick "fix", that line should say "Sorry Dave, I'm afraid I can't do that" and bail
[16:40:40] <jmkasunich> btw, I do think that period/4 is a good choice for the upper limit of busywaiting
[16:44:25] <jepler> yeah
[16:44:33] <jepler> it saves me having to figure out the cut-off in stepconf, I can just use that one.
[16:45:28] <jmkasunich> oh
[16:45:38] <jmkasunich> I totally misinterpreted that line you pasted
[16:45:47] <jmkasunich> I thought it was IN stepconf
[16:45:52] <jmkasunich> its in parport, right?
[16:46:28] <jmkasunich> if it is in parport, then it is most emphatically NOT a bug
[16:46:55] <jepler> that's a line from hal_parport
[16:46:59] <jmkasunich> duh
[16:47:26] <jmkasunich> I should have realise that is was C, not python
[16:47:32] <jepler> no big deal
[16:48:03] <jmkasunich> I'll be awake later ;-)
[16:50:49] <alex_joni> ah, that's no fun :)
[16:51:41] <jmkasunich> I think I need to buy more memory for this PC, and set up a few more VMs
[16:52:03] <jmkasunich> I had my dapper desktop running for the last month or so, so the dapper farm slot would get updated
[16:52:17] <jmkasunich> and I've had the shoptask computer on 24/7 for about the same time
[16:52:25] <jmkasunich> it made a noticable difference in electrical usage
[16:53:05] <jmkasunich> we should have an 8.04 farm slot anyway
[17:04:13] <jmkasunich> jepler: you just changed the default for the inputs to be unused instead of limit... is that in response to the various folks who have been unable to figure that out?
[17:09:03] <alex_joni> sounds like a good change
[17:09:29] <jmkasunich> agreed
[17:09:47] <jmkasunich> I just didn't expect to see that in a commit fixing something else
[17:25:14] <cradek> ybin: Blessing /dev/hda2 with Holy Penguin Pee...
[17:25:46] <jmkasunich> ?
[17:26:23] <cradek> that was my feeling too
[17:26:33] <cradek> the mac bootloader prints that
[17:26:47] <jmkasunich> http://www.jargondb.org/glossary/holy-penguin-pee
[17:34:06] <jmkasunich> cradek: http://farm1.static.flickr.com/123/416272313_1a953b94b4.jpg?v=0
[17:34:24] <jmkasunich> note the gray penguin on the right edge
[17:34:35] <jmkasunich> and what he is doing
[17:58:29] <skunkworks> jmkasunich: the logic seems to work on the h-bridge. So far :)
[17:59:25] <skunkworks> I hope to hook it to 'real' pwm and play with it today. (pluto) and higher voltage than I have been testing 50v vs 20. Baby steps. ;)
[18:03:31] <skunkworks> don't know if you saw this http://www.youtube.com/watch?v=eUmFKOVepYY
[19:16:40] <jepler> jmkasunich: yeah that also seems to be a common problem
[19:50:49] <jmkasunich> skunkworks: yeah, I saw the vid
[19:51:22] <jmkasunich> was that halscope on the screen?
[19:51:32] <jmkasunich> I'm not used to it refreshing that quick
[19:52:04] <cradek> roll mode in the base thread, I bet
[19:55:03] <jmkasunich> jepler: you said "that also seems to be a common problem", but I can't tell what you were responding to?
[19:55:40] <jepler> jmkasunich: the home switch thing
[19:56:12] <jmkasunich> ah, right
[19:56:40] <jmkasunich> an hour at the dogpark is good for forgetting what I was talking about ;-)
[19:57:03] <cradek> jepler: should we do anything about tool table comments, and if so, what?
[19:57:19] <jepler> cradek: beats me
[19:58:23] <cradek> if I add them to CANON_TOOL_TABLE it will be a lot bigger (will probably have to enlarge the nml buffer again)
[19:58:30] <jepler> yeah
[19:58:52] <jepler> let's let it suck for now
[19:59:02] <cradek> also I can't quite figure out how you say "the rest of the line" in scanf
[20:00:06] <jepler> %[^\n] ?
[20:00:45] <cradek> I could keep them, but not make them available to emc
[20:00:55] <cradek> wonder if that would be a useful halfway solution
[20:01:09] <jmkasunich> sure
[20:01:18] <cradek> let me see if I can pull that off
[20:01:20] <jmkasunich> they are for the benefit of a human editing the file (IMO)
[20:01:39] <cradek> true, but ideally the gui would show them somehow
[20:02:25] <jmkasunich> I'm trying to remember (cause that machine is powered off at the moment), but I think my shoptask not only has per-tool comments, it has a block at the front
[20:02:43] <jmkasunich> reminding me that my zero-reference point is 4" from the spindle nose gage line
[20:02:45] <cradek> lines that don't parse right are just skipped over
[20:02:57] <cradek> ... but they won't be preserved
[20:02:57] <jmkasunich> and preserved when re-writing?
[20:03:07] <cradek> no
[20:03:50] <jmkasunich> oh well
[20:04:03] <jmkasunich> if I start using that feature, I'll probably stop doing the 4" thing anyway
[20:04:15] <jmkasunich> that is mostly for offline tool measurement
[20:04:36] <jmkasunich> oh, I just remembered something I wanted to ask you yesterday about this
[20:04:52] <cradek> it will still work fine if your tools are shorter than your reference tool
[20:04:58] <jmkasunich> for lathes, you've said that you need to use touch-off with care to avoid breaking CSS
[20:05:02] <cradek> you'll get those correct negative numbers
[20:05:06] <jmkasunich> thats good
[20:06:03] <jmkasunich> I guess with a lathe, offsetting coordinate systems (in X) doesn't make a whole lot of sense
[20:06:12] <cradek> I agree
[20:06:27] <cradek> I don't really know what that would mean
[20:07:34] <jmkasunich> well, on my lathe, the toolpost is in a different place every time I mount it
[20:07:55] <jmkasunich> I can either set offsets to zero, then touch off each tool (setting tool offset, not coord offset)
[20:07:56] <cradek> you really want this new feature then
[20:08:17] <jmkasunich> or I can set a single offset that (hopefully) will correct for the new tool positions for _all_ my tools
[20:08:30] <jmkasunich> correct for the new toolPOST position I mean
[20:08:57] <cradek> I think if you don't care about css, that would work fine
[20:09:05] <jmkasunich> but not for CSS, right?
[20:09:10] <cradek> right
[20:09:57] <cradek> a couple holes and dowel pins will fix your problem...
[20:10:19] <jmkasunich> assuming that I always want the toolpost in the same place
[20:10:46] <jmkasunich> it can mount in either of two t-slots (Z) and sometimes there are good reasons to switch
[20:10:53] <cradek> dang.
[20:11:08] <cradek> if the two positions have the same X, you're still ok though
[20:11:12] <jmkasunich> right
[20:12:01] <cradek> I don't remember why css is the way it is - maybe you could fix it to work with g5x.
[20:15:00] <jmkasunich> maybe
[20:15:16] <jmkasunich> if that happens it will be after I have variable speed on my spindle
[20:15:21] <jmkasunich> which is about 4 projects from nwo
[20:15:22] <jmkasunich> now
[20:15:47] <cradek> if you have good homing, good toolpost locating is something you really will want anyway
[20:16:41] <jmkasunich> yeah, I need to figure out how to do that
[20:17:01] <jmkasunich> dowel pins and holes in the table aren't swarf friendly, but there is probably a way
[20:22:22] <jmkasunich> bbl
[20:45:13] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/iotask/ioControl.cc: preserve comments that have been manually added to the tool table