#emc | Logs for 2011-02-01

Back
[00:00:26] <stuste1> If you have a 90 degree head in the spindle then the TOV is not 0,0,1. It is now 1,0,0 or 0,1,0. Your tool length offset MAY need to be along the current TOV.
[00:00:49] <toast> what?
[00:00:51] <SWPadnos> yep. I see that as separate from G17/18/19
[00:01:19] <crotchetyGuy> Hi stuste1- is this strictly for multi-axis?
[00:01:19] <toast> my co-worker used to work with machines that had a horizontal and vertical mode, and he always talked about making sure the machine was set to the right plane
[00:01:37] <toast> because you just can't predict what the user wants to do, so you have to leave it to the user to do it how they want
[00:02:20] <stuste1> that is why I would like to have a separate method of designating the tool axis offset vector.
[00:02:41] <stuste1> the machine you talk about was probably a Maho or a Deckel
[00:03:08] <toast> i'm still lost, does EMC change the tool vector in it's present mode?
[00:03:14] <stuste1> no
[00:03:34] <toast> where do arc planes come into things?
[00:03:38] <toast> *then
[00:04:55] <toast> i'm just trying to understand where the spindle orientation change and the arc plane thing come together
[00:04:57] <stuste1> as I mentioned. Do you want to mill a radius on the top edge of a wall? You can use G18/G19 and a ball/bull mill to cut a radius on the top edge of the wall
[00:05:31] <toast> right, that's standard
[00:05:50] <SWPadnos> the discussion is about some proposed additions to EMC
[00:06:03] <SWPadnos> not existing behavior
[00:06:04] <stuste1> This dialog comes from me desire to have 5 axis tool length compensation for some machines I want to put EMC on.
[00:06:34] <stuste1> not additions Steve 'enhancements'
[00:06:48] <toast> oh, i see
[00:07:11] <stuste1> I also want 5 axis tool diameter compensation
[00:07:54] <toast> and you'd like the planes to travel around with respect to the spindle?
[00:08:33] <stuste1> no, not in the G68 manner
[00:08:54] <stuste1> the discussion about planes was from my explanation of what I want
[00:09:57] <stuste1> there is nothing like asking for the world
[00:12:18] <crotchetyGuy> stuste1: each machine/control combo would have to calculate each new position on the fly, correct?
[00:12:28] <stuste1> yes
[00:12:50] <stuste1> doesn't it already?
[00:13:03] <crotchetyGuy> I'm not a emc guru-
[00:13:38] <crotchetyGuy> just interesting for me because it is related to 5/axis post-processing type stuff.
[00:13:41] <stuste1> I am not either. If I was I wouldn't ask for help to do this. It would already be done.8-)
[00:14:33] <crotchetyGuy> output of cam programs are tool position and tool vector, then the post figures out final position.
[00:14:47] <crotchetyGuy> no way to comp, unless the control handles it.
[00:14:56] <stuste1> yes that is correct
[00:15:29] <crotchetyGuy> I do some 4th axis work, and no comp is a pain. Don't know how common it is on commercial controls.
[00:15:33] <stuste1> that is why I would like tool length compensation. I don't want to have to post the program again when I replace a worn cutter.
[00:16:02] <stuste1> Most current controls have 5 axis tool length compensation
[00:16:23] <stuste1> Some even have 5 axis cutter diameter compensation
[00:16:54] <crotchetyGuy> I would think the math to be fairly straight-forward, (for length anyway, don't know about diameter)
[00:17:16] <stuste1> 5 axis cutter diameter compensation is much more complicated. Not necessarily for the control but for the programmer/operator to use correct.y.
[00:17:39] <crotchetyGuy> can you explain that?
[00:17:40] <stuste1> The math is more complicated but not impossible
[00:18:59] <tomp> i tried the xmpl of userspace comps on page 91 of Integrators Manual version June 2007. blows up because i copied it. It contains weird chars for the 'right tick/apostrophe', use the standard single quote instead ( pdf shows h[’out’] = h[’in’] use h['out'] = h['in'] instead )
[00:20:21] <stuste1> It shouldn't be any more complicated. Everyone tries to make it more complicated than it is. It should work just the same as 3 axis cutter diameter compensation.
[00:21:59] <toast> just "stay left of this 3d curve?"
[00:22:03] <crotchetyGuy> I understand the math to the z - value compensation.
[00:22:04] <toast> or "stay right of this 3d curve?"
[00:22:39] <crotchetyGuy> cutter comp in 2d is not as straight-forward as height comp
[00:22:51] <toast> cutter comp in 3d hurts my brain
[00:22:57] <stuste1> Read my last three posts to the users list. I try to explain what I want and why.
[00:24:46] <toast> well i certainly don't subscribe to the user list
[00:24:53] <toast> not that i'm a programmer either
[00:25:07] <toast> i'm just concerned that what you want isn't necessarily the issue
[00:25:13] <toast> that would concern the programmers
[00:25:20] <toast> rather than the things involved in implementing it
[00:25:33] <stuste1> You can 'stay left/right of this 3d curve' in a cam package. The machine tool control (EMC) does not have the curve geometry in it.
[00:26:12] <stuste1> The 5 axis program is just linear moves with the format X Y Z A B
[00:26:37] <stuste1> why don't you subscribe to the list?
[00:26:41] <toast> because i don't use emc
[00:27:05] <Ziegler> BLASPHEMY
[00:27:17] <toast> tru!
[00:27:51] <toast> i'm just trying to figure out how cutter comp would work
[00:27:51] <stuste1> Why would you think that what I want is not the issue?:)
[00:27:55] <toast> mathematically
[00:28:04] <toast> for something that shifts the tool vector
[00:28:47] <toast_> whoops
[00:31:38] <crotchetyGuy> the math to the z comp issue is straight-forward. Just multiply the correct matrix to the commanded position.
[00:31:38] <stuste1> just like the cutter compensation on a three axis mill. You would use three programmed points (and their vectors) to determine the direction and amount of axis position modification.
[00:32:02] <crotchetyGuy> tool comp then changes the matrix, not just a z register
[00:32:21] <stuste1> yes - my proposal exactly
[00:33:17] <stuste1> this would would work directly for tool length compensation
[00:33:40] <stuste1> diameter comp would take more math before the matrix was calculated
[00:35:00] <crotchetyGuy> multi-axis is relatively rare in commercial, and near non existant in the hobby world where emc seems dominant, so getting it might take a wait, I'm guessing.
[00:35:48] <crotchetyGuy> cradek has multi-axis on the horizon, so maybe all is not lost.
[00:36:07] <toast_> it would be cool if someone wanted to implement the lathe canned cycles =(
[00:36:16] <stuste1> I can understand not subscribing to the users list. This is the first time I have spent much time on the IRC.
[00:36:37] <cradek> crotchetyGuy: you can see a very far horizon from here
[00:37:03] <cradek> (emc doesn't even run that mill yet)
[00:37:49] <stuste1> Multi-axis is not rare anymore. There are many, not just aerospace, companies with multi-axis machines. This could also work well on multi-axis lathes.
[00:37:49] <crotchetyGuy> hey stuste1- aren't you the apt programmer that contacted me long ago?
[00:38:14] <stuste1> It is very possible. Why did I contact you?
[00:38:45] <crotchetyGuy> I am part of an open source apt project.
[00:38:48] <stuste1> If I can influence the horizon any it will be a near horizon
[00:39:00] <toast_> multi-axis is common in trade rags, aerospace, medical, and automotive
[00:39:11] <toast_> but in the job shops all across america, not so much
[00:39:20] <toast_> but still, it would be cool to be ready
[00:39:28] <toast_> lot of work though.
[00:39:36] <stuste1> VERY LIKELY - That is another interest of mine.
[00:39:57] <stuste1> It is a lot of work but if we start now we will finish sooner
[00:39:58] <crotchetyGuy> did you ever get it to work on your machine?
[00:40:23] <stuste1> did I ever get what to work on my machine. The apt program or EMC
[00:40:32] <crotchetyGuy> the apt program-
[00:41:09] <stuste1> no - I haven't tried it in a while. Have you made some progress? I use NCL.
[00:41:47] <crotchetyGuy> well, I have used it for some 4 axis continuous programs at work.
[00:42:02] <stuste1> I will certainly try it again. thanks
[00:42:14] <toast_> man you guys make me jealous =(
[00:43:30] <Ziegler> got my mill vice keyed in: http://images.myonlinesite.com/cnc_mill/tool_mill_vice.jpg
[00:44:11] <crotchetyGuy> we are next door in #cam- if you have issues, drop in - also check out http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl
[00:44:42] <stuste1> Don't trust too much the keys!! Always verify the alignment.
[00:45:00] <Ziegler> yeah thats right stuste1
[00:45:10] <crotchetyGuy> stuste1: I would be interested to get your input- I don't have a lot of multi-axis experience
[00:46:02] <crotchetyGuy> oops- ignore- wrong link- finding the right one....
[00:46:09] <stuste1> I will download it again and try it. I will give is some real attention and try to make sure I can give you some feedback.
[00:47:44] <fenn> heh stuste1 i havent read your "request" yet but i understand what you want and agree it's not that complicated
[00:47:58] <crotchetyGuy> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?AptProgrammingForEMC
[00:48:00] <fenn> re: 5 axis tool offset
[00:48:40] <fenn> as long as you dont change the tool angle during the program...
[00:49:12] <stuste1> my request is to be able to change the tool angle during the program
[00:50:11] <stuste1> great stuff crotchetyGuy - I have some reading to do later
[00:50:18] <Ziegler> oh.. .how is apt coming?
[00:52:28] <crotchetyGuy> also check out https://sourceforge.net/projects/vapt/
[00:52:29] <stuste1> If the apt is inside EMC and processes and posts the source code to run the machine then tool length compensation will not be needed in EMC as the calculation will be done before it gets to the control. This truly would be the ultimate solution.
[00:53:09] <fenn> stuste1: you will have to use kinematics for 5 axis tool offset to work, but you probably need it anyway somewhere in the cad->cam->emc chain
[00:53:19] <crotchetyGuy> I wonder if that is what it would take to get 3d cutter comp going?
[00:53:40] <stuste1> length comp / diameter comp / even changing step overs / changing cutter geometry
[00:54:10] <fenn> how does a cam program specify the path? in terms of joint movements or at the tip of the tool?
[00:54:44] <stuste1> 3d cutter comp is available for some controls. The post must put out some more information - specifically vectors for the control to use.
[00:55:02] <fenn> which vectors?
[00:56:04] <stuste1> the vectors the control would use to comp the tool path. If you have a ball/bull mill cutting a contour you would need a vector to tell the control which direction to comp the cutter.
[00:56:54] <fenn> oh gross, you rotate the part around the tool tip
[00:56:59] <crotchetyGuy> So if it had say, the tool orientation and a direction it was heading, that would be all it needed?
[00:57:02] <stuste1> A CAM program will output tool tip end point and tool axis vectors. The post processor will use that input to create the G code program for a specific machine.
[00:58:28] <stuste1> That would work as you would be able to calculate the offset direction using by crossing the tool axis vector with the forward vector.
[00:58:43] <fenn> ok so the post processor has what i call 'kinematics' in it, which describes the way the rotary tables are stacked and offset
[00:59:01] <matthew> hey, quick question for any haas users out there...
[00:59:12] <stuste1> yes - you must configure the post processor to the machine kinematics
[00:59:23] <fenn> matthew: i dont know anyone using haas
[00:59:34] <stuste1> I have five haas machines - shoot
[00:59:42] <fenn> heh spoke too soon
[01:00:24] <toast_> we have two haas machines at school
[01:00:25] <toast_> but not at work
[01:00:43] <matthew> ok, made a nice family parts program with variables, plotted correctly with NcPlot but when loaded to cnc it marks all the #'s as bad charecters
[01:01:08] <toast_> did you buy the macro option
[01:01:11] <matthew> do you know if macro b is standard on the haas line
[01:01:17] <toast_> it isn't
[01:01:36] <matthew> thats what i was thinking,... my boss said he will upgrade he couldn;t beleive all the stuff i was telling him about
[01:02:19] <crotchetyGuy> fenn: the problem is a linear algebra problem basically- change of coord system from machine coords to part coords.
[01:02:36] <matthew> m98 would be standard though right.... not parametric programming, but internal loops and such... our mill will do m98;s but not sure about parametric
[01:03:32] <crotchetyGuy> or vice-versa- you get the point.
[01:04:32] <fenn> crotchetyGuy: we've got that covered in emc already with kinematics
[01:04:54] <crotchetyGuy> fenn: how does that work?
[01:05:02] <fenn> it makes sense that way too, the part program should represent the part, and the control should know all about hte machine configuration
[01:05:50] <crotchetyGuy> so maybe stuste1's problem isn't that unsolvable.
[01:06:05] <fenn> crotchetyGuy: you feed the motion module a series of cutter location/orientation vectors, and it outputs a series of movements for the joints (motors) to make
[01:06:31] <stuste1> If that is already covered in the kinematics it may be relatively easy to implement. Chris mentioned it would not be difficult just time consuming as it would require changes in many places.
[01:06:37] <fenn> you also have to define the way the machine is set up, and since this is easiest to do in code, there's a different kinematics module for each general case
[01:06:50] <fenn> "stacked rotary tables" would be a general case
[01:07:18] <fenn> tool offset is the thing that requires many changes, as its a poorly designed system to begin with
[01:07:40] <fenn> you cant even specify a ball nose cutter :(
[01:07:50] <stuste1> All the more reason to enhance it
[01:09:04] <fenn> actually, maybe i'm confusing things again with that ball end comment
[01:10:23] <fenn> stuste1: when talking about 5 axis control stuff, it's important to keep the concepts 'joint' and 'axis' separate or you confuse everything
[01:10:42] <stuste1> I think maybe the ball nose cutter would fit in a graphics or simulation area.
[01:10:44] <fenn> joint is the thing that moves, axis is part of the abstract XYZ coordinate system
[01:13:37] <stuste1> The joint/axis connection should make no difference as we are talking about modifying the position the machine should move to.
[01:14:42] <fenn> i get really confused when i start reading things like "If the Z axis has 1 rotary axis then two axis compensation is
[01:14:46] <fenn> necessary
[01:15:09] <stuste1> Hi JohnK. I have been here a while today. It is sometimes hard to follow the conversation as I don't type very fast and sometimes I think even slower.
[01:17:10] <stuste1> If the Z axis carries 1 rotary axis then you must compensate either the Z and Y or the Z and X. If the Z axis carries a tilting rotary table you must the compensate the X Y and Z axes to have tool length compensation
[01:17:47] <fenn> i really think that the tool should count as an extra 'joint' in the kinematics definition, since the length of the tool affects where the tip is
[01:18:15] <toast_> that is kinematically accurate
[01:18:21] <fenn> but it's not how emc does it right now :(
[01:19:38] <toast_> i'm just saying you're technically correct.
[01:19:43] <toast_> =(
[01:19:43] <fenn> stuste1: see what i'm saying is that a 'z axis' cant carry anything. a knee on a mill can carry something, or a bed can have something mounted on it
[01:19:53] <toast_> tru
[01:21:13] <fenn> i know it's not how machinery people normally talk
[01:21:14] <stuste1> On the Haas VR-11 the Z axis carries the tilting rotary table. The tilting rotary table carries the spindle. This gives the machine 5 axis motion. On MANY 5 axis mills the Z axis carries both the rotary axes.
[01:22:00] <fenn> ok i understand that
[01:22:41] <toast_> no dude, you don't get it
[01:22:48] <toast_> an axis is a theroetical construct
[01:22:51] <toast_> it doesn't actually exist
[01:22:55] <stuste1> when configuring a post processor you must specify which axis is a rider and which axis is a carrier
[01:22:56] <toast_> that's what he's saying.
[01:24:07] <fenn> its really sad that control manufacturers have such crap software that they force the cam software to do kinematics for them
[01:24:26] <toast_> or have such crap designs
[01:24:33] <fenn> there's nothing wrong with the design
[01:24:45] <fenn> i mean, it works right?
[01:25:03] <toast_> well, i guess what i meant is some kinematic configurations are superior to others
[01:25:22] <fenn> yeah sure but industry is conservative
[01:25:24] <toast_> indeed
[01:25:55] <fenn> that's where i come in :P
[01:26:02] <fenn> toss 'em on their heads
[01:26:07] <toast_> hahaha
[01:26:21] <stuste1> OK. I will try again. The joint that is congruent with the Z axis carries the joint which is congruent with the B axis which then carries the joint which is congruent with the A axis which then carries the spindle. The joint which is congruent with the Y axis carries the joint which is congruent with the X axis. The two joints that are congruent with the X and Y axes move under the spindle.:)
[01:27:32] <fenn> stuste1: the two rotary joints holding the spindle aren't exactly congruent to A and B
[01:27:49] <fenn> one has to rotate around the other
[01:28:36] <stuste1> If the manufacturing is absolutely correct then they both rotate around the same exact point
[01:28:45] <toast_> no
[01:28:45] <toast_> they don't
[01:28:47] <toast_> they never will
[01:28:50] <fenn> the order in which they're stacked affects what angle you end up with
[01:28:48] <toast_> and can't
[01:28:53] <fenn> the math is not commutative
[01:29:22] <stuste1> the stacking order is very important.
[01:31:30] <fenn> lol haas has a zip drive
[01:31:59] <stuste1> If the axis of the A joint and axis of the B joint do not project through the same point then the machine must be compensated geometrically. This is where the kinematics comes in to create a theoretical axis motion to give accurate 5 axis motion.
[01:33:07] <fenn> even if they're perfect you need to describe the stacking order
[01:33:23] <fenn> i figure that is kinematics
[01:33:28] <stuste1> I agree
[01:34:14] <stuste1> That is not necessarily kinematics to EMC. That configuration is in the post processor that created the G code program from the CAM system.
[01:34:40] <fenn> but if emc doesn't know about how the machine is put together, it cant do fancy stuff like 5 axis compensation
[01:35:09] <stuste1> I agree - that is the reason I started this dialog.
[01:35:29] <fenn> ok, so let's just forget about this post processor stuff ok :)
[01:35:44] <stuste1> ok
[01:36:05] <stuste1> I MIGHT possibly mention it again sometime.
[01:36:46] <fenn> we really should have a stacked-rotary VMC configuration in the demos
[01:37:19] <stuste1> I am intrigued with your comment about treating the tool length as a joint. This may be the best way to answer this question.
[01:37:28] <toast_> it's kinematically accurate
[01:37:41] <fenn> the way i see it, the part program should describe the relation between the tool tip and the part
[01:38:07] <fenn> the control takes that info along with other configuration info (like tool length and kinematics) and comes up with motor movements
[01:38:31] <fenn> then you can take that part program and run it on a totally different type of machine and get the same result
[01:39:22] <stuste1> the way I see it the part program should be the absolute authority for machine motion and control. The machine should do nothing other than what the program tells it to do.
[01:39:36] <toast_> i don't think that's in question
[01:39:37] <fenn> if tool length isn't considered inside kinematics, you have to do all kinds of gross stuff with post processors and cam
[01:39:57] <toast_> what fenn is suggesting agrees with the philosophy that the program should do what it is told
[01:40:07] <fenn> just at a higher level
[01:40:14] <stuste1> You are talking about the HOLY GRAIL of machining with the ability to take the program and use it on kinematicly different machines.
[01:40:24] <fenn> well, of course :)
[01:40:31] <toast_> with a proper kinematics definition, that's a given
[01:40:36] <toast_> and what he's suggesting is kinematically accurate
[01:40:41] <fenn> you can still move joints around one by one if you want to
[01:40:51] <fenn> like quill and knee
[01:41:59] <fenn> i always thought that was how it worked until i went and saw how they make sausage, so to speak
[01:43:28] <fenn> this is definitely within the capabilities of g-code
[01:43:35] <Ziegler> sausage?
[01:43:43] <Ziegler> with g-code?
[01:43:48] <fenn> you can carry the concept further, and that's what step-nc is all about
[01:43:49] <toast_> that would be an awesome machine
[01:44:01] <fenn> toast_: ?
[01:44:01] <Ziegler> I want a cnc sausage machine
[01:44:05] <toast_> ^^^
[01:44:07] <toast_> cnc sausage machine
[01:44:14] <stuste1> g-code should be able to control a machine that makes sausage
[01:44:24] <Ziegler> :)
[01:44:26] <toast_> g1 x5. f10 l10
[01:44:32] <fenn> um, no.
[01:44:36] <Ziegler> LOL
[01:44:37] <toast_> IT COULD WORK THAT WAY
[01:44:43] <fenn> no
[01:44:58] <fenn> maybe with step-nc
[01:45:10] <fenn> sausage(5,10) feed(10)
[01:45:14] <toast_> hahaha
[01:45:24] <fenn> or whatever the xml is supposed to look like
[01:45:26] <toast_> i am just being ridiculous
[01:45:33] <stuste1> step-nc is what many people are working on today
[01:45:32] <toast_> do not mind my invalid g-code
[01:45:57] <Ziegler> EMC3 (step-nc)
[01:46:18] <fenn> i dont see step-nc happening any time soon
[01:46:30] <stuste1> I like the sound of that. How impressive to do it before the industry.
[01:47:21] <fenn> well, you need a decent CAD infrastructure that supports STEP to begin with..
[01:47:36] <crotchetyGuy> I am not convinced step will replace g-code- interested in other opionions,though, and I don't know much about step
[01:47:39] <stuste1> It won't happen any time soon. Follow the money. Which control company is going to obsolete all other controls?
[01:48:19] <fenn> in a market based mostly on reputation, i dunno
[01:48:37] <Ziegler> CAD Microstation CAD files are open source
[01:48:42] <SWPadnos> EMC2!
[01:48:48] <fenn> people say that industry is so cutting edge and cut-throat but i dont believe it one bit
[01:48:53] <stuste1> STEP is just an evolution of IGES. It can be included in any CAM package.
[01:49:25] <stuste1> I agree! Steve
[01:49:37] <toast_> they aren't, the labs are
[01:49:56] <tomp> phew! i got some labjack data thru hal using the python interface ( i got the file handle on a float pin :)
[01:50:20] <fenn> toast_: right, and that's where we see emc2 being used
[01:50:28] <toast_> ?
[01:50:29] <fenn> by universities and hobbyists
[01:50:43] <toast_> i see commercial or experemental controls being used in labs
[01:50:46] <toast_> and universities
[01:50:59] <toast_> you have to compete with Fanuc willing to give universities free, cutting edge controls
[01:51:05] <tomp> and mad scientists use it too
[01:51:09] <toast_> that IS true
[01:51:18] <stuste1> How much does EMC cost?
[01:51:23] <toast_> nothing
[01:51:23] <fenn> yea that guy with the laser cutter is pretty crazy :)
[01:51:32] <toast_> just like the cutting edge Fanuc control
[01:51:46] <tomp> a pound of flesh
[01:51:58] <fenn> ten hours of your intern's time
[01:52:06] <SWPadnos> it's a commonly used technique. put your stuff in the schools, and people will be indoctrinated into using it as professionals
[01:52:14] <toast_> and it works great!
[01:52:16] <Ziegler> stuste1: time
[01:52:20] <SWPadnos> and they won't know anything else
[01:52:27] <SWPadnos> yes, it does work well, shitty though it is
[01:52:27] <stuste1> I may have given EMC more than a pound of flesh
[01:52:29] <toast_> but i don't see emc ready to compete with fanuc
[01:52:48] <toast_> but more people can use emc
[01:53:02] <toast_> smaller colleges, etc
[01:53:22] <Ziegler> larger colleges too
[01:53:30] <stuste1> with a few suggested 'enhancements' I will replace a 15mb control with EMC.
[01:53:40] <toast_> the machining projects I've seen at larger colleges all use high end control systems
[01:53:51] <toast_> sometimes multiple control systems from different companies on one machine
[01:53:56] <tomp> colleges are run by bean counters, they love used machines and emc ( or free fanucs, they're whores )
[01:54:20] <stuste1> aren't we all. I am a machining prostitute
[01:54:21] <toast_> it depends on the scope of the project
[01:54:29] <tomp> :)
[01:55:21] <toast_> but a lot of the 'cutting edge' projects you guys are talking about are beyond the ability of emc to control, at present
[01:55:36] <toast_> not that with all the stuff you are discussing emc won't be a contender in the future
[01:55:37] <stuste1> but I don't like financial sex - where I am the one getting screwed
[01:56:55] <stuste1> EMC is already a contender on most stages. It is very capable of competing with most current controls. The labs have controls that are unavailable to the machine tool industry.
[01:57:47] <toast_> cutting edge things, like the lathe canned cycles for roughing and finishing? =)
[01:58:30] <fenn> i'd have to agree with toast.. never seen emc running a mill-turn
[01:58:49] <stuste1> why would that not be possible?
[01:58:58] <toast_> because they aren't implemented right now
[01:59:03] <fenn> because g-code sucks
[01:59:12] <stuste1> only because someone hasn't done it YET
[01:59:14] <toast_> hookay
[01:59:22] <toast_> well, based on that system, i am the first person to mars
[01:59:26] <toast_> i just haven't been there yet.
[01:59:37] <fenn> i'm immortal as far as i know
[01:59:44] <toast_> ^5!
[01:59:49] <crotchetyGuy> fenn: I have to wonder what would replace g-code?
[01:59:51] <fenn> and you are all figments of my imagination
[02:00:02] <toast_> fenn: you have a horrible imagination
[02:00:21] <fenn> crotchetyGuy: g-code can only describe the relationship between two things. a mill turn has at least 3 things moving (lathe bit, part, milling bit)
[02:00:45] <fenn> so, something that can describe more complex motion
[02:01:03] <fenn> or you can do some synchronization hand-off hack
[02:01:14] <toast_> it would be freakin' awesome to use some other, expandable functional language
[02:01:20] <crotchetyGuy> sounds like "super g-code"
[02:01:30] <stuste1> you guys are nuts
[02:01:32] <toast_> if someone came up with a machine library for like, C
[02:01:35] <fenn> toast_: that's why i'm ostensibly working on a set of python bindings
[02:01:36] <toast_> or perl
[02:01:43] <toast_> or that
[02:01:47] <fenn> but i guess they're already there and i just didnt know about it
[02:01:49] <toast_> that would be very cool
[02:01:54] <fenn> so, its a documentation problem now?
[02:02:42] <fenn> and emc only knows about 9 axes, but that seems like its easy enough to extend
[02:02:45] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/Submakefile: improve dependency information for l2h docs
[02:02:56] <toast_> fenn: with your python extension it would be a non-problem, right?
[02:03:06] <fenn> toast_: i dont know
[02:03:16] <stuste1> while you are documenting you 'super G code' would you implement 5 axis tool length compensation?
[02:03:29] <toast_> or n-axis tool length comp
[02:03:30] <toast_> :o
[02:03:31] <fenn> heh i'm not jepler you know
[02:03:55] <jepler> my ears are burning
[02:04:05] <toast_> jepler: the users demand n-axis tool length comp!
[02:04:10] <stuste1> bow to the god
[02:04:20] <jepler> toast_: yeah but I haven't the slightest idea what that is
[02:04:27] <fenn> weakly god-like non-artificial intelligence
[02:04:33] <jepler> may I offer you a slightly useless python program instead?
[02:04:35] <toast_> tool length compensation for any arbitrary number of axes
[02:04:38] <toast_> jepler: you may!
[02:04:52] <toast_> i won't use it for anything, but i will accept your gift with grace.
[02:04:53] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/ (l2h.xsl xref.xsl): tweak multicolumn toc/index layout; get rid of ToC header if no items
[02:05:05] <toast_> hahah.
[02:05:24] <crotchetyGuy> fenn: sounds like you want g-code with threading:)
[02:05:37] <toast_> that's exactly what they do
[02:05:46] <fenn> crotchetyGuy: yeah something like that, except i hate g-code
[02:06:02] <SWPadnos> how about calling it H-code instead?
[02:06:07] <toast_> U-code
[02:06:08] <toast_> UBERCODE
[02:06:14] <fenn> hey we could use H1 for linear feed
[02:06:20] <SWPadnos> of the mac version - iCode
[02:06:25] <SWPadnos> or
[02:06:29] <toast_> eCode - the iCode killer
[02:07:14] <SWPadnos> stuste1, I remember talking to you about cutter comp at CNC workshop, and I even remember thinking I understood what you were trying to say :)
[02:07:15] <fenn> think i'm gonna go have some breakfast
[02:07:36] <SWPadnos> however, I don't remember why I thought it might be as easy as you think
[02:07:41] <stuste1> have I thoroughly confused you now?
[02:07:48] <SWPadnos> no, that's my job thank you very much! :)
[02:07:58] <fenn> cutter comp is normally along a plane, probably XY
[02:08:12] <fenn> with 5 axis you have a sort of moving average along the path that defines the plane
[02:08:54] <stuste1> You didn't sound like you thought it would be easy. You thought it would be very difficult considering how EMC implements cutter comp.
[02:09:05] <SWPadnos> I think it had to do with the idea that the CAM output will be in a form that you don't need truly generic compensation algorithms
[02:09:18] <SWPadnos> I think I thought it would be hard, regardless of how EMC does it
[02:09:36] <stuste1> with 2 axis interpolation you have a moving average also.
[02:09:47] <fenn> if you had surface normal information from CAM you can use that as the direction to compensate
[02:10:10] <fenn> vectors perpendicular to the surface you're machining
[02:10:24] <stuste1> yes - that is what we discussed earlier about 3d compensation
[02:10:30] <SWPadnos> you can infer surface normals for both the cutting tip and the edge
[02:10:56] <stuste1> CAM output is very generic. X.... Y.... Z.... A.... B....
[02:10:58] <SWPadnos> but that doesn't fix the issue of machine axis stack-ups being different
[02:11:10] <SWPadnos> it's not the format, it's the content
[02:11:20] <SWPadnos> the CAM program knows what the part is, and it outputs the path
[02:11:27] <fenn> an apt cutter has 3 primitive surfaces, the face, radius, and edge (taper)
[02:11:39] <SWPadnos> the mcahine only knows the path, so it had to figure out the part if it wants to do comp
[02:11:41] <stuste1> the g-code has the stack ups calculated into it by the post processor
[02:12:07] <SWPadnos> yes
[02:12:36] <fenn> that will never work with cutter compensation
[02:12:49] <SWPadnos> it may be as "simple" as doing some matrix math, once the matrix is determined for the particular machine
[02:13:02] <stuste1> The machine doesn't have to know (or figure anything about the part). I am only wanting to offset the programmed path by a variable amount.
[02:13:21] <jepler> anybody got an opinion on the use of "multi-column" layout? e.g., the ToC here http://linuxcnc.org/docs/devel/html/hal_drivers.html and index here http://linuxcnc.org/docs/devel/html/xref.html ?
[02:13:46] <jepler> I expect it only to work in mozilla but degrade to single-columnd display on IE or Opera .. but the question is whether it's better than 1-column layout
[02:13:48] <fenn> SWPadnos: sure you just offset the desired position by the tool radius in the direction of the normal (or use the length for the face surface, or the ellipsoid-distance for the tip radius hoo boy)
[02:14:02] <SWPadnos> I only see one column in mozilla
[02:14:02] <crotchetyGuy> stuste1's shop: http://www.mpm1.com
[02:14:20] <SWPadnos> ah - firefox has nice multiple columns
[02:14:32] <jepler> SWPadnos: I tested only in ff1.5 so far
[02:14:42] <stuste1> jepler: looks good to me in firefox
[02:14:42] <jepler> that's what I meant when I said mozilla
[02:14:43] <SWPadnos> FF2.0.0.7 works
[02:14:52] <SWPadnos> mozilla 1.7x doesn
[02:14:54] <SWPadnos> t
[02:15:09] <SWPadnos> let me see how it looks on the high res monitor
[02:15:09] <jepler> works and you like how it looks?
[02:15:17] <SWPadnos> yes, I prefer the multicolumn output
[02:15:46] <SWPadnos> if the headings could be made not full width, that would be good
[02:15:59] <stuste1> now you have done it. I am no longer anonymous. You will know what I look like. You still don't know where I live.
[02:16:26] <SWPadnos> there are a few places (around 1.3.x or so) where it just looks mostly like horizontal bars
[02:16:32] <SWPadnos> (that's separate from the column thing)
[02:17:30] <fenn> wow that is a big shop
[02:19:12] <SWPadnos> columns work nicely on the high res monitor as well. I get up to 8 columns, then there's a little extra space on the right
[02:19:30] <SWPadnos> but the page does fill the entire width, which is a nice departure from most of the internet
[02:20:19] <fenn> i like the fact that it doesnt require me to use a high res monitor
[02:20:33] <SWPadnos> heh. yes, it also works at 1280x1024
[02:20:52] <SWPadnos> but it's also quite readable at 3840x2400
[02:23:42] <jepler> I'm not sure how to make the 'pre' and 'h#' colored areas only extend a certain distance -- any web developers handy to tell me how?
[02:24:07] <stuste1> jepler: I like the look. It also looks good when you drill down.
[02:24:46] <tomp> stuste1: a guy once tried to tell me those CHMER edms were somehow connected to the Khmer Rouge of the Vietnam War. Unforch I had been to the Ching Hong Mechanical & Electrical Research facilities :)
[02:25:11] <jepler> tomp: ha
[02:30:17] <toast_> god damnit i am having lab reporter's block
[02:30:52] <stuste1> The Mighty Viper is the bridge mill I would like to put EMC on. It would replace the Fanuc 15mb control. I need geometric compensation on that machine. Fanuc has it on the newer controls but it can be VERY expensive to upgrade to a new Fanuc control. I want to put a probe in the spindle, check an artifact and update the compensation with the results.
[02:31:09] <tomp> i'm up to 3 real pins on the labjack to hal now ( a bit useless, the version, wether a driver is present and the filehandle )
[02:31:33] <toast_> stuste1: doesn't emc already have a chart
[02:31:37] <toast_> you just have to edit it by hand?
[02:32:02] <tomp> stuste1: i dont think emc has 3d comp ( like Z posn correct by xy location ), and unsure of 2D ( like x to y )
[02:32:11] <toast_> oh.
[02:32:11] <jepler> I can make the <H#> style be "thin line below" and <PRE> style be "thin line on left"; that probably looks better when the window is "too wide"
[02:32:11] <stuste1> I don't know. If there is where would I find it?
[02:32:54] <toast_> great question!
[02:33:17] <SWPadnos> stuste1, so you want to machine something, then probe it, then grab the same tool back and use the results of the probe pass for compensation?
[02:33:23] <jepler> currently emc only has one-axis compensation (a correction to X based on X); it's been suggested that kinematics could do full 3D compensation but I don't think anybody's tried
[02:33:25] <toast_> SWPadnos: no, using a gage
[02:33:35] <toast_> like a step block
[02:33:37] <stuste1> This seems like a kinematics solution. I would need writable parameters for the kinematics.
[02:33:59] <toast_> the block has lapped surfaces
[02:34:09] <jepler> kinematics can have parameters (tripodkins does to set the tripod geometry) but you would need a large number of them for this purpose..
[02:34:10] <toast_> and you touch off the block along the surfaces and get an error map
[02:34:28] <SWPadnos> ok, so stick a 3" ball bearing in the vise (how? ;) ), then probe all around the ball and figure out the machine errors from that
[02:34:43] <toast_> no no no
[02:34:49] <tomp> ballbar
[02:34:52] <toast_> imagine this gage block
[02:34:57] <SWPadnos> ah, gepmetric comp - never mind
[02:34:59] <toast_> that has lapped surfaces at 1" intervals
[02:35:01] <SWPadnos> geometric
[02:35:03] <SWPadnos> much easier
[02:35:34] <tomp> cataract gauge ;) certified surfaces every inch
[02:35:38] <stuste1> I am thinking I would need only six parameters for this machine. Three each for the rotary axes.
[02:35:48] <toast_> ?
[02:36:13] <SWPadnos> 2 rotaries * 3 each = 6 ...
[02:36:22] <toast_> that's not going to do what you want
[02:36:35] <toast_> if you are trying to get geometric error comp
[02:36:58] <jepler> is this a better style than the "solid rectangles of color" for doc pages? http://emergent.unpy.net/index.cgi-files/sandbox/alt-style-medium.png
[02:37:32] <toast_> stuste1: you don't want to just check one or two points
[02:37:44] <toast_> it's usually better to just not correct it, versus trying to take an insufficent sample size
[02:37:50] <tomp> jepler: didnt render as scrollable in ffox 1.5, and uit sure looks like there's more to it
[02:38:10] <tomp> no elevator/slider
[02:38:10] <jepler> tomp: that last link is just a partial screencap
[02:38:11] <stuste1> I should need only X comp, Y comp and Z comp for each of the rotary axes. The probe would allow the control to determine the inaccuracies of the rotary axis positions at the home position of each axis and then write that into the parameters for the kinematics to use.
[02:38:16] <tomp> oh
[02:38:37] <tomp> png!
[02:38:40] <jepler> ding ding
[02:38:50] <toast_> stuste1: i may not be reading this right, and if so i apologize
[02:38:58] <toast_> but i read that as you only want to check the table at one point
[02:39:06] <toast_> rather than checking it ever 15 degrees or whatever
[02:39:09] <toast_> *every
[02:39:40] <fenn> sepehr kiani mentioned something about geometric compensation on the list but now i cant find it
[02:40:23] <stuste1> The artifact would be built to allow checking at a sufficient number of points and angle to allow the control to calculate the current inaccuracy.
[02:40:25] <tomp> jepler: the last is easy on the eyes, but it think the solid blocks were better visual organization ( made the organization more pronounced)
[02:40:33] <toast_> stuste1: okay, excellent
[02:41:27] <jepler> maybe the blue vertical bars for <PRE> and the solid rectangles for headers .. I'm not sure if it was headers or <pre> that SWPadnos found distracting..
[02:41:40] <SWPadnos> that image looked better to me
[02:42:00] <SWPadnos> the short sections just have alternating bars of blue background then white background
[02:42:17] <SWPadnos> in the old style
[02:42:47] <tomp> i get fixed table machines with cantilevered heads moving out 1.5 to 2 meters. the control people talk about compensating the Z position for 'droop' I say the damn tool is at an angle to the work.
[02:43:22] <toast_> lol
[02:43:29] <tomp> they need a bridge style machine, you cant fix that with math
[02:43:40] <toast_> or they need a properly scraped/ground way
[02:44:12] <toast_> the old planers with a single column had an arched way that compensated for both angular and vertical error
[02:44:26] <tomp> no, its overhung 60 inches and weighs tons, even with counterbalance and wide saddles, its worse out than in.
[02:44:33] <stuste1> Weight transfer is a very real thing. The tool will be at an angle to the work when the ram droops. The angle will not be very much. Probably insignificant. The droop however may be very significant.
[02:44:58] <toast_> tomp: they machine out the error
[02:45:09] <toast_> not anymore, but they used to
[02:45:33] <jepler> * jepler kicks CIA-8
[02:45:33] <CIA-8> ow
[02:45:44] <fenn> i love it
[02:45:53] <toast_> they measure the droom from full extend to full retract
[02:45:54] <toast_> *droop
[02:45:58] <fenn> * fenn pats CIA-8
[02:46:08] <tomp> nice cia-8
[02:46:20] <jepler> but he hasn't shown the last commit message :-P
[02:46:23] <jepler> :-(
[02:46:32] <stuste1> The bridge mill in my shop has 100 inches of Y travel. There is now about .003 bow in the center of the bridge. This is compensated for in the control. The bow wasn't there when the machine was new.
[02:47:00] <fenn> the metal sagged?
[02:47:03] <toast_> creep
[02:47:09] <toast_> the gantry creeps.
[02:47:25] <toast_> plastic deformation below young's modulus
[02:47:32] <fenn> maybe its stress relief
[02:47:38] <fenn> or strain relief, bah
[02:47:46] <tomp> try tension underneath? like a bridge
[02:47:48] <toast_> every material does it to some extent
[02:47:54] <tomp> i do
[02:48:09] <toast_> creep is a function of time and temperature, so it is a form of stress relief/aging
[02:48:51] <stuste1> all metal moves with stress. The weight of the saddle and bridge have caused it to sag. The droop on your machine will probably not be linear as the weight transfer will have a transfer point. The distance from linear may not be very much but you may have to compensate for it.
[02:49:11] <toast_> you can also have the machine ways reground or rescraped and they'll take that out for you.
[02:49:21] <toast_> but the control is the cheap and readily available option
[02:49:24] <toast_> and gets you just as good a result
[02:49:32] <fenn> its just going to sag again though
[02:49:38] <toast_> yep
[02:49:43] <fenn> software is the sustainable solution :)
[02:49:51] <toast_> well, that's actually way maitnence
[02:50:07] <toast_> in bigger hardware, they have the machines rebuilt on a regular basis
[02:50:19] <toast_> rathe than relying on the control, because it gives them a chance to touch the machine internals up
[02:50:25] <toast_> and make sure the ways are in pristine condition
[02:50:52] <toast_> the control is used in the interim between the maitnence.
[02:51:31] <toast_> if you don't get that droop or error out of it mechanically, it can accelerate the wear and drop machine life.
[02:51:59] <toast_> not a big issue on a 40x80 milling machine, but it's a huge issue on big castings that cost more than most new machines
[02:52:05] <fenn> they should design the ways with sagging in mind then
[02:52:10] <toast_> they DO
[02:52:18] <toast_> but they can't be pre-emptive about it
[02:52:20] <fenn> with 5 points of contact or whatever
[02:52:23] <toast_> 3
[02:52:28] <fenn> 3?
[02:52:36] <toast_> yeah
[02:52:44] <toast_> that kinematically constrains something for flatness/no stress
[02:52:44] <fenn> because gravity does the rest or what?
[02:53:04] <fenn> no you need 5 points for a fully constrained linear movement
[02:53:04] <stuste1> I am not trying to remove the sag. That is no problem. I am trying to compensate for rotary heads. The center line of the spindle is not coincident with the B axis and the B axis is not coincident with the C axis.
[02:53:04] <toast_> also they don't use the 3/5/6 point contact
[02:53:08] <toast_> on a way
[02:53:23] <toast_> because ways use elastic averaging for accuracy
[02:53:32] <toast_> rather than kinematic correctness
[02:53:53] <toast_> they machine the ways to take out any droop and error in the tool when the machine is new
[02:54:01] <toast_> and then just periodically take it out as it forms
[02:54:20] <fenn> i figured it was the non-straightness of the ways combined with being overconstrained that caused excess wear
[02:54:44] <toast_> wear is almost always improper care for the ways
[02:54:46] <toast_> almost always.
[02:55:01] <fenn> i dont see how regrinding the ways can solve anything
[02:55:08] <toast_> they grind an arc into the way.
[02:55:14] <fenn> if it gets messed up you have to regrind it anyway
[02:55:24] <toast_> ?
[02:55:33] <fenn> its like buying a new car because that's how you change the oil, silly
[02:55:41] <toast_> what?
[02:55:53] <toast_> i'm listening, i just don't understand what you're saying
[02:55:55] <fenn> you're saying that regrinding the ways is part of 'proper way maintenance' right?
[02:56:00] <toast_> correct
[02:56:09] <fenn> and if your ways get messed up, then what do you do?
[02:56:17] <toast_> regrind them a lot.
[02:56:19] <fenn> you regrind them!
[02:56:23] <toast_> a lot, versus less.
[02:56:24] <fenn> so why bother
[02:56:33] <toast_> because you can cause failure in the castings
[02:56:39] <toast_> and other stress
[02:57:32] <toast_> it's not an issue in a smaller vmc
[02:57:44] <toast_> i'm not trying to pretend shops everywhere are doing this
[02:58:01] <toast_> because it's usually cheaper to just get a new machine when it wears out
[02:59:19] <stuste1> thank you very much for you comments and suggestions. I will be back. Good Night
[03:04:37] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/common/emc2_introduction.lyx: add labels. ream some outdated texts
[03:07:08] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/l2h.xsl: don't show Notes in the html
[03:14:43] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/index.tmpl: re-organize hal lower down the index
[03:15:01] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/common/Glossary.lyx: additional indexing and cross-referencing
[03:15:01] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: additional indexing and cross-referencing
[05:57:24] <toast__> toast__ is now known as toastydeath
[09:44:43] <fenn> * fenn ate too much candy
[10:14:31] <alex_joni> heh
[11:33:55] <The_B> The_B is now known as The_Ball
[12:14:24] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/ (l2h.xsl lyxtree.py xref.py xref.xsl): xslproc needs a little help sorting indexes .. still not perfect
[12:51:09] <leeleatherwood> hi, is anyone around?
[12:52:14] <leeleatherwood> I am having trouble getting my designs from solidworks into EMC Compatible GCode
[12:52:26] <leeleatherwood> I was wondering if anyone has any pointers
[12:53:20] <alex_joni> hi
[12:53:33] <leeleatherwood> hi
[12:56:14] <leeleatherwood> alex, how do you get your GCode from DXF file?
[12:57:12] <alex_joni> there are a number of CAM apps which do that
[12:57:27] <alex_joni> for *very simple* things there are dxf2g-code converters (like ACE)
[12:58:28] <leeleatherwood> I have used ACE... it works to an extent.
[12:58:41] <alex_joni> right, further you need a CAM app
[12:58:48] <alex_joni> I know synergy which runs on linux
[12:58:55] <alex_joni> and a number of doze apps
[12:58:57] <leeleatherwood> I would like something more graphical, Lazycame works great for me but it will not output GCode that works with EMC
[12:59:14] <leeleatherwood> lazycam*
[12:59:24] <fenn> what's wrong with the gcode?
[12:59:29] <alex_joni> most cam packages have something called a post-processor
[12:59:41] <alex_joni> which is the thing that writes g-code numbers and parameters, etc
[12:59:57] <alex_joni> usually you have to adjust a postprocessor to work with emc (or any other interpreter)
[13:00:09] <leeleatherwood> I see
[13:00:18] <alex_joni> otoh, lazycam is the one for mach.. right?
[13:00:26] <leeleatherwood> yeah
[13:00:32] <alex_joni> it should be mostly the same thing, as mach uses the same interpreter
[13:00:43] <leeleatherwood> it outputs a .tap file
[13:00:43] <alex_joni> only special G and M codes might be different
[13:01:01] <alex_joni> * alex_joni suggests pastebin.ca
[13:01:05] <leeleatherwood> and when i try to load it into EMC it will not
[13:01:20] <fenn> did you rename it .ngc?
[13:01:36] <fenn> * fenn always hated that filter crap
[13:01:54] <alex_joni> you can have a ini entry for it to load .tap files
[13:02:04] <fenn> yeah but most people dont know about that
[13:04:04] <alex_joni> PROGRAM_EXTENSION = .tap Lazycam g-code
[13:04:08] <alex_joni> tap =
[13:04:28] <alex_joni> I *think* that using = ' ' is the way to make it load by default.. might be wrong though ;)
[13:04:38] <alex_joni> or maybe cat might be better
[13:04:41] <alex_joni> tap = cat
[13:04:57] <fenn> yeah that's real obvious :)
[13:05:37] <alex_joni> it might be :D
[13:06:14] <fenn> how bout egrep '.*' -
[13:07:19] <leeleatherwood> yeah i renamed it to .ngc, still didnt work. I forgot the error messages but i will go look it up in a few
[13:07:39] <alex_joni> leeleatherwood: while you're at it.. don't forget to grab the file aswell
[13:07:49] <alex_joni> if it doesn't work, it would be best if we can look at it
[13:07:58] <alex_joni> so putting it at pastebin.ca is really helpfull
[13:08:20] <fenn> and the error too
[13:30:19] <leeleatherwood> ok, these are the errors, will post the file in a few secs
[13:30:35] <leeleatherwood> line 4; unknown g code used
[13:30:55] <leeleatherwood> only error on that file ;)
[13:31:53] <leeleatherwood> pastebin is loading slow
[13:31:59] <alex_joni> did you use pastebin.ca ?
[13:32:05] <alex_joni> the .com one is really slow
[13:32:15] <leeleatherwood> im using .ca
[13:32:51] <leeleatherwood> alex, have you used Asterisk? I have a great working asterisk setup and hopefully a great emc setup
[13:36:35] <skunkworks> leeleatherwood: good to see you on here. (samco on cnczone)
[13:36:47] <leeleatherwood> http://pastebin.ca/729828
[13:38:01] <leeleatherwood> hi samco
[13:39:23] <alex_joni> leeleatherwood: I don't have asterisk.. unfortunately I learned about it about 2 months too late
[13:39:32] <alex_joni> already had order a commercial alternative
[13:39:36] <fenn> G91.1*. Incremental arc centers mode
[13:39:53] <leeleatherwood> ouch
[13:40:29] <alex_joni> hmm.. pastebin.ca is really slow today
[13:40:34] <fenn> is there a way to turn that off in lazycam?
[13:40:46] <leeleatherwood> possibly, i will check
[13:40:51] <fenn> seems like a weird 'feature'
[13:41:01] <lerman__> leeleatherwood: I'm using Trixbox (which is essentially the same as asterisk -- dons armor)
[13:41:49] <leeleatherwood> to be honest, i really feel like the creators of MACH3 and Lazycam are trying to make it propiority
[13:41:48] <skunkworks> are we talking phone systems? We tried asterisk a few months ago.
[13:41:58] <lerman__> Yup. Phones.
[13:41:59] <leeleatherwood> yeah
[13:42:21] <skunkworks> I don't know if we will ever get rid of our pbx - but it looked cool.
[13:43:03] <lerman__> My first try using asterisk with a cheap board was a disaster (echo, CID didn't work). Got a decent board and it works fine.
[13:44:03] <leeleatherwood> these are the only options in Lazycam. "Use G41/G42 on Leadin outputs" and "Incremental IJ's. Will use appropriate control words to set Mach3"
[13:44:28] <fenn> un-set incremental IJ
[13:44:33] <leeleatherwood> I am using VIOP inbound and outbound so I would not need any special hardware, just 2 nics
[13:44:51] <leeleatherwood> ok
[13:44:56] <leeleatherwood> will try it again
[13:46:06] <fenn> for future reference, these are the g-codes emc recognizes http://linuxcnc.org/docs/html/gcode.html
[13:47:53] <leeleatherwood> I should really do some tutorials on writing GCode from scratch so that I do not rely on programs
[13:48:07] <fenn> * fenn shrugs
[13:48:15] <fenn> g-code kinda sucks for writing programs
[13:48:34] <fenn> you should learn to read g-code, but writing it isnt very useful unless you have to
[13:49:38] <leeleatherwood> ok
[13:50:41] <fenn> i think learning python would be a good first programming language if you dont know one already
[13:51:07] <fenn> then you can print out all the g1's your heart desires
[13:51:16] <leeleatherwood> I am working on C#
[13:51:26] <fenn> ok, that's a good one
[13:51:52] <leeleatherwood> I have seen alot of good stuff with python though, so I may work on that afterwords
[13:52:00] <Ziegler> actually... I couldnt get The CAT method to work... but the program extension method did
[13:52:05] <cradek> if you remove the G91.1 does that file load?
[13:52:34] <Ziegler> oops... sorry... chat windows was stuck back a few conversations
[13:52:44] <leeleatherwood> well, now it says line 4 is unknown GCode: N20 M5 M9
[13:53:14] <Ziegler> (can you copy and paste it into pastebin.ca?
[13:53:16] <cradek> the file on pastebin doesn't have that line
[13:53:20] <leeleatherwood> doing so now
[13:53:27] <leeleatherwood> pastebin is going really slowly
[13:53:32] <Ziegler> ah
[13:53:52] <fenn> try http://rafb.net/paste/
[13:54:52] <leeleatherwood> http://rafb.net/p/rcAgf279.html
[13:55:12] <cradek> it's the G90.1 that's invalid
[13:55:15] <fenn> argh it stuck g90.1 in there anyway
[13:55:24] <cradek> so edit it
[13:55:37] <fenn> it's the principle though :)
[13:55:45] <leeleatherwood> k
[13:56:03] <cradek> G1 Z1, G2..., G0 Z0
[13:56:04] <Ziegler> what is .1 ?
[13:56:12] <cradek> something is very odd about that
[13:56:16] <fenn> absolute arc centers
[13:56:29] <cradek> emc has incremental arc centers
[13:56:56] <fenn> cradek: is that included in g91?
[13:57:14] <cradek> fenn: emc has incremental arc centers regardless of g90/g91
[13:57:25] <fenn> oh really?
[13:57:31] <leeleatherwood> ok, i removed the g90.1 line and now it says line 21: all axes missing with motion code
[13:57:37] <Ziegler> I have gotten myself use to seeing negative Z for the code I setup
[13:57:40] <cradek> leeleatherwood: yeah I saw that one coming
[13:58:03] <skunkworks> can you set eazycam to output all axis letters?
[13:58:05] <cradek> some posts have an option for "output all words for arcs" and that placates emc
[13:58:09] <Ziegler> might have just needed to remove the .1 leeleatherwood
[13:58:27] <leeleatherwood> ok, let me check both suggestions
[13:58:29] <cradek> can you fix easycam's "default mill post"?
[13:58:58] <Ziegler> (can can it git rid the numbering)
[13:59:11] <Ziegler> :-P
[13:59:26] <leeleatherwood> yeah, i will get rid of the numbering too
[13:59:36] <leeleatherwood> possibly
[13:59:58] <cradek> I don't see any other problems
[14:00:01] <cradek> (except Z being upside-down)
[14:00:04] <Ziegler> N35 G0 Z0.0000
[14:00:05] <Ziegler> N40 M3
[14:00:05] <Ziegler> N45 X162.6080 Y272.2259
[14:00:14] <Ziegler> needs a g code beetween n40 and n45
[14:00:26] <Ziegler> (I think)
[14:00:32] <cradek> Ziegler: I don't think that's right
[14:00:40] <cradek> I think it's still G0
[14:00:54] <cradek> but, it does need an S word or emc won't turn the spindle on
[14:01:04] <Ziegler> yeah
[14:01:11] <Ziegler> learned that last night
[14:03:29] <leeleatherwood2> rafb.net/p/ikDKf927.html
[14:03:45] <leeleatherwood2> http://rafb.net/p/ikDKf927.html
[14:03:59] <Ziegler> hey cradek I just compiled emc 2.1.5 on this machine to check this code... where is the executable located?
[14:04:20] <cradek> you run scripts/emc to start it
[14:04:21] <Ziegler> err... binary to run emc
[14:04:21] <skunkworks> still missing x and y in the circles.
[14:04:32] <Ziegler> thanks
[14:04:40] <leeleatherwood2> yeah i did not find an option for that in lazycam
[14:04:59] <leeleatherwood2> although it does allow me to load a post processor .pst file
[14:05:05] <skunkworks> it must be doable - http://www.cnczone.com/forums/showthread.php?t=44308
[14:05:18] <skunkworks> this example gcode has x and y in g2,3
[14:06:57] <Ziegler> ahh
[14:07:07] <Ziegler> line 41
[14:07:24] <Ziegler> for some reason emc requires an the x and y
[14:07:57] <Ziegler> and I see skunkworks already mentioned that
[14:08:25] <Ziegler> Why does emc require that?
[14:08:31] <leeleatherwood2> im stuck on line 22
[14:08:42] <alex_joni> Ziegler: historic reasons :)
[14:08:55] <Ziegler> leeleatherwood nothing wrong with the latest version I just loaded
[14:10:06] <Ziegler> unless... is your code have a space between each line?
[14:10:40] <leeleatherwood2> no
[14:10:53] <leeleatherwood2> that space is put there by the pasting program
[14:11:18] <Ziegler> oh.. ok... then looking at the linup on the paste program... that line 41
[14:11:45] <cradek> this file has absolute arc centers which is wrong
[14:11:58] <cradek> and you need to have it put the XY words in like skunkworks says
[14:12:09] <Ziegler> (historic reasons you say... heh)
[14:12:27] <leeleatherwood2> yeah, cradek, i just dont see that in the option of LazyCam :(
[14:12:49] <Ziegler> BobCAD/CAM does the same thing to me leeleatherwood
[14:12:55] <cradek> can you edit "Default Mill Post"?
[14:13:12] <skunkworks> leeleatherwood: the the cnczone link I sent you seems to have that as an option.. somewhere.
[14:13:26] <leeleatherwood2> yeah i noticed
[14:13:32] <skunkworks> * skunkworks has never played with mach/lazycam.
[14:13:39] <Ziegler> There is one option that will turn on all axis codes... which creates alot of code... but gives me what I need
[14:14:28] <leeleatherwood2> cradek, i can change that with a postprocessor file
[14:14:33] <leeleatherwood2> .pst
[14:14:46] <skunkworks> Ziegler: so you have lazycam working for you?
[14:14:48] <skunkworks> with emc?
[14:14:53] <leeleatherwood2> but it doesnt have any different ones exept for default
[14:14:53] <cradek> leeleatherwood2: there you go then
[14:15:08] <cradek> I mean can you edit it? what is it?
[14:15:51] <Ziegler> no I was mentioning BobCAM... did the same thing, but I found an option that lets me turn on all the axis codes... maybe you can find something similar in lazy
[14:16:38] <Ziegler> another option...
[14:16:49] <Ziegler> can lazy cam convert arcs to short line segments?
[14:17:04] <Ziegler> not the best... but that can also work.
[14:20:41] <fenn> Ziegler: an arc with no X or Y is supposed to be a circle
[14:21:03] <Ziegler> ok
[14:22:13] <Ziegler> man CAM progs gerenerate code in such a way that if Y or X coords dont change... they wont add in a X or Y coordinate
[14:22:43] <fenn> right. i think emc is supposed to work that way but it's just a low priority thing to fix
[14:22:57] <fenn> as far as arcs with no x or y
[14:23:18] <Ziegler> do those ever work?
[14:23:19] <cradek> no, ngc says the words are required
[14:23:26] <cradek> it's a bug in the spec, not a bug in emc
[14:23:28] <alex_joni> http://www.linuxcnc.org/docs/devel/html/gcode_main.html#sub:G2,-G3:-Arc
[14:23:34] <fenn> then the spec should be fixed :)
[14:23:39] <alex_joni> It is an error if:
[14:23:39] <alex_joni> X and Y are both omitted
[14:23:39] <alex_joni> or I and J are both omitted.
[14:24:06] <Ziegler> yeah... I somwhat agree with fenn. I can live with it, but it seems that the standard could be updated
[14:24:07] <cradek> fenn: I agree. If you fix it please put it on a branch to merge later, because we're in feature freeze
[14:24:28] <fenn> i'm going to sleep :)
[14:24:33] <jepler> 'night
[14:24:40] <Ziegler> could it be a selectable option?
[14:24:48] <fenn> Ziegler: absolutely not
[14:24:54] <fenn> that way lies madness
[14:25:01] <Ziegler> hear you loud and clear
[14:25:00] <cradek> no need, since it that change wouldn't break existing ngc programs
[14:25:05] <cradek> s/it//
[14:25:18] <Ziegler> good point cradek
[14:25:55] <skunkworks> is it a feature or a bug fix ;)
[14:26:05] <alex_joni> it's a spec fix
[14:26:12] <alex_joni> which is by definition a feature :D
[14:26:40] <cradek> I think whoever changes that is unlikely to get it right in one try, so it doesn't belong in 2.2
[14:26:40] <alex_joni> emc != spec -> bugfix
[14:27:29] <skunkworks> this is cool -> http://www.youtube.com/watch?v=wi4dKAseDCg#GU5U2spHI_4
[14:29:11] <Ziegler> wow... why does the table move up and down?
[14:29:12] <leeleatherwood2> i like how he raises and lowers the table with the chain drive
[14:29:14] <leeleatherwood2> good idea
[14:29:24] <Ziegler> and the video of it cutting looks speed up
[14:30:53] <skunkworks> if you want to read about it http://www.cnczone.com/forums/showthread.php?t=33485
[14:31:30] <Ziegler> thanks sku
[14:34:40] <Ziegler> I only skimmed... but any ideas why the Z moves on a 2D table?
[14:35:56] <skunkworks> makes it a bit more flexable I guess
[14:36:10] <skunkworks> what if you want to etch something that is pretty thick..
[14:36:20] <Ziegler> I see
[14:36:36] <Ziegler> my mind isnt awake yet.
[14:36:44] <Ziegler> maybe next month
[14:40:58] <fenn> laser is pretty picky about z
[14:47:14] <CIA-8> 03alex_joni 07TRUNK * 10emc2/debian/emc2.files.in: pciread was missing
[14:47:32] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/ (l2h.xsl xref.xsl):
[14:47:32] <CIA-8> * xmlns:fo is not used
[14:47:32] <CIA-8> * include HTML DTD in output
[14:48:27] <skunkworks> fenn: right - be a lot easier to make the table drop than the head move up with that design.
[14:48:46] <skunkworks> (think he is using mirrors to get the laser to the head)
[15:07:01] <lewin1> lewin1 is now known as lewing
[15:20:45] <CIA-8> 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-6.06/emc2.files: stepconf menu entry wasn't specified
[15:21:02] <alex_joni> * alex_joni goes home
[15:44:53] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/config/ (5 files):
[15:44:52] <CIA-8> * add and use images
[15:44:52] <CIA-8> * add labels for toc
[15:44:52] <CIA-8> * a few text fixes
[15:45:05] <Ziegler> why put the funky music on a cnc video: http://www.youtube.com/watch?v=65ijh8IX-_4&mode=related&search=
[15:46:57] <Ziegler> Hey.. any of you guys do thread milling with emc?
[15:47:46] <cradek> I haven't but I often use helixes for other stuff
[15:48:09] <archivist> I would love to do thread milling
[15:48:25] <Ziegler> My spindle speed doesnt need to be controlled does it?
[15:48:35] <cradek> not for thread milling
[15:48:49] <cradek> you just need the special cutter
[15:49:00] <Ziegler> What are some "musts" for thread milling (besides cutter)
[15:49:06] <cradek> very good backlash control
[15:49:07] <archivist> does need to be synchrinised
[15:49:23] <Ziegler> hmmm
[15:49:31] <cradek> archivist: not with the special cutter
[15:50:02] <Ziegler> bet I could grind a single point tool
[15:50:04] <cradek> Ziegler: you're talking about a thread milling cutter, not rigid tapping, right?
[15:50:13] <Ziegler> Thats correct cradek
[15:50:24] <cradek> right no synchronization needed then
[15:50:51] <cradek> it would be fun to try to grind a tool that works
[15:51:07] <Ziegler> yeah hehe
[15:51:13] <cradek> I wonder is it just a 60 degree V
[15:51:17] <archivist> * archivist would like to see how
[15:51:21] <Ziegler> I would think so
[15:51:26] <archivist> cos a screw is a screw
[15:52:03] <cradek> would need lots of relief, probably should be much smaller than the hole
[15:52:35] <Ziegler> right
[15:52:52] <cradek> http://www.use-enco.com/CGI/INPDFF?PMPAGE=64
[15:52:57] <Ziegler> someone wanted me to thread a cast iron nit that has a 2" diameter hole
[15:52:59] <archivist> ah those internal thread mills, lots of relief
[15:53:00] <Ziegler> nut
[15:53:04] <cradek> sure looks like a V to me
[15:53:26] <cradek> Ziegler: can't get it mounted on a lathe?
[15:53:56] <Ziegler> thats how I will do it, but I was wondering about the thread milling
[15:54:34] <Ziegler> is there a canned cylce in emc for thread milling?
[15:55:23] <cradek> no, just make one helix for each thread
[15:56:12] <cradek> I would use cutter comp so you can measure the resulting thread pitch and tweak it
[15:57:00] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/l2h.xsl: print a warning when a cross-reference wasn't resolved, instead of leaving a bum hyperlink in the output
[15:57:01] <cradek> http://cvs.linuxcnc.org/cvs/emc2/nc_files/useful-subroutines.ngc?rev=1.4
[15:57:20] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/config/ (stepconf-test.png stepconf.lyx): add a screenshot of the 'axis test' pop-up
[15:57:20] <Ziegler> ahhhh
[15:57:22] <cradek> the helical hole milling subroutine might be a nice starting point for you
[15:57:34] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/hal/rtcomps.lyx: include diagram of 3-phase stepping types
[15:57:53] <cradek> take out the full circle at the bottom of the hole, and make a proper exit move that goes to the center of the hole first
[15:58:18] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/gcode/ (main.lyx tool_compensation.lyx): fix refs to radius compensation docs
[16:00:06] <Ziegler> That file is included in examples isnt it
[16:00:11] <cradek> if you have a lathe and a mill you could easily make this cutter out of hardening drill rod
[16:00:38] <Ziegler> This project goes on the list of things to do.
[16:00:58] <cradek> yeah 'fun things to try' is a long list
[16:01:44] <Ziegler> right now I dont think my milling machine has good enough backlash comp
[16:01:54] <cradek> ah
[16:02:04] <cradek> seems like it would have to be pretty tight to get an acceptable thread
[16:02:09] <Ziegler> I could over size the hole a bit to "make it work"
[16:02:25] <Ziegler> Z backlash is good
[16:02:45] <Ziegler> especialy since it would be going in one direction through the operation
[16:03:03] <cradek> yeah Z isn't the problem
[16:03:32] <Ziegler> but I would get a slightly elliptical hole... which wont be a problem if the screw going into it is small enough
[16:03:46] <Ziegler> but it would be a sloppy screw
[16:09:05] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/lyxtree.py: improve formula appearance and get rid of call to 'mogrify'
[16:09:36] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/motion/pid_theory.lyx: use equations to get subscripts P_{c} and so on
[16:10:33] <Ziegler> time to go play... bbl
[16:34:19] <[1]a-l-p-h-a> [1]a-l-p-h-a is now known as a-l-p-h-a
[17:30:52] <CIA-8> 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-6.06/usr/share/applications/emc2-stepconf.desktop: it's confusing to have 2 entries labeled EMC2 on the menu
[17:58:29] <mountjulep> anyone here work with legos?
[17:59:39] <Jymmmm> Only the plastic kind, no electronics
[18:04:18] <alex_joni> mountjulep: what kind?
[18:05:13] <Jymmmm> I installed this in FF last night, works pretty cool... http://adblockplus.org/en/
[18:08:04] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/ (Submakefile l2h.xsl lyxtree.py xref.xsl): previous/next/up links from html doc to doc
[18:08:21] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/docs.xml: previous/next/up links from html doc to doc
[18:15:18] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/ (Submakefile index.foot index.tmpl): improve html index
[18:16:03] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/Submakefile: fix typo
[18:21:10] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/ (Submakefile l2h.xsl xref.xsl): html style tweaks
[18:23:11] <CIA-8> 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-5.10/emc2.files: install emc2-stepconf.desktop on all platforms
[18:23:12] <CIA-8> 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-5.10/usr/share/applications/emc2-stepconf.desktop: install emc2-stepconf.desktop on all platforms
[18:23:13] <CIA-8> 03alex_joni 07TRUNK * 10emc2/debian/extras-sim-Ubuntu-6.06/usr/share/applications/emc2-stepconf.desktop: install emc2-stepconf.desktop on all platforms
[18:23:13] <CIA-8> 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-7.10/usr/share/applications/emc2-stepconf.desktop: install emc2-stepconf.desktop on all platforms
[18:23:16] <CIA-8> 03alex_joni 07TRUNK * 10emc2/debian/extras-sim-Ubuntu-5.10/usr/share/applications/emc2-stepconf.desktop: install emc2-stepconf.desktop on all platforms
[18:23:19] <CIA-8> 03alex_joni 07TRUNK * 10emc2/debian/extras-sim-Ubuntu-6.06/emc2.files: install emc2-stepconf.desktop on all platforms
[18:23:22] <CIA-8> 03alex_joni 07TRUNK * 10emc2/debian/extras-sim-Ubuntu-5.10/emc2.files: install emc2-stepconf.desktop on all platforms
[18:43:58] <leeleatherwood> Does anyone work with ACE? Is it possible to get it to take tool diameter into account?
[18:44:28] <skunkworks> not that I am aware of.. It only takes a dxf file and converts the lines/arcs to gcode.
[18:45:45] <leeleatherwood> yeah :( Good simple program, would be great for PCBs, lasers and plasma cutting possibly but not for milling
[18:48:30] <alex_joni> you can let emc2 take care of tool diameter
[18:48:38] <jepler> that's doubtful
[18:48:48] <alex_joni> if it's a really simple dxf
[18:48:57] <alex_joni> and you like handchanging the output from axe
[18:49:01] <jepler> you'd have to carefully create your shapes, at any rate, to avoid the "convex" and "gouging" messages
[18:49:02] <alex_joni> ace even
[18:49:04] <jepler> er, "concave"
[18:50:30] <davidf> leeleatherwood, hi, I'm working with ACE right now. I just have the community edition binary that comes with Ubuntu.
[18:51:09] <jepler> emc2's cutter radius compensation docs: file:///users/jepler/emc2-src/docs/html/gcode_tool_compensation.html#sec:Cutter-Radius-Compensation
[18:51:13] <jepler> er, wrong URL
[18:51:24] <davidf> oops. I mean QCad. Sorry.
[18:51:30] <jepler> http://linuxcnc.org/docs/devel/html/gcode_tool_compensation.html#sec:Cutter-Radius-Compensation
[18:51:41] <davidf> I am using ACE also though.
[18:54:17] <CIA-8> 03alex_joni 07TRUNK * 10emc2/bin/.cvsignore: silence
[18:54:47] <davidf> leeleatherwood: I just draw offset lines in Qcad after drawing the part to size and save the offset drawing as the tool path, then run it through ACE.
[18:58:29] <davidf> Is anyone here using QCad professional edition, and do you know if it will it run on ubuntu 6.06?
[18:58:53] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/ (l2h.xsl xref.xsl): improve appearance of toc and xref index
[19:01:47] <Ziegler> http://images.myonlinesite.com/cnc_mill/ball_cage/ball_cage.jpg <<< couldnt find a small ball mill, but not bad.
[19:01:47] <Ziegler> http://images.myonlinesite.com/cnc_mill/ball_cage/videos.html <<< video a bit worthless
[19:02:56] <jepler> davidf: looks like you can download demo of the QCad professional edition here: http://www.qcad.org/qcad_downloads.html -- it says it supports "Ubuntu 5.1" which says two things to me: It's likely to work, and that they don't know about Ubuntu version numbers.
[19:03:41] <Ziegler> you can download qcad cam... if you can work fast enough I have used it to generate some code
[19:04:19] <Ziegler> I think they let you use it for 20 minutes at a time
[19:04:50] <davidf> jepler, hah. That's what I thought too. I'm not very good at installing from tarballs though.
[19:05:10] <Ziegler> I thought it was just a binary
[19:05:30] <Ziegler> download the tar ball and extract it to a sub directory
[19:05:35] <Ziegler> then just run it from the directory
[19:05:42] <skunkworks> Ziegler: you used my gcode? from here? http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Oword#Sample_1_One_side_of_a_ball_in_cage
[19:05:54] <Ziegler> sure did skunkworks
[19:05:56] <davidf> hope that's right! I thought it was source.
[19:06:00] <Ziegler> thanks for that
[19:06:01] <skunkworks> Cool :)
[19:06:25] <skunkworks> I never put in the effort to find a longer ball end mill either :)
[19:06:50] <Ziegler> skunkworks: I have been wanting to try that code out for about a year... before I even had my first machine
[19:06:59] <skunkworks> http://www.sokolik.com/
[19:07:25] <skunkworks> that is as far as I have gotten :)
[19:07:26] <Ziegler> my end mill was long enough... It just didnt have a ball on it :-\
[19:07:35] <Ziegler> how come you didnt finish i up?
[19:07:44] <skunkworks> too many projects.
[19:08:04] <Ziegler> how many sides are left in that pic?
[19:08:11] <Jymmmm> 6
[19:08:12] <skunkworks> 2
[19:08:25] <Ziegler> aw... another 10 minutes
[19:08:56] <Ziegler> I was going to do it in aluminum...
[19:08:56] <Jymmmm> skunkworks: 2?! You are a lazy bastard!
[19:08:58] <skunkworks> I didn't have an easy way to hold it.. you almost have to make a female pattern so the ball is held
[19:09:16] <Jymmmm> skunkworks: never heard of silly putty?!
[19:09:19] <Ziegler> but I dont know what my machine can handle
[19:09:37] <Ziegler> yeah... skunk... also... those tabs look like they might hold it
[19:09:43] <skunkworks> I remember trying a foam like substance..
[19:10:18] <Ziegler> I bet the tabs are enough
[19:11:20] <Jymmmm> skunkworks: I bet you could make some jig with set screws
[19:11:29] <Jymmmm> like set screws I mean
[19:11:42] <Jymmmm> thumb screws more like it.
[19:11:49] <Ziegler> skunkworks: are those tabs still attaching the ball to the cage?
[19:13:00] <skunkworks> barely
[19:13:21] <Ziegler> set screws idea sounds better then :-P
[19:21:52] <Jymmmm> skunkworks: Yeah, give away the ball cage gcode for free, but charge $100 to the gcode to make the jig =)
[19:22:05] <skunkworks> heh
[19:22:36] <Jymmmm> skunkworks: I bet you at least one person will but it.
[19:22:41] <Jymmmm> buy
[19:23:58] <Ziegler> skunkworks: along with the ball cage idea... I plan to do some (simple) code to crave out a wooden chain
[19:27:47] <skunkworks> Ziegler: cool
[19:28:25] <Ziegler> especially if I can rig up a 4th axis
[19:29:31] <Jymmmm> I watched how chain was made on "How it's Made", very interesting I thought.
[19:30:06] <skunkworks> Ziegler: Do you have a tungstin carbide wedding ring?
[19:30:28] <Ziegler> LOL... no.. white gold
[19:30:40] <Ziegler> I do have a stainless steel ring on the other hand though
[19:30:58] <Ziegler> America's version of the "iron ring"
[19:31:08] <skunkworks> heh - I showed your picture to a coworker and they thought it was me.
[19:31:23] <skunkworks> they keep wanting me to finish one.
[19:32:00] <Ziegler> I was thinking about adding some code to it so I can do multiple passes in aluminum
[19:32:15] <Ziegler> instead of full depth first pass
[19:32:22] <skunkworks> yes - that would be cool
[19:32:30] <Ziegler> ( http://en.wikipedia.org/wiki/Iron_Ring)
[19:32:43] <skunkworks> I made the code and it seemed to work... and that is as far as I got.
[19:32:58] <Ziegler> it works great by me
[19:33:27] <skunkworks> my wife got me a tungsten carbide ring.. as she thought it was 'me'
[19:33:35] <Ziegler> im still not very confident at how aggressive I can take cuts in aluminum and steel with my machine
[19:33:50] <Ziegler> very cool
[19:33:57] <skunkworks> http://www.electronicsam.com/images/ring.JPG
[19:34:15] <Ziegler> wow... bet that sucker doesnt have a scratch on it
[19:34:37] <skunkworks> http://www.electronicsam.com/images/woodcube.jpg
[19:34:38] <skunkworks> not yet
[19:35:10] <Ziegler> how many "steps" did you do that with... and what are the dimensions on it?
[19:36:16] <skunkworks> I would have to look. it was either 1 or 1.25
[19:36:41] <skunkworks> I don't remember what degrees of resolution it was.
[19:37:23] <skunkworks> probably 1 or less
[19:37:34] <Ziegler> I used 3... still looks ok with the end mill I was using
[19:37:58] <skunkworks> that was black walnut iirc
[19:38:28] <Ziegler> ahh.. cut off of a 2x4 here
[19:39:38] <Ziegler> dang saw dust has my y screw squeeking now
[19:40:24] <davidf> ziegler, jepler: I downloaded Qcad pro demo & it is a binary. Works fine so far. Can't save though. Guess I'll buy it. Thanks!
[19:40:33] <Ziegler> davidf:
[19:40:41] <Ziegler> you dont need to save... you can export the code
[19:41:22] <davidf> ah... but I'll have to finish in one ten minute session though.
[19:41:44] <davidf> Now I see why you said "if you can work fast..."
[19:41:45] <Ziegler> finish how? You regular q-cad for drawing
[19:42:01] <Ziegler> then use cam version to export to g-code
[19:42:10] <davidf> ?
[19:42:27] <Ziegler> do you have the comunity version of q-cad installed?
[19:42:36] <davidf> yes.
[19:42:41] <anonimasu> hot glue.. :P
[19:42:40] <davidf> Older one.
[19:42:44] <Ziegler> use that to draw in.. .no time limit
[19:43:12] <Ziegler> then open that drawing file in the CAM binary you just got isntalled
[19:43:35] <davidf> & then export g code?
[19:43:40] <Ziegler> yup
[19:43:59] <alex_joni> or use a time-dillatation field
[19:44:10] <Ziegler> whats that alex_joni?
[19:44:17] <alex_joni> dilation
[19:44:21] <davidf> I see... I didn't even realize the cam program was included. I thought it was a separate program for more $.
[19:44:33] <alex_joni> http://en.wikipedia.org/wiki/Time_Dilation_Device_(Stargate)
[19:44:34] <davidf> yeah, what's that?
[19:44:36] <Ziegler> ah haha
[19:44:55] <Ziegler> davidf: there is a cam version to download as a demo
[19:44:59] <alex_joni> The device was first used by the Asgard to trap the Replicators in a time bubble where time was slowed down by a factor of 10^4 relative to the outside of the time bubble.
[19:45:35] <davidf> Oh yeah, of course, why didn't I think of that? :)
[19:45:38] <Ziegler> http://www.ribbonsoft.com/camexpert_downloads.html
[19:46:00] <alex_joni> 10^4 minutes is a lot of time :D
[19:46:44] <davidf> Yeah, but I work slow...
[19:47:00] <alex_joni> still..
[19:47:03] <Ziegler> alex_joni: in reality... I wonder if you could write a script to keep setting your system time back 10 minutes while you were using the program and get away with it
[19:47:23] <Ziegler> they were probably smarter than that
[19:47:24] <alex_joni> Ziegler: just use a virtual machine
[19:47:29] <alex_joni> install it in there
[19:47:34] <Ziegler> ah yeah
[19:47:40] <alex_joni> then fuss with the clock of the vm from an outside script
[19:48:11] <Ziegler> or I supose you could start the program and reset your time back a day earlier
[19:48:45] <alex_joni> I bet that won't work
[19:48:52] <Ziegler> mee too
[19:49:07] <alex_joni> but resetting the time from outside every second will definately be a possibility
[19:50:36] <Ziegler> in any case.. .CAM expert... not the most user friendly...
[19:50:43] <lerman__> man strace
[19:51:00] <anonimasu> :9
[19:51:00] <Ziegler> but fairly easy to gen some g-code in the time allowed
[19:51:11] <alex_joni> STRACE(1)
[19:51:27] <lerman__> Will tell you all system calls that are made. Run the program let it force the exit and then see what call it made just prior to that.
[19:52:27] <alex_joni> anonimasu: sweden was hotter than expected
[19:52:40] <lerman__> Then patch the executable to use your own version of that call and kludge a work-around.
[19:52:50] <alex_joni> (if you can call 12C hot)
[19:52:55] <lerman__> Of course, that would be *wrong*.
[19:53:01] <anonimasu> alex_joni: really?
[19:53:05] <skunkworks> heh
[19:54:27] <Ziegler> hey... how hot is too hot for steppers?
[19:54:40] <davidf> Qcad pro : 24 euro -- Cam Expert: 149 euro.. I'll probably stick with qcad & ace I think. Ace does fine for the stuff I do anyway.
[19:55:04] <Ziegler> davidf: Ace runs in linux?
[19:55:13] <davidf> Ziegler, I think around 100 C
[19:55:25] <davidf> Yes, ace can be run in linux.
[19:55:29] <Ziegler> 100 C... 212 F ?
[19:55:42] <davidf> But you need to do a couple simple tricks.
[19:55:51] <Ziegler> wine?
[19:56:16] <Ziegler> got a link davidf
[19:56:26] <davidf> right. and also, run linuc2dos on the dxf file prior to loading it into ace.
[19:56:47] <davidf> that's all you need to do.
[19:57:12] <davidf> Link, like a how-to? no, I just farted around till I figured it out.
[19:57:13] <Ziegler> ahh.. new lines?
[19:57:20] <davidf> yup.
[19:57:22] <Ziegler> link to the website
[19:57:32] <Ziegler> for ace
[19:57:40] <davidf> just a sec...
[19:58:02] <Ziegler> So steppers can run really hot then without worry?
[19:58:22] <davidf> http://www.dakeng.com/ace.html
[19:58:38] <Ziegler> thanks davidf
[19:58:43] <anonimasu> um
[19:58:46] <davidf> re the temp, let me check the specs on mine. Gimme a minute...
[19:58:46] <Ziegler> ah... I have used that
[19:58:50] <anonimasu> when they get too hot you notice it.
[20:00:28] <Ziegler> ahh.. davidf the difference between ace and q-cad... q-cad isnt just a converter you get some flexibility in theorder of how lines are cut... and other minor cam options
[20:04:53] <davidf> yeah, i know... but ace does fairly well if you draw the part in the order you want.
[20:05:01] <davidf> http://www.web-tronics.com/costmo.html re temp...
[20:05:12] <davidf> 110 C max.
[20:09:22] <davidf> Ziegler, thats not my motor, just googled stepper motor temperature, & that was first one I saw... but they can get pretty hot witout damage. I try to run mine below the "pain" point. Like a coffee pot seems to be fine.
[20:10:02] <Ziegler> good to know...
[20:10:18] <davidf> But with my little desk top lathe & mill, I don't need much oompf anyway so its not an issue really for me.
[20:10:18] <Ziegler> I have never run over 24 volts before.. now I am running at 48
[20:10:25] <Ziegler> bit a of a temp difference
[20:10:42] <anonimasu> I ran mine at 80v before..
[20:10:47] <anonimasu> 84..
[20:10:48] <Ziegler> speedy?
[20:10:51] <davidf> My zeta 4's run at 90 volts. way cool.
[20:10:54] <anonimasu> I chickened out..
[20:10:59] <Ziegler> LOL
[20:11:00] <anonimasu> that's pushing the geckos.
[20:11:51] <Ziegler> I may take mine up to 60.. but I need a new power supply first
[20:12:15] <davidf> http://www.compumotor.com/literature/pg110_zeta_family.htm
[20:12:28] <lerman_> lerman_ is now known as lerman
[20:12:46] <Ziegler> thanks davidf
[20:12:56] <davidf> zeta 4's are really neat - they run directly off the power line, no xfrmr
[20:14:14] <davidf> $1100 new, but you can find them on ebay for $100 - I got one for $98 and bought 4 more buy it now, $200 each. Got carried away, but I've neber regretted it.
[20:14:33] <Ziegler> WOW
[20:14:34] <davidf> no, not neber. LOL
[20:14:44] <Ziegler> lol
[20:16:46] <davidf> hmm... this looks interesting... http://cgi.ebay.com/PARKER-COMPUMOTOR-LAST-CHANCE-PRICE-DROPPED_W0QQitemZ320167029928QQihZ011QQcategoryZ78195QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
[20:22:29] <davidf> Bought mine about 2 years ago. Looks like they are higher now. But keep looking, untested ones may go real cheap. Parker engr told me that usually if there is any problems, it is just the rectifier diodes, so probably a simple fix?
[21:07:03] <CIA-8> 03alex_joni 07TRUNK * 10emc2/TODO: couple more todo's before 2.2.0
[21:57:51] <CIA-8> 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: oops, uvw jogwheel stuff
[22:46:35] <a-l-p-h-a2> a-l-p-h-a2 is now known as a-l-p-h-a
[22:49:51] <toast> the 12' horizontal milling machines look very cool
[22:50:59] <toast> from cinci
[23:01:22] <ds2> that's ', not a typo?
[23:17:55] <Ziegler> Hey... what sort of oil do you use to protect your machines when you are done using them for the day?
[23:18:13] <Ziegler> (looking for recommendations, and things to avoid)
[23:19:06] <SWPadnos> I use condensation. Once it forms a protective and attractive layer of rust, you don't notice any more damage
[23:20:13] <Ziegler> heh
[23:20:45] <Ziegler> That seems like the process the previous owner of my mill used
[23:21:05] <SWPadnos> sadly, it's the process the current owner of my mill is using :(
[23:21:09] <Ziegler> LOL
[23:21:37] <Ziegler> I just spent the past couple hours steel wooling with some wd-40.
[23:21:51] <cradek> if I intend to leave something precisely ground (like the vise or rotary table) for a while, I spray it with WD
[23:21:52] <Ziegler> It looks better
[23:22:16] <SWPadnos> yeah. when I have the time (TM), I'll get out there with the wire brush and oily things
[23:22:28] <cradek> WD has a new? misty spray can that's for lightly coating large surfaces
[23:22:28] <SWPadnos> at the moment, it looks like that will be in 2097 or so
[23:22:50] <Ziegler> Ill take a look at it
[23:23:02] <cradek> I just "stored" the rotary table on a piece of wood on the floor, so I sprayed it pretty good
[23:23:12] <cradek> (I bet it'll be there for a while)
[23:23:21] <Ziegler> heavy?
[23:23:29] <cradek> yeah very
[23:24:05] <cradek> what I wish I knew is whether my coolant (which is 90-95% water) encourages rust or prevents it
[23:24:14] <SWPadnos> encourages
[23:24:19] <Ziegler> My garage is a bit dark... so I didnt really notice how bad it was until I took a picture of it with a flash... then those pesky spots were very easy to see
[23:24:20] <cradek> figures
[23:24:51] <SWPadnos> one of the features of the lathe I nearly managed to buy was that it had never been run with coolant, always with cutting oil or dry
[23:25:11] <SWPadnos> and it was absolutely clean and new looking
[23:25:11] <Ziegler> so it was in fairly good shape
[23:25:13] <Ziegler> nice
[23:25:14] <SWPadnos> spotless
[23:25:30] <cradek> 'They have excellent rust-preventive properties, both are inhibited against foaming, and both are versatile products suitable for a wide range of metal cutting and grinding operations.'
[23:25:32] <SWPadnos> you could have eaten off the tooling plate, if you like the spicy aroma of cutting oil
[23:25:57] <SWPadnos> that's likely anti-rust for the tank, not the machine
[23:26:02] <SWPadnos> which gets a lot more exposure to air
[23:27:02] <SWPadnos> it's possible that the water parts would dry, leaving a protective film, but I'd think that overall it's worse than no water at all
[23:27:13] <Ziegler> is that 95% watter stuff the same as the bio-degradable stuff?
[23:27:28] <SWPadnos> you mix a lot of coolants 10 or 20 to 1
[23:27:35] <cradek> I'm using "kutwell 40"
[23:27:48] <cradek> it seems to work well and it's not too offensive
[23:28:31] <cradek> came recommended by a local "lubrication specialist" (I swear that's what his card says)
[23:29:10] <ds2> is the company "Escorts Inc"?
[23:29:38] <cradek> I bet he's never heard that kind of joke before
[23:31:29] <ds2> I think taig uses ATF for their rust preservative
[23:34:22] <Ziegler> alcohol tobacco and firearms
[23:34:48] <Ziegler> sound like a marry Poppins song
[23:46:45] <crotchetyGuy> cradek: those coolants will leave an oil film. We always mop up the spills immediately because if you wait, you have pure oil on the floor.
[23:47:02] <toast> ds2: from way earlier, no, the ' isn't a typo
[23:48:18] <crotchetyGuy> recently took off a haas 5c indexer that had been bolted to the table continuously for over 6 years. I expected it to be rusted on, but it just had some slight discoloration.
[23:49:21] <toast> was the bottom flat?
[23:49:31] <toast> that is pretty darn impressive
[23:54:45] <crotchetyGuy> not as good as pure oil, I suppose, but our 1997 era haas's have very little rust anywhere.

#emc | Logs for 2007-10-08