#emc | Logs for 2007-07-03

Back
[01:28:22] <toastydeath> http://www.youtube.com/watch?v=6wK87SMAgWQ
[01:28:25] <toastydeath> cnc screw machine
[01:29:33] <Skullworks-PGAB> toastydeath: i am reading up on suturing
[01:29:54] <Skullworks-PGAB> go buy some medical grade crazy glue
[01:31:12] <toastydeath> that's probably another valid alternative
[01:32:46] <toastydeath> that thing is trick though
[01:33:18] <toastydeath> i've never seen a manual screw machine that cutoff on the first operation
[01:33:43] <toastydeath> or could do both sides of the workpeice
[01:33:58] <cradek> in a machine with Z and W axes, what is the convention, if there is one, for the positive/negative directions?
[01:34:12] <toastydeath> Z- is always towards the spindle
[01:34:16] <toastydeath> er
[01:34:19] <toastydeath> that's exactly opposite
[01:34:32] <toastydeath> hold on, there is a convention
[01:34:36] <toastydeath> and i have confused myself
[01:34:54] <toastydeath> in milling, z- goes into the part
[01:34:55] <cradek> what I mean is this I guess: I can drill by moving Z -. Can I also drill with W- or W+?
[01:35:08] <toastydeath> you should be able to, yes
[01:35:12] <cradek> haha
[01:35:14] <cradek> I mean which one
[01:35:19] <toastydeath> w-
[01:35:55] <cradek> so on a knee mill Z+ moves the quill UP, but W+ moves the knee down?
[01:36:24] <toastydeath> on a bridgeport, it doesn't work that way
[01:36:27] <toastydeath> on a cnc mill, it does work that way
[01:36:38] <toastydeath> i was thinking you had a boring mill
[01:36:41] <Skullworks-PGAB> (BOSS)
[01:36:59] <toastydeath> for bridgeport-type cnc machines, there is no convention
[01:37:15] <toastydeath> everybody seems to do whatever the hell they please
[01:37:31] <toastydeath> but on big machines, z- will plunge you into the part
[01:37:31] <toastydeath> always
[01:37:39] <cradek> yes I know that part
[01:37:45] <toastydeath> w- will as well.
[01:37:48] <cradek> it's the sign of W that I'm asking about
[01:38:05] <cradek> ok
[01:38:41] <toastydeath> Z and W also work the same way on lathes
[01:38:44] <toastydeath> they both go into the part.
[01:38:50] <cradek> so say I am at x0y0z0w0 in normal feed mode
[01:38:52] <cradek> I have a drill bit in the spindle
[01:39:09] <toastydeath> tru
[01:39:10] <cradek> if I program z-1 w-1 f10, I know I'll end up two inches in the part
[01:39:18] <toastydeath> yep
[01:39:27] <cradek> what is the apparent feed rate? is it 10 or 20 or something else?
[01:39:29] <toastydeath> 20
[01:39:52] <cradek> ok so xyz moves at 10, and uvw moves so as to start and stop with it (like abc also do)
[01:40:01] <toastydeath> also so you know, many machines will lock one axis down
[01:40:02] <toastydeath> when the other is moving.
[01:40:11] <cradek> sure I know this is atypical 'coordinated motion'
[01:40:17] <toastydeath> sure
[01:40:39] <cradek> so you know of no machine that would drill that part at an apparent 10ipm?
[01:40:46] <toastydeath> no sir
[01:40:53] <cradek> excellent, that makes my life easier
[01:40:54] <toastydeath> you commanded two seperate axes to move
[01:40:57] <toastydeath> they're gonna do what you tell em
[01:41:21] <cradek> well that's not the whole story though. when you command x1y1f10, the apparent feed is actually 10
[01:41:20] <toastydeath> to be honest, i don't know of any machine that would let you execute a simultanious Z and W move
[01:41:29] <toastydeath> unless you are talking dual turrets on a lathe
[01:41:45] <toastydeath> like machines with index tables lock out all axes when you tell them to index
[01:41:50] <toastydeath> so you don't try to mill
[01:41:56] <Skullworks-PGAB> cradek: ok so xyz moves at 10, and uvw moves so as to start and stop with it (like abc also do) - would be correct for Wire cutting
[01:42:13] <cradek> that's ok, it doesn't matter if nobody uses it, I just want it to be sane
[01:44:40] <cradek> how about arcs in UVW? is there such a thing?
[01:44:48] <toastydeath> uh, for edm
[01:44:53] <toastydeath> and for dual turret lathes
[01:44:54] <cradek> they are orthogonal, so I imagine it's possible
[01:45:17] <cradek> hmm, maybe I'll think about that "later"
[01:45:26] <toastydeath> lol
[01:45:32] <toastydeath> you should treat UVW as it's own seperate deal
[01:45:51] <toastydeath> except on single turret lathes, because UVW on single turrets is incremental motion
[01:45:57] <Skullworks-PGAB> Cradek - also RE: Axis naming - There is also the lathe condition where the spindle becomes a C axis.
[01:46:19] <cradek> Skullworks-PGAB: yes I've seen that, and I think I've seen coordinated CW (for instance) moves
[01:46:41] <cradek> (with a milling cutter in W)
[01:46:43] <toastydeath> C axis is more for milling operations
[01:46:47] <cradek> right
[01:46:54] <Skullworks-PGAB> live tooling
[01:47:10] <toastydeath> but again if it's a single turret
[01:47:27] <toastydeath> W is going to be an incremental axis
[01:47:31] <Skullworks-PGAB> ALSO the UVW would be used for a hot wire foam cutter.
[01:47:45] <toastydeath> lol
[01:48:26] <cradek> ok, I think making an axis incremental is a separate problem from what I'm working on, but I'll keep it in mind
[01:48:42] <toastydeath> well i guess i am kind of saying "the lathe part of emc is broken"
[01:48:47] <toastydeath> insofar as usability
[01:49:03] <toastydeath> and uvw breaks it further
[01:49:07] <toastydeath> insofar as conventions go
[01:49:19] <toastydeath> not that i have any room to bitch about it since i'm not a dev
[01:49:35] <Skullworks-PGAB> foam cutters are a popular DIY machine - problem is most CAD/CAM want to drive the wire cutter controller directly - instead of outputting useable G-code.
[01:49:58] <cradek> I don't follow you toastydeath. how can the uvw be broken for lathes when uvw is not accepted at all yet?
[01:50:17] <toastydeath> that would sum it up partially, right there
[01:50:31] <toastydeath> but what you're suggesting, if UVW were to become live
[01:50:35] <toastydeath> would break "lathe" further
[01:50:42] <cradek> Skullworks-PGAB: I've noticed that, but changing that output to usable gcode (using inverse time mode) is pretty trivial
[01:51:05] <cradek> toastydeath: explain again howso, I must be slow
[01:51:18] <toastydeath> like, most (if not all) of our stuff involves UVW moves
[01:51:23] <toastydeath> on the lathes
[01:51:31] <toastydeath> single turret
[01:52:11] <toastydeath> and a lot of the EMC control stuff that has been implemented is very much mill specifif
[01:52:13] <Skullworks-PGAB> for radius definition or incremental axis moves?
[01:52:21] <toastydeath> incremental axis moves
[01:52:28] <toastydeath> *specific
[01:52:29] <Skullworks-PGAB> ah
[01:52:30] <cradek> what's an incremental axis move
[01:52:36] <cradek> I'm still not getting you
[01:52:46] <toastydeath> XYZ moves the turret in absolute mode
[01:52:57] <toastydeath> z-4.0 three times in a row will move once and stop
[01:53:13] <toastydeath> w-4.0 four times in a row will execute four moves that move the turrent -4.0 inches/mm/whatever
[01:53:48] <cradek> z-4.0w-4.0 four times moves z once at first, but w each time?
[01:53:55] <toastydeath> yes
[01:54:08] <toastydeath> every time you call UVW, it pretends it's at 0
[01:54:12] <cradek> wow, how insane
[01:54:12] <toastydeath> it's not
[01:54:21] <toastydeath> it's very useful, especially for coding out machine errors and looping
[01:54:24] <Skullworks-PGAB> think of U/W commands as automatic G91 one shot moves without ever going to G91
[01:54:35] <toastydeath> when you didn't buy the expensive macro package
[01:54:37] <cradek> but you wouldn't expect a mill to ever do that, right?
[01:54:42] <toastydeath> nope
[01:54:45] <toastydeath> but you demand a lathe does
[01:54:53] <cradek> * cradek grumbles
[01:55:21] <toastydeath> because lathe code is a lot more repetative than mill code (usually)
[01:55:36] <toastydeath> and it helps out a loooot
[01:55:52] <toastydeath> especially since emc doesn't support roughing/finishing cycles
[01:56:09] <cradek> I can accept it's a standard behavior, but I doubt I'll be convinced that it's not insane
[01:56:25] <toastydeath> we have a machine
[01:56:33] <toastydeath> it has like, a four thou taper
[01:56:33] <toastydeath> per foot
[01:56:43] <toastydeath> rather than trig everything out
[01:56:56] <cradek> I had a guy tell me last week he doesn't give two shits about roughing cycles because nobody writes gcode by hand in a real shop, and no cam uses it
[01:57:09] <toastydeath> ironic, because a lot of "real shops" still do nothing but hand coding
[01:57:19] <Skullworks-PGAB> yep
[01:57:28] <toastydeath> because it is forever and always faster and more flexible than cam
[01:57:31] <cradek> (well not his, and it looked pretty real to me)
[01:57:35] <toastydeath> until you get into the huge parts you can't hand code easily
[01:57:51] <toastydeath> but many places use macro programming
[01:57:54] <toastydeath> rather than cam
[01:57:55] <cradek> I just report the news :-)
[01:58:35] <cradek> my stake in it is: I write my lathe gcode by hand, so it would be nice
[01:58:37] <cradek> that's all
[01:58:44] <toastydeath> me too =(
[01:58:56] <cradek> I'm getting distracted, thanks for your input guys
[01:58:55] <Skullworks-PGAB> I use a CAD/CAM but the final code looks almost nothing like what the POST spit out. - I hand "message" everything for optimal use.
[01:59:28] <toastydeath> np cradek
[02:05:18] <cradek> one last thing - would you expect to be able to cut a helix with e.g. G17 G3 X Y I J W F?
[02:05:27] <cradek> or is that just crazy talk
[02:06:32] <Skullworks-PGAB> nope
[02:06:52] <cradek> or more perverse: G3 X Y I J Z-1 W-1
[02:06:57] <Skullworks-PGAB> W should be Z in that under normal use
[02:07:35] <cradek> so "you can't move UVW coordinated with an arc" would be sane and typical?
[02:08:06] <toastydeath> well
[02:08:11] <toastydeath> in a two turret lathe..
[02:08:28] <toastydeath> i am kidding, you shouln't/cant coordinate moves like that
[02:09:16] <cradek> ok, I think I'll allow it, but it will have the same feed problem as G1 Z-1 W-1 F10
[02:09:49] <Skullworks-PGAB> but again - if someone had dual axis - like a bridgeport with both quil and knee feed - you might need to use both to reach required depth - but I would think it could be split into 2 seperate command lines
[02:10:17] <cradek> I agree
[02:10:23] <toastydeath> i would drop the spindle to the depth i needed
[02:10:28] <toastydeath> and use Z to do the contouring
[02:11:00] <toastydeath> someone is going to die doing that on a bridgeport
[02:11:04] <cradek> then look for the crank that's probably under something...
[02:11:06] <toastydeath> synched Z/W moves
[02:13:46] <Skullworks-PGAB> I think the safest bet would be to restrict that type of movement until someone comes up with a application that requires it
[02:14:22] <toastydeath> like, on applications that have two heads, like dual lathes
[02:14:23] <cradek> a lot of things are handled at the low levels, but forbidden nearer the user, this could be one of them if necessary
[02:14:34] <toastydeath> there's a block of g-code that defines each head's movment
[02:14:44] <toastydeath> and then it goes, independent of one another
[02:14:49] <toastydeath> synched by M codes at certain points
[02:14:59] <toastydeath> you don't actually use combined XYZ UVW moves
[02:15:15] <cradek> yeah, that's way beyond the scope
[02:16:05] <tomp> maybe... the parallel axis are used to move the work envelope, the main axis are used to move the tool in the envelope ( so UVW move you into range, and XYZ cut )
[02:16:20] <toastydeath> tomp: that's another m-code synched situation
[02:16:24] <Skullworks-PGAB> this is only for the standard kinematics?
[02:16:40] <toastydeath> where an M-code defines each head's motion, then you hit another m-code and it runs
[02:16:44] <Skullworks-PGAB> not for hexapods or such?
[02:16:54] <toastydeath> as far as i know, yes
[02:17:40] <toastydeath> but then again there's the single turret lathe
[02:17:50] <toastydeath> where you can combine X and W moves to produce relative tapers
[02:18:41] <Skullworks-PGAB> tomp - possible - but why not just use a work offset like g54-g59 to move into the work zone
[02:19:15] <toastydeath> because you still have to move the other axis
[02:19:23] <toastydeath> also, what machine does that
[02:20:23] <Skullworks-PGAB> toasty - I do that every day
[02:20:37] <toastydeath> no, that was a real question
[02:20:39] <toastydeath> i want to know the machine that does that
[02:20:55] <toastydeath> for my own personal machinery knowledge library
[02:20:54] <Skullworks-PGAB> but we just use X+#1
[02:21:09] <Skullworks-PGAB> for taperes
[02:21:11] <toastydeath> you have a stage that moves seperate from the cutting head?
[02:21:19] <tomp> Skullworks-PGAB: my experience with parallel axis was that UVW were 'backslides', and kept the machine envelope stiff rather than using a huge open throat that the tool had to traverse. ( eg: move the knee so the quill isnt extended too far )
[02:21:41] <Skullworks-PGAB> right
[02:21:55] <Skullworks-PGAB> that case was mentioned
[02:22:48] <Skullworks-PGAB> the real quest was more if it would need to be a co-ordinated move
[02:22:52] <Skullworks-PGAB> question
[02:23:01] <toastydeath> ?
[02:23:29] <Skullworks-PGAB> Z W
[02:23:39] <cradek> G10 L2 P1 W10 - is this typically supported?
[02:23:42] <Skullworks-PGAB> move knee then move quill
[02:23:59] <Skullworks-PGAB> no
[02:24:24] <toastydeath> i don't know, that's not g-code i recognize
[02:24:30] <tomp> i've never used ZW coordinated moves, tho it may be useful to 'open up' the machine for inspection' ( not really coordinated, just simultaneous rapids )
[02:24:37] <cradek> it's how you set g54 offset
[02:24:48] <toastydeath> usually machines lock out one or the other axis - Z or W
[02:24:54] <toastydeath> while they move
[02:25:04] <toastydeath> so you can't try countouring with both at the same time and die
[02:25:11] <toastydeath> rapids especially
[02:25:18] <Skullworks-PGAB> G10 L2 P1 is a command that will modify a value in the G54 offset table
[02:25:30] <toastydeath> yar, my machines don't have that
[02:25:37] <Skullworks-PGAB> bet they do
[02:25:45] <toastydeath> i've got the g-code reference manuals for them
[02:25:49] <toastydeath> didn't see it
[02:25:58] <toastydeath> it could be there and i'm just retarded
[02:25:57] <Skullworks-PGAB> unless okuma
[02:26:09] <toastydeath> oh, i thought that set work shift
[02:26:17] <toastydeath> not work offset
[02:26:20] <toastydeath> ohhhhhh
[02:26:21] <toastydeath> ohhh
[02:26:25] <toastydeath> nevermind
[02:26:30] <toastydeath> i am retarded
[02:26:40] <Skullworks-PGAB> cradek - any chance they might do G10 L1 ?
[02:26:59] <cradek> wait let's do my question first
[02:27:07] <Skullworks-PGAB> OK
[02:27:12] <cradek> UVW have work offsets or no?
[02:27:27] <cradek> to me, it seems like they'd have to
[02:27:40] <toastydeath> depends on the machine
[02:28:02] <Skullworks-PGAB> yep machine/application dependant
[02:28:03] <toastydeath> but for the bridgeport example, yeah
[02:28:10] <toastydeath> also for a horizontal boring mill
[02:28:10] <Skullworks-PGAB> and for a wire machine
[02:28:27] <cradek> ok, this project just got worse.
[02:28:39] <toastydeath> emc needs like, machine profiles
[02:28:44] <toastydeath> or an abstraction layer =(
[02:28:55] <Skullworks-PGAB> IT HAS THAT
[02:28:57] <toastydeath> rly?
[02:29:06] <cradek> no, he means for the interpreter
[02:29:18] <Skullworks-PGAB> ok
[02:29:21] <Skullworks-PGAB> got it
[02:29:21] <cradek> like this 'UVW is magically relative on a lathe' insanity
[02:29:23] <toastydeath> i mean so like, you can make the g-code and the axis restrictions behave like a mill
[02:29:29] <toastydeath> or a lathe
[02:29:32] <toastydeath> or a boring mill
[02:29:37] <toastydeath> or a jig grinder.
[02:30:34] <toastydeath> man
[02:30:35] <toastydeath> a jig grinder
[02:30:37] <toastydeath> i don't even know how you would do that
[02:32:29] <tomp> The W that is a backslide and parallel to Z in a mill is not like the U that is parallel to X in a wire edm. The prior is a range , and the latter is a related motion ( i avoid the word relative ). There may be some kinematic description for this parent/sibling idea.
[02:33:16] <toastydeath> backslide?
[02:34:24] <tomp> like on a jig grinder, the spindle motion is less than the motion of the throat adjustment. move the throat close enuf, then cut with the short spindle motion
[02:35:01] <toastydeath> which spindle?
[02:35:32] <toastydeath> i am sure you have a valid point and i have no idea what you are talking about
[02:35:38] <tomp> the big spider handle that moves the jig grindler spindle head closer/further to the table ( Moore or Sipp )
[02:35:42] <toastydeath> ah
[02:35:57] <toastydeath> okay yeah
[02:35:58] <toastydeath> now i am with you
[02:36:01] <Skullworks-PGAB> Toasty - every seen the MAZAK that they retrofit with EMC
[02:36:02] <tomp> the spindle itself just goes up and down a little bit and oscillates
[02:36:16] <toastydeath> i have not seen the mazak, no sir
[02:36:22] <Skullworks-PGAB> hmmm
[02:36:52] <toastydeath> i am like the emc outsider who idles in the channel and asks weird questions everyone hates
[02:37:03] <toastydeath> =)
[02:37:09] <Skullworks-PGAB> well the whole head moves up/down as part of a setup - then cutting is done via quill movement
[02:37:19] <toastydeath> yar, i understand!
[02:37:24] <toastydeath> that makes sense
[02:38:21] <toastydeath> personally i'd want those axes locked out
[02:38:28] <Skullworks-PGAB> now - if someone wanted to add controlled movement to the head - it would be a (backslide if not coordinated) W axis.
[02:38:30] <toastydeath> so i didn't move both at the same time by some stroke of stupidity
[02:38:50] <toastydeath> i was always taught that the spindle was W
[02:38:59] <toastydeath> oh, no i wasn't
[02:38:58] <toastydeath> you're right.
[02:39:34] <tomp> if the axis is used for setup. dont use it for cutting ( it's a "coarse" axis not meant for cutting ) so, dont worry about cutting helixes with a 'setup axis', only with a 'cutting axis'. you can 'control' it, but dont 'contour' it
[02:40:26] <toastydeath> yes
[02:40:29] <toastydeath> exactky
[02:40:31] <toastydeath> *exactly
[02:40:43] <toastydeath> or really you could try to contour with it
[02:40:45] <toastydeath> just don't move W and Z at the same time
[02:41:12] <toastydeath> but it would be so nice to rapid them at the same time, seperately
[02:41:28] <toastydeath> so like one could say "g0 w0 z0.1"
[02:41:34] <toastydeath> and get them both down ready to cut
[02:41:52] <tomp> maybe: G0 is ok for XYZUVWABC but G1 restricted to XYZABC(IJK) ?
[02:42:10] <toastydeath> nar
[02:42:20] <toastydeath> what i would like to see "ideally" is fairly ridiculous
[02:42:26] <toastydeath> i'd like to not see Z and W in the same line
[02:42:34] <toastydeath> UNLESS they are by themselves in a G0
[02:42:43] <toastydeath> to position and retract them
[02:42:51] <toastydeath> but that's ridiculous
[02:43:14] <tomp> why? if they are relegated to rapids, then G0 ZW move that realm faster
[02:43:30] <toastydeath> becaues i don't want to do "g0 x0 z0 w0"
[02:43:39] <toastydeath> ...or do i?
[02:43:46] <toastydeath> sure, restrict it to rapids
[02:43:48] <toastydeath> that would work.
[02:45:51] <tomp> my prev remark should been , dont interpolate coarse axis, and do interpolate cutting axis. and some kins descriptions define which axis are coarse/setup and which are fine/cutting
[02:46:53] <toastydeath> i guess my concern with that is i use the course axis to do most of my milling
[02:47:01] <toastydeath> and i leave the quill up in the machine
[02:47:28] <tomp> cranking the knee?
[02:47:31] <toastydeath> yar
[02:47:35] <toastydeath> keeps it rigid
[02:47:40] <toastydeath> i usually take cuts that break things
[02:47:47] <toastydeath> so i like to have every ounce of rigidity i can get
[02:48:14] <tomp> sometime i do that too , esp when Bport spindle is sticky/sloppy
[02:48:22] <cradek> if that were my habit I'd be very tempted to make the knee Z
[02:48:30] <toastydeath> that's what all our toolmakers do
[02:48:38] <toastydeath> i never see them touch the quill except for boring and drilling
[02:48:51] <toastydeath> and i've broken many cutters by using the quill
[02:49:02] <toastydeath> where they survive knee cuts
[02:51:40] <tomp> the q about G02 XYIJW ... is it just a matter of calling W Z? just 'semantics'? ( some kins definitions the user can play with )? I think you
[02:52:02] <tomp> wont find it disallowed in any book , but you wotn find a single example
[02:52:34] <toastydeath> my beef with that
[02:52:37] <toastydeath> is that it's not defining a single point
[02:52:41] <cradek> it's not about the motion so much as the feed that's the question
[02:53:00] <toastydeath> like, it depends on the mode
[02:53:21] <tomp> ? feed of Z versus W
[02:53:23] <toastydeath> in distance per time, the second head goes to 10 ipm and the first head does too
[02:53:28] <cradek> if you cut a helix in XYZ in G94 your feed is along the helix
[02:53:44] <cradek> if you cut a helix in XYW in G94 is the feed along the helix or along the circle?
[02:53:51] <cradek> (projected circle)
[02:54:12] <toastydeath> why would W be different in that situation
[02:54:12] <cradek> that's the real question in my mind
[02:54:30] <cradek> well you said it was when I asked about G1 Z-1 W-1 F10
[02:54:47] <toastydeath> that's two different movements on the same axis!
[02:55:04] <cradek> you said the W motion is ignored for the feed calculation
[02:55:22] <cradek> well it's true you may not have made this generalization that I did
[02:55:29] <toastydeath> i did not make that generalization
[02:55:36] <toastydeath> it's two seperate equations
[02:55:48] <tomp> (not familiar with G94) i'd think it'd be speed along the path in both cases (imo )
[02:56:01] <tomp> would/should
[02:56:13] <toastydeath> like, XYW and XYZ should behave identically
[02:56:15] <cradek> I'll call it insane again if you tell me it should be a long the helix (tooltip) for G3 XYW, but not G1 ZW
[02:56:22] <cradek> along
[02:56:42] <toastydeath> you need to treat X and W as if they are two seperate heads
[02:57:01] <toastydeath> and that XYZ and XYW are two different points in space
[02:57:52] <cradek> sure but this is about the cartesian feed
[02:58:05] <toastydeath> Z and W are two different cartesian spaces
[02:58:08] <toastydeath> or, are in
[02:58:10] <cradek> either cartesion space is (x,y,z) or (x-u,y-v,z-w)
[02:58:24] <toastydeath> no, there's XYZ and XYW
[02:58:28] <cradek> it can't change depending on the move
[02:58:39] <toastydeath> if you were, say on an unrestricted machine
[02:58:51] <toastydeath> to command "X10 Y10 Z10 W10"
[02:59:05] <toastydeath> you would wind up with double the movement in the absolute Z axis
[02:59:14] <cradek> yes of course
[02:59:22] <toastydeath> and at DOUBLE the rate
[02:59:26] <cradek> and double the feed
[02:59:34] <toastydeath> so i'm confused as to what more you're asking
[02:59:43] <cradek> ok let me explain
[03:00:07] <toastydeath> k
[03:00:20] <cradek> imagine a move g1z-1w-1f10. it takes 1/10 minute right?
[03:00:32] <toastydeath> yes
[03:00:36] <toastydeath> if you are in that mode
[03:00:46] <cradek> it can be g1 z-1 w[anything] f10 and it still takes 1/10 minute right?
[03:00:52] <toastydeath> if you are in inverse time
[03:00:54] <toastydeath> yes
[03:01:01] <toastydeath> not if you are in feed per minute
[03:01:03] <cradek> no, in normal feed mode G94
[03:01:09] <toastydeath> then no, it happens twice as fast
[03:01:20] <toastydeath> in one direction
[03:01:23] <toastydeath> the Z axis
[03:01:29] <toastydeath> and you have some fucked up parts.
[03:01:48] <toastydeath> this is EXACTLY why machines lock this movement out
[03:01:49] <cradek> right, the tooltip motion relative to the work is twice as fast
[03:01:57] <cradek> so it STILL takes 1/10 minute
[03:02:03] <toastydeath> for the other two axes, sure
[03:02:07] <cradek> even though you move twice as far
[03:02:09] <toastydeath> correct
[03:02:20] <cradek> ok I want to be very clear about that
[03:02:37] <cradek> you see how W is ignored for the feed calculation? it can be anything, and the move takes 1/10 minute
[03:02:49] <toastydeath> yeah, i'm seeing that now
[03:03:05] <toastydeath> i see what you want.
[03:03:03] <cradek> ok now let's talk arcs, we have a flat arc in XY that takes 1/10 minute
[03:03:14] <toastydeath> k
[03:03:23] <cradek> I'd give the gcode, but it would have pis in it
[03:03:26] <cradek> so just say we do
[03:03:31] <toastydeath> right, keep it simple
[03:03:41] <toastydeath> i don't want you getting all "g10" on me here.
[03:03:44] <cradek> now add a W move to it, to make it a very deep helix
[03:03:51] <toastydeath> k
[03:04:02] <cradek> the apparent tooltip motion relative to the work will be very fast now
[03:04:09] <toastydeath> yeah
[03:04:12] <cradek> but, the cut will still take 1/10 minute
[03:04:23] <toastydeath> yep
[03:04:45] <cradek> because cartesian feed is in XYZ, but UVW are "along for the ride" (they synchronize, but don't contribute to feed)
[03:04:52] <toastydeath> right
[03:05:04] <toastydeath> it moves hilariously fast?
[03:05:06] <cradek> right.
[03:05:13] <toastydeath> and that's expected behavior.
[03:05:26] <toastydeath> once you move into true 3d space you are supposed to turn on inverse time mode
[03:05:26] <cradek> ok, so do you see that XYZ and XYW arcs *don't* act the same?
[03:05:26] <toastydeath> to solve that problem
[03:05:33] <Skullworks-PGAB> inverse time is a necessary evil
[03:05:46] <toastydeath> like, i would expect the machine to crash or do something bizzare
[03:05:48] <toastydeath> if i were programming that.
[03:05:51] <toastydeath> in feed/minute
[03:06:11] <toastydeath> because the same problem happens in 5+ axis applications
[03:06:14] <toastydeath> right?
[03:06:33] <Skullworks-PGAB> but you almost have to use inverse time for 4th and 5th axis work
[03:06:40] <cradek> well here's the real scoop: I could make XYZ and XYW moves feed the same (tooltip relative to the work). That means g1 x-1 w-1 f10 takes 1/5 minute now, instead of 1/10
[03:06:52] <toastydeath> no, in feed/minute it must move 1/10
[03:06:56] <cradek> ok
[03:06:55] <toastydeath> because that's the mode the programmer has the machine in
[03:07:01] <toastydeath> in inverse time, it must take 1/5
[03:07:02] <cradek> then arcs must not be the same in XYZ and XYW
[03:07:27] <cradek> helixes I mean
[03:07:42] <toastydeath> they need to produce the same behavior
[03:07:44] <toastydeath> is what i am getting at
[03:08:02] <cradek> but the feeds are different!
[03:08:19] <cradek> that's what we've just gone through
[03:08:31] <toastydeath> they need to produce the exact same behavior.
[03:08:43] <toastydeath> if you say XYZ for an arc
[03:08:48] <toastydeath> it needs to produce the same arc as XYW
[03:08:56] <cradek> yes, but at a different feed
[03:09:02] <toastydeath> why?
[03:09:13] <toastydeath> we were talking about XYZW arcs, weren't we?
[03:09:24] <cradek> argh I just spent a half hour explaining it
[03:09:27] <tomp> stop at why & listen
[03:09:32] <toastydeath> k.
[03:11:08] <toastydeath> er?
[03:11:10] <toastydeath> hello?
[03:12:17] <cradek> ok it was only ten minutes, sorry for being dramatic
[03:12:23] <cradek> (I assume tomp is typing)
[03:12:26] <toastydeath> like, i kind of undersand, partly
[03:12:27] <toastydeath> what you are trying to point out
[03:12:47] <toastydeath> but i am saying the expected behavior from the machine
[03:13:07] <tomp> i've been scrolling back at the xy arc turned to xyW arc , both with same F, both with same time, and how that could be bad when the W dimension is large, well the same could be true of XYZ, both could be bad, both could be ok )
[03:13:23] <tomp> the bad would be overloading the tool with either W or Z
[03:13:39] <toastydeath> we are talking freespace toolpath here
[03:13:44] <toastydeath> no part in the machine
[03:14:06] <cradek> toastydeath: I understand clearly what you're saying, but it's inconsistent in such a glaring way that I suspect you're mistaken. No offense meant.
[03:14:26] <toastydeath> the part i'm sure of is that the W and the Z axis
[03:14:31] <toastydeath> move in an identical way
[03:14:43] <toastydeath> when you tell them to cut arcs and helixes
[03:14:45] <cradek> helixes are rare and usually not very deep, so I bet you're mistaken about how the feed works
[03:14:48] <toastydeath> so anything else i've said
[03:14:53] <toastydeath> you can ignore
[03:15:05] <cradek> it would be easy to miss the difference unless the helix is very deep
[03:15:07] <toastydeath> whatever you need to do to get the two helix feeds to be identical
[03:15:31] <toastydeath> but please straighten me out here
[03:15:35] <toastydeath> i may just be too lost to get it
[03:15:46] <cradek> I understand that's what you're saying, but I think you're mistaken
[03:15:52] <toastydeath> but, in a XY plane Z helix and an XY plane W helix
[03:15:56] <toastydeath> why would the two feed rates be different?
[03:16:17] <toastydeath> it's the same axis movement
[03:16:21] <toastydeath> just two different points on the same axis
[03:16:26] <cradek> because Z is part of the cartesian space and W isn't
[03:16:30] <toastydeath> no, that's a mistake
[03:16:45] <tomp> hmmm, 2 joints, one axis
[03:16:45] <cradek> it's got to be that way if G1 z-1 w-1 f10 works how you want
[03:16:45] <toastydeath> yes
[03:16:58] <toastydeath> machines lock out Z-1 W-1
[03:17:02] <toastydeath> you can't move both at the same time
[03:17:09] <toastydeath> it would be nice if you COULD
[03:17:11] <toastydeath> is what i was saying
[03:17:12] <toastydeath> for G0
[03:17:14] <toastydeath> to retract them
[03:17:28] <toastydeath> practically, they never move at the same time
[03:17:45] <toastydeath> and i am really, really sorry for being confusing if that was the whole point of contention
[03:18:14] <cradek> argh, I think it was...
[03:18:37] <toastydeath> but as far as i know, there is zero GOOD reason to move both at the same time
[03:18:48] <toastydeath> except for rapid retract, and that's not a good enough reason to allow someone to crash the machine REALLY bad
[03:20:17] <toastydeath> i'm sorry dude =(
[03:20:30] <toastydeath> i was talking hypothetically =(
[03:20:35] <cradek> 'sokay
[03:21:24] <tomp> i'm interested in these extra axis, but i got a runaway oscillator i gotta uild a trap for ... just logging now :)
[03:21:58] <toastydeath> lol
[03:22:54] <toastydeath> like, when i was talking about what would happen
[03:23:04] <toastydeath> if you were to interpolate a dual Z and W move
[03:23:20] <toastydeath> the W interpolation would be calculated using the ZXW coordinate system
[03:23:23] <toastydeath> and the er
[03:23:27] <toastydeath> XYW
[03:23:31] <toastydeath> and the Z move in XYZ
[03:23:35] <toastydeath> the XY result is the same
[03:23:41] <toastydeath> for both
[03:23:48] <toastydeath> right?
[03:24:26] <toastydeath> if the answer is "no toasty you are high" there is no way to interpolate Z and W at the same time.
[03:24:40] <cradek> I don't understand the question
[03:24:49] <toastydeath> like, you were talking about how W wasn't used
[03:24:56] <toastydeath> in the feed equation
[03:24:58] <cradek> right
[03:25:05] <toastydeath> i am saying you'd have to do the feed equation twice
[03:25:13] <toastydeath> once for XYZ and once for XYW
[03:25:22] <toastydeath> the X and Y results would be identical, correct?
[03:25:46] <toastydeath> my point being if they aren't identical, you can't move them at the same time and one has to wait.
[03:26:04] <toastydeath> The W axis would pretend Z does not exist, for purposes of W axis movement
[03:26:09] <toastydeath> and vice versa
[03:26:28] <cradek> if it's coordinated motion, they would start and stop together
[03:26:35] <cradek> so one moves faster
[03:26:42] <toastydeath> yes
[03:26:44] <cradek> g1 x-1 w-2
[03:26:43] <toastydeath> sort of
[03:26:48] <cradek> w moves twice as fast
[03:26:50] <toastydeath> maybe?
[03:26:52] <toastydeath> correct
[03:26:56] <cradek> err I meant g1 z-1 w-2
[03:27:05] <cradek> the apparent cut is 3"
[03:27:17] <toastydeath> but in your complicated example, you calculate the motion twice
[03:27:22] <toastydeath> and move W as if Z wasn't around
[03:27:24] <cradek> which example?
[03:27:40] <toastydeath> one would finish before the other
[03:27:41] <toastydeath> noncoordinated
[03:27:46] <toastydeath> in feed/minute
[03:27:55] <toastydeath> becaues they're two seperate cartesian systems
[03:28:10] <cradek> no, that would be silly
[03:28:19] <toastydeath> i propose it's only silly from the user perspective
[03:28:38] <toastydeath> if you need them to finish in the same timeframe, you need to use inverse time
[03:28:55] <cradek> silly silly silly
[03:28:58] <toastydeath> why?
[03:29:01] <cradek> why would you not want them to end together?
[03:29:02] <toastydeath> that's how five axis stuff works
[03:29:08] <toastydeath> you DO, but you can't do it in feed/minute
[03:29:14] <cradek> sure you can
[03:29:14] <toastydeath> and preseve two seperate cartesian systems
[03:29:36] <toastydeath> not in feed/minute, man
[03:29:36] <cradek> just like with an XA move, they can start and stop together
[03:29:41] <cradek> sure
[03:29:55] <toastydeath> Z and W think they each have their own tool.
[03:30:08] <toastydeath> they're not coordinating the same point
[03:30:13] <cradek> the units and coordinate systems and everything can be different, they can start and stop together, and anything else is unnecessarily silly
[03:30:27] <toastydeath> you are describing inverse time motion, though
[03:30:56] <toastydeath> and suggesting that you break feed/minute to preseve synchronosity
[03:31:25] <cradek> brb
[03:31:24] <toastydeath> commercial controllers are more than happy to break your tools in the silly way i describe if you leave them in feed/minute
[03:31:28] <toastydeath> k
[03:32:52] <toastydeath> whatever produces the most bizzare and unexpected motion in Z and W is the one that happens in feed/minute
[03:34:23] <toastydeath> hmm
[03:34:27] <toastydeath> no, that's not right either
[03:34:44] <toastydeath> won't the rates be different for XYZ and XYW
[03:34:45] <toastydeath> hmm
[03:34:48] <toastydeath> for x and y, that is
[03:39:51] <toastydeath> you have probably learned never to ask me anything again
[03:39:52] <toastydeath> hahahaha
[03:39:53] <toastydeath> =(
[03:40:01] <cradek> back
[03:40:07] <cradek> haha
[03:40:08] <toastydeath> sawp!
[03:40:38] <toastydeath> but seriously, won't 5 inches/minute for x5 y5 z5 produce a different feed rate for X and Y
[03:40:47] <toastydeath> than X5 Y5 W10
[03:40:49] <toastydeath> say, F5
[03:40:51] <toastydeath> in feed/minute
[03:41:07] <toastydeath> my big problem here is i'm trying to understand your side of things
[03:41:11] <toastydeath> and i'm clearly failing miserably
[03:42:25] <cradek> x5 y5 z5 and x5 y5 w5 are different if cartesian space is (x,y,z). they're the same if cartesian space is (x-u,y-v,z-w).
[03:42:43] <cradek> different feeds
[03:43:01] <toastydeath> but it's not the second one
[03:43:10] <cradek> why not?
[03:43:16] <toastydeath> so it's impossible to move Z and W at the same time, because they both want X and Y to move at different rates
[03:43:49] <cradek> it's clearly not impossible - all we have to do is define the behavior
[03:44:13] <toastydeath> but any attempt to define it would cause a preference
[03:44:18] <toastydeath> of one over the other
[03:44:42] <toastydeath> and it's not clear what the programmer is going to want
[03:45:05] <toastydeath> now i kind of get what you are saying, the 1/10 vs 1/5
[03:45:08] <cradek> if g1z-2f10 and g1w-2f10 and g1w-1z-1f10 should all take 1/5 minute, that's the second kind of cartesian space, and the helixes will also turn out the same
[03:45:36] <cradek> yes we're defining a preference - that's the point - deciding how to do it
[03:45:36] <toastydeath> but that's in inverse time
[03:45:44] <cradek> no!!
[03:45:47] <toastydeath> yar?
[03:45:52] <cradek> 10 inches/minute
[03:45:54] <cradek> 2 inch move
[03:45:59] <cradek> takes 1/5th minute
[03:46:14] <toastydeath> but the "tip" of w wants to move at 10 inches/min
[03:46:19] <toastydeath> the w space
[03:46:21] <cradek> w has no tip
[03:46:24] <toastydeath> it DOES
[03:46:32] <cradek> you're totally missing what I'm saying
[03:46:32] <ds2> what is W?
[03:46:49] <toastydeath> w is a secondary axis along Z
[03:46:52] <cradek> look at g1z-2f10 and g1w-2f10 and g1w-1z-1f10
[03:47:04] <cradek> they both drill the tool 2 inches down into the work right?
[03:47:08] <toastydeath> yeah
[03:47:11] <cradek> sit on the work and watch the tool
[03:47:12] <ds2> Hmm
[03:47:18] <toastydeath> except the last one does it at 20 ipm
[03:47:27] <cradek> it can go past you at 10inches/minute
[03:47:37] <cradek> no, it *CAN* go past you at 10 inches/minute
[03:47:46] <cradek> right? I mean it's possible to program it that way
[03:47:50] <toastydeath> no man
[03:48:02] <cradek> now imagine it's a helix!
[03:48:09] <cradek> arrrgh I need a drink
[03:48:13] <toastydeath> =(
[03:48:34] <ds2> this is on a mill type machine?
[03:48:36] <toastydeath> yeah
[03:49:39] <toastydeath> my formal suggestion is to lock out Z and W moves in feed/minute and open them up in inverse time.
[03:49:41] <ds2> interesting how the axis names has different meanings depending on the machine
[03:49:57] <toastydeath> becaues in feed/minute, the W and Z spaces will want the X and Y axis to move at different rates.
[03:50:09] <toastydeath> to achieve the apparent tool speed in inches a minute.
[03:50:38] <cradek> goodnight all
[03:50:43] <toastydeath> lol =(
[03:50:42] <toastydeath> bye
[03:52:14] <toastydeath> i have the feeling i am a horrible idiot in some way, yet cannot identifiy the exact point
[03:54:53] <Jymmm> * Jymmm raises hand
[03:54:57] <ds2> aren't U/W relative axis on a lathe?
[03:55:07] <toastydeath> yeah, that was discussed earlier though
[03:55:14] <ds2> just sanity checking
[03:55:15] <toastydeath> u/w can also be the second turret
[03:55:21] <toastydeath> depending!
[04:07:35] <maddash> discrete motion control
[04:11:30] <maddash> how does the TP convert a continous trajectory into one consisting of discrete steps? aren't steps always lost in the process?
[07:05:42] <alex_joni> hi Rugludallur
[07:31:13] <lewin1> lewin1 is now known as lewing
[08:48:08] <Dallur> Hi Alex, that was my computer logging back in but hey :)
[08:57:22] <alex_joni> hey
[08:57:26] <alex_joni> what's up?
[09:27:23] <martin_lundstrom> Hello everyone
[09:27:34] <Dallur> hey martin
[09:27:51] <martin_lundstrom> How are you?
[09:27:56] <Dallur> alex_joni: waiting for some info from the candcnc guys, I tend to ask hard questions so :)
[09:28:03] <Dallur> martin_lundstrom: good, and you ?
[09:28:11] <martin_lundstrom> ok
[09:28:48] <martin_lundstrom> I have cut using your config and Im making progress
[09:29:06] <Dallur> martin_lundstrom: excellent
[09:29:16] <Dallur> martin_lundstrom: did you have to do a lot of changes ?
[09:29:47] <martin_lundstrom> I had some problems updating the values in axis, you also?
[09:29:48] <Dallur> martin_lundstrom: about that "dip" when you start your cutting, it's a bug which I have not fixed yet, I noticed that but I figured there were more important things to fix first
[09:30:01] <Dallur> martin_lundstrom: hmm no I think it was fine with me
[09:30:02] <martin_lundstrom> Dallur: only minor changes
[09:30:17] <martin_lundstrom> I will check again
[09:31:16] <Dallur> martin_lundstrom although I seem to remember that spin buttons did not update untill you removed focus from them
[09:31:31] <martin_lundstrom> ahhh
[09:32:16] <martin_lundstrom> do you know what the dip depend on?
[09:32:33] <martin_lundstrom> Is the corner lock implemented?
[09:35:10] <Dallur> martin_lundstrom: the corner height lock should be implemented and working yes but I have only tested in software
[09:35:25] <martin_lundstrom> ok
[09:35:27] <Dallur> martin_lundstrom: I can't remember off the tip of my head why it dips but it had something to do with initial state
[09:35:44] <Dallur> err top of my head :+P
[09:36:40] <martin_lundstrom> ok i was thinking maybe i could help, but this is too complicated
[09:37:48] <Dallur> martin_lundstrom: the diagram should help
[09:39:06] <martin_lundstrom> it helps, but its still far from clear to me
[09:41:12] <martin_lundstrom> need to rebbot
[09:51:32] <Martin_Lundstrom> Dallur: Shoyld pyvcp.Spin-TravelHeight be updated when I change the value in axis? (it dont now)
[10:07:31] <alex_joni> where's the diagram again?
[10:10:19] <anonimasu> morning
[10:15:24] <Dallur> martin_lundstrom: it should
[10:15:53] <anonimasu> U W is neat stuff ;)
[10:16:10] <Dallur> alex_joni: http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/~checkout~/emc2/configs/plasma-thc/THCDesign.odg?rev=1.1;content-type=text%2Fplain
[10:18:05] <anonimasu> alex_joni: are you awake?
[10:18:40] <anonimasu> alex_joni: is it to support DMG style machines?
[10:18:46] <anonimasu> err dgm..
[10:19:08] <Martin_Lundstrom> DMG?
[10:19:16] <Martin_Lundstrom> dgm?
[10:19:18] <anonimasu> deckel maho gleidemeister..
[10:21:18] <anonimasu> cant find a good picture
[10:22:24] <anonimasu> http://www.oboronliga.ru/rus/partners/mazak/images/variaxis.gif
[10:22:30] <anonimasu> machines with that kind of table ;)
[10:36:49] <Martin_Lundstrom> Im not sure if you ask about the thc diagram above (its for a torch height controller)
[10:39:06] <anonimasu> me?
[10:39:11] <anonimasu> I'm talking 5 axis machines.
[10:39:34] <Martin_Lundstrom> just who is confused ;)
[10:39:45] <Martin_Lundstrom> +me
[10:39:43] <anonimasu> I dont care about thc :p
[10:44:31] <Martin_Lundstrom> Anyone know of a nice nesting software?
[10:46:21] <anonimasu> Martin_Lundstrom: Sigmanest
[10:46:41] <Martin_Lundstrom> Ill have a look
[10:46:58] <anonimasu> Martin_Lundstrom: just kidding
[10:47:12] <anonimasu> http://www.sigmanest.com/
[10:47:32] <anonimasu> it's loads of $$$$$
[10:48:02] <anonimasu> sheetcam works pretty well
[10:49:58] <anonimasu> I wish he would implement the automatic nesting feature I added a proposal for ;)
[10:50:06] <alex_joni> what's the status of sheetcam these days?
[10:50:29] <Martin_Lundstrom> Dallur: Its updating I think, it was the HAL configuration window that did not update, my fault
[10:50:36] <anonimasu> alex_joni: working?
[10:50:52] <alex_joni> anonimasu: I last tried sheetcam when it was beta/shareware
[10:50:56] <alex_joni> 0.9.something
[10:53:04] <Martin_Lundstrom> any other low cost with automatic nesting?
[10:55:13] <anonimasu> Martin_Lundstrom: forget it.
[10:55:24] <anonimasu> Martin_Lundstrom: automatic nesting is where the $ multiplies.
[10:56:40] <Martin_Lundstrom> ok
[10:56:55] <anonimasu> hence why I want it in sheetcam ;)
[10:57:02] <anonimasu> I havent found anything cheap that does automatic nesting
[11:23:00] <anonimasu> :)
[11:28:05] <Martin_Lundstrom> bbl
[12:02:01] <maddash> which module contains the code the decides how to round from the actual displacement to the number of step pulses to output?
[12:02:55] <cradek> stepgen
[12:03:30] <cradek> all stepper-specific stuff is in there. the rest of emc is more generic.
[12:05:11] <maddash> wow, what a big file
[12:07:07] <alex_joni> heh
[12:08:26] <maddash> on another note, why does the TP call cubicaddpoint during each [TRAJ] cycle? aren't you supposed to calculate all the points you want to move to and spline them up at once?
[12:09:05] <alex_joni> you calculate the next point at each TRAJ cycle
[12:09:18] <cradek> I'm not sure even the cubic interpolator is currently used
[12:09:42] <maddash> cradek: "cubicNeedNextPoint" is checked every cycle
[12:11:00] <maddash> alex_joni: yeah, but when I open up GIMP (or photoshop, or acad, etc) and draw a spline, adding a new point changes the curve behind the current point.
[12:12:28] <maddash> is there some reference book or something you guys used as the basis for kinematics/* ? figured it might make it easier to understand how the TP works
[12:13:14] <alex_joni> I bet with enough determination you can write a plugin for photoshop to command steppers directly
[12:14:05] <Martin_Lundstrom> lol
[12:14:27] <alex_joni> Martin_Lundstrom: I was semi-serious
[12:14:51] <Martin_Lundstrom> its funny either way :)
[12:15:32] <alex_joni> maddash: there are some pages in the wiki about it
[12:15:33] <anonimasu> maddash: I'd like to understand the tp but im too stupid :)
[12:16:11] <maddash> alex_joni: actually, I checked out all the results from searching "Trajectory" on the wiki
[12:16:14] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TrajectoryControl
[12:16:17] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Trapezoidal_Velocity_Profile_Trajectory_Planner
[12:16:24] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Whitepapers_For_Reference
[12:16:25] <maddash> alex_joni: yep. yep.
[12:16:28] <maddash> yep.
[12:16:36] <anonimasu> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_Tp_Notes
[12:16:37] <alex_joni> lots of interesting papers to read about on the last one
[12:16:45] <maddash> simple tp notes?
[12:16:51] <maddash> or whitepapers?
[12:16:51] <alex_joni> whitepapers
[12:17:12] <alex_joni> the Sonja Macfarlane is quite readable
[12:17:34] <maddash> i read the fourth order one; sonja and daniela were too long
[12:18:30] <anonimasu> heh
[12:18:34] <alex_joni> that sounds like an interesting criteria to chose
[12:18:38] <anonimasu> I guess I'm stoo stupid.
[12:19:04] <anonimasu> :D
[12:19:35] <maddash> anonimasu: mostly your basic high school physics. the hard part is converting your continuous functions into discrete ones.
[12:20:13] <anonimasu> it's just all this stupid math :p
[12:20:38] <alex_joni> anonimasu: you forgot useless
[12:20:44] <maddash> also, why do control.c and tp.c default to EMCMOT_MAX_AXES?
[12:20:47] <anonimasu> useless?
[12:20:55] <maddash> doesn't that just slow things down?
[12:21:30] <anonimasu> alex_joni: how so?
[12:21:59] <maddash> er, EMCMOT_MAX_AXIS* (but it ought to be AXES)
[12:22:58] <anonimasu> one axis multiple axes to cut things down.
[12:24:08] <alex_joni> anonimasu: just as much useless as it is stupid :P
[12:25:25] <anonimasu> heh..
[12:25:28] <alex_joni> maddash:
[12:25:28] <alex_joni> if (!GET_JOINT_ACTIVE_FLAG(joint)) {
[12:25:29] <alex_joni> /* if joint is not active, skip it */
[12:25:29] <alex_joni> continue;
[12:25:29] <alex_joni> }
[12:25:48] <maddash> is that control.c?
[12:25:52] <CIA-8> 03jepler 07TRUNK * 10emc2/src/emc/motion/control.c: it's -> its in comments
[12:26:09] <alex_joni> maddash: yeah, the places where it matters
[12:26:24] <alex_joni> for example if you abort you can safely abort all joints
[12:26:42] <jepler> as for the frequency of calls to cubicAddPoint, you'll notice for the case EMCMOT_MOTION_COORD that it is only called when cubicNeedNexPoint
[12:26:54] <jepler> COORD is the mode for running g-code programs
[12:27:03] <maddash> alex_joni: I'm talking about pieces like, "for (joint_num = 0; joint_num < EMCMOT_MAX_AXIS; joint_num++) {"
[12:27:07] <alex_joni> maddash: me too
[12:27:20] <jepler> anyway in HEAD those have been generally modified to say: for (joint_num = 0; joint_num < num_joints; joint_num++) {
[12:27:30] <alex_joni> maddash: you can have joints 0,2,4,5 and 7 active
[12:27:31] <maddash> jepler: ah, better.
[12:28:08] <jepler> but you're worried about microoptimization here -- have you determined that these loops over "unused" joints are a performance problem in some case you care about?
[12:28:08] <alex_joni> but as jeff said, there's an insmod param that tells what the max joint nr. is
[12:28:48] <maddash> alex_joni: not quite. for example, "case EMCMOT_MOTION_COORD" in "get_pos_cmd"
[12:29:13] <alex_joni> maddash: TRUNK?
[12:29:30] <maddash> alex_joni: er, 2.1.5? is that THUNK?
[12:29:37] <maddash> TRUNK*
[12:29:52] <jepler> no
[12:29:56] <alex_joni> no, 2.1.x is the latest released version
[12:29:59] <jepler> TRUNK is the newest development version from CVS
[12:30:25] <maddash> I thought that was HEAD
[12:30:48] <jepler> you can call it HEAD if you like
[12:30:54] <alex_joni> HEAD was an incorrect name we used
[12:31:02] <alex_joni> HEAD is the latest version of _any_ branch
[12:31:09] <alex_joni> even v2_1_branch has a HEAD
[12:31:23] <alex_joni> the HEAD of the main devel is called TRUNK
[12:31:58] <maddash> jepler: what do you mean by "it's -> its in comments"?
[12:32:09] <maddash> alex_joni: where do you get these names?
[12:32:16] <alex_joni> CVS manual
[12:32:29] <alex_joni> http://cvsbook.red-bean.com/cvsbook.html
[12:32:43] <jepler> maddash: correcting grammar mistakes (use of "it's" where "its" was appropriate) in comments
[12:33:19] <alex_joni> * alex_joni goes back to real work
[12:33:30] <maddash> * maddash goes back to tp.c
[12:33:59] <maddash> ^^ and cubic.c and control.c
[12:35:22] <alex_joni> enjoy..
[12:36:10] <anonimasu> maybe I should write a spec for the UI stuff..
[12:36:13] <anonimasu> in a bit
[12:36:28] <alex_joni> oh, it's not done yet?
[12:36:49] <anonimasu> lol
[12:36:54] <anonimasu> dont yet?
[12:37:05] <anonimasu> I've wored 1 hour in 2 days at it :)
[12:37:53] <alex_joni> and it's not done yet?
[12:38:03] <alex_joni> oh.. :/
[12:38:03] <anonimasu> no
[12:38:06] <alex_joni> :P
[12:41:03] <maddash> how the hell is turbocnc "open-source" when you have to pay for the source code?
[12:41:45] <maddash> fecking moniker abuser.
[12:41:48] <maddash> brb.
[12:43:41] <anonimasu> turbocnc is the crappiest thing ever.
[12:43:51] <anonimasu> lost step world.
[13:00:54] <alex_joni> but I suspect the TP is way easier to understand :D
[13:02:14] <jepler> you can write a real simple TP. First, neglect acceleration altogether ...
[13:04:33] <alex_joni> yeah, you're laughing, but I've seen controls that do that
[13:04:40] <alex_joni> PC based win software
[13:05:12] <jepler> when I couldn't get emc1 to work right for the first rev of etchcnc that's what I did too
[13:05:49] <jepler> the thing has no mass and I didn't care about a stall every few minutes so...
[13:07:15] <alex_joni> this looks like a resonably sized machine
[13:07:16] <alex_joni> http://www.milltronics.net/images/machines/br60.jpg
[13:07:57] <archivist> vacuum table on that ?
[13:08:16] <alex_joni> 24HP spindle
[13:09:10] <archivist> hmm some of that looks a bit light for 24hp
[13:13:24] <alex_joni> * alex_joni heads home
[13:28:38] <anonimasu> archivist: agreed
[13:29:17] <Guest827> neat looking machine though
[13:29:19] <Guest827> oh
[13:29:26] <Guest827> Guest827 is now known as skunkworks_
[13:29:35] <anonimasu> yep
[13:29:37] <anonimasu> I'd like two..
[13:29:56] <archivist> only 2?
[13:30:21] <anonimasu> http://www.milltronics.net/products/used/
[13:31:06] <anonimasu> http://www.partnermachines.net/images/vk4.jpg
[13:34:27] <anonimasu> *yawns*
[13:35:11] <maddash> out of curiosity, why is posemath inside of libnml?
[13:35:45] <cradek> they both came from nist rcslib
[13:36:55] <maddash> but posemath has nothing to do with nml
[13:41:25] <jepler> fwiw libposemath is now (in TRUNK at least) a separate library from libnml .. but the benefits to reorganizing the source tree are outweighed by the costs, so the source files remain in src/libnml/posemath
[13:49:01] <maddash> better.
[13:50:28] <anonimasu> hm ok
[17:01:27] <ohiopctechDOTcom> ohiopctechDOTcom is now known as chr0n1c
[17:09:42] <anonimasu> hello
[17:11:20] <bill2or3> * bill2or3 waves.
[17:11:34] <anonimasu> what's up?
[17:12:02] <bill2or3> nada, just working. *bleh*
[17:12:21] <anonimasu> :)
[17:12:21] <anonimasu> ok
[17:12:32] <anonimasu> I started working on this ui stuff :)
[17:12:44] <anonimasu> but im very inclined to draw up this part and cut it..
[17:13:05] <bill2or3> cut it on what?
[17:14:39] <anonimasu> my mill..
[17:16:08] <SamOrpheus> acemi
[17:16:13] <anonimasu> :)
[17:24:23] <chr0n1c> i need emc to run on an amd64 chip or i need to find a new power supply for my old p2 333 box before i can run my mini mill again :(
[17:24:48] <chr0n1c> the pwoer supply in it died last night (my older emc machine)
[17:24:54] <chr0n1c> power supply*
[17:25:51] <skunkworks_> 333 is getting to be a bit on the thin side. How did it run?
[17:26:00] <chr0n1c> it runs nice
[17:26:09] <skunkworks_> mec_guy: Hi
[17:26:13] <mec_guy> hi
[17:26:21] <chr0n1c> i wouldn't go anything lower than that
[17:26:25] <mec_guy> r thee many mech engg on this channel
[17:26:35] <anonimasu> mec_guy: What?
[17:26:34] <chr0n1c> but axis will only bog down if i runa 30,000 line program
[17:26:38] <chr0n1c> other than that it's fine
[17:27:10] <skunkworks_> You need to clear the preview every so often.
[17:27:11] <mec_guy> i mean do Mechanical Engineers hang out on this chatroom
[17:27:39] <chr0n1c> i do some mechanical engineering... and get paid for it, but i'm not an official engineer?
[17:27:54] <archivist> some of us are mechanical engineers of one sort or another
[17:28:06] <skunkworks_> some of us just wing it.
[17:28:13] <anonimasu> haha
[17:28:15] <anonimasu> :)
[17:28:15] <bill2or3> for instance, I am a 6 story tall robot.
[17:28:16] <chr0n1c> word @ wing it
[17:28:18] <chr0n1c> lol
[17:28:26] <anonimasu> I usually holds up a wet finger in the air
[17:28:37] <anonimasu> err I usually hold up a wet finger in the air to feel which way the draft is..
[17:28:47] <anonimasu> ;)
[17:28:49] <anonimasu> it works for sizing ;)
[17:29:08] <anonimasu> and if it breaks you can always say you are not a engineer.
[17:29:09] <anonimasu> :D
[17:29:11] <anonimasu> just kidding ;)
[17:29:21] <archivist> in the open source world we have an open definition of engineer
[17:29:21] <mec_guy> how does EMC compare against fanus or MAZAK?
[17:29:38] <chr0n1c> the engineers get blamed for everything that goes bad and none of the good stuff :(
[17:29:43] <anonimasu> mec_guy: it does compare well considering it's free..
[17:30:19] <skunkworks_> mec_guy: it is one of the few pc machine controllers that will do true closed loop
[17:30:26] <chr0n1c> emc holds it's own.. i have used several different cnc interfaces and emc works like it should for a cnc machine
[17:30:35] <anonimasu> yep
[17:30:44] <anonimasu> 19:32 <mec_guy> do u have a sim sw 4 this
[17:30:52] <anonimasu> mec_guy: Go to www.linuxcnc.org and download the livecd
[17:31:11] <anonimasu> 19:33 <mec_guy> i have had some pracice on a technofour controller
[17:31:22] <chr0n1c> who's gonna add amd64 to the live cd? :D
[17:31:39] <skunkworks_> chr0n1c: you ;)
[17:31:42] <chr0n1c> DOH!
[17:31:45] <anonimasu> I was just going to say that
[17:31:51] <archivist> anonimasu, heh I just pointed him here from brlcad
[17:32:02] <anonimasu> archivist: oh :)
[17:32:07] <anonimasu> mec_guy: ?
[17:32:11] <archivist> yup
[17:32:21] <mec_guy> i'm hree
[17:32:31] <anonimasu> that's the best way to get started
[17:32:31] <mec_guy> i mean i'm here
[17:32:48] <anonimasu> mec_guy: it's not as much how to operate emc as general procedures for setting up parts and stuff that's usually a problem
[17:32:59] <mec_guy> d live cd
[17:33:36] <mec_guy> i did not understand u?
[17:33:44] <chr0n1c> BIG TIP: always home your machine before you shut the controller down. that way your zero always stays the same
[17:33:56] <chr0n1c> **if you don't use home switches
[17:34:23] <anonimasu> chr0n1c: well, MOUNT HOME SWITCHED<- ANOTHER BIG TIP
[17:34:28] <anonimasu> :D
[17:34:42] <chr0n1c> rofl... that's a good tip as well
[17:34:45] <anonimasu> mec_guy: "http://www.linuxcnc.org" go there and downlaod the live cd
[17:34:50] <anonimasu> err download
[17:35:12] <anonimasu> mec_guy: it is the easiest way to try emc out
[17:35:13] <chr0n1c> downlaod still sounds the same when you say it aloud
[17:35:21] <chr0n1c> the same as download
[17:35:27] <mec_guy> wat abt d G & M codes in EMC?
[17:35:37] <chr0n1c> mec_guy: yes
[17:36:02] <anonimasu> mec_guy: What about them?
[17:36:10] <mec_guy> der r lniks to user manual and integrator manual
[17:36:12] <chr0n1c> mec_guy: you can use mdi mode or full on g-code files from mastercam and the likes
[17:36:22] <mec_guy> r d G & M codes available in those
[17:36:38] <anonimasu> yes, they are
[17:36:52] <anonimasu> it supports rs274-ngc..
[17:36:59] <anonimasu> http://www.linuxcnc.org/docs/EMC2_User_Manual.pdf
[17:37:02] <anonimasu> in section 3
[17:38:16] <mec_guy> will give it a try?
[17:38:33] <anonimasu> mec_guy: What?
[17:38:49] <chr0n1c> i'd say... if you are building a hombrew cnc machine and you don't use emc.. then you haven't done it right
[17:39:37] <mec_guy> i actually just want to learn CNC programming
[17:39:51] <anonimasu> mec_guy: well, then emc is quite a bit overkill
[17:40:00] <anonimasu> :)
[17:40:10] <anonimasu> there are stuff like cnc simulator for free downloading
[17:40:16] <mec_guy> then can you suggest a good CNC simulation software?
[17:40:19] <anonimasu> that'll run in windows if you like..
[17:41:10] <chr0n1c> i have emc2/ubuntu runnin in windows on this machine... in vmware ;)
[17:41:41] <chr0n1c> not for actual cutting but to try out programs before i send them to the real cnc box
[17:41:52] <mec_guy> checked out d website they say that they support Mill and turning ms but no Lathe
[17:42:35] <anonimasu> mec_guy: "Turning" is what you do on a lathe
[17:43:03] <mec_guy> wat abt facing?
[17:44:13] <chr0n1c> facing is turning
[17:44:35] <chr0n1c> like aquaring is milling
[17:44:39] <chr0n1c> squaring*
[17:45:29] <mec_guy> but facing reduces length and turning redused diameter
[17:45:50] <anonimasu> mec_guy: It dosent matter..
[17:45:53] <anonimasu> mec_guy: you do it on a lathe..
[17:46:08] <anonimasu> mec_guy: that's what matters.. the rest is all programming
[17:47:45] <mec_guy> so u say dat i can simulate all lathe operations on this simulator
[17:48:15] <archivist> even screw cutting
[17:49:50] <mec_guy> will definitle give it a try?
[17:51:54] <skunkworks_> why are you asking?
[17:52:09] <mec_guy> ? was amistake
[17:52:18] <skunkworks_> ah :)
[17:53:19] <chr0n1c> * chr0n1c wants to be in cali
[17:53:34] <chr0n1c> * chr0n1c wants to be in cali... instead of ohio
[17:53:36] <ds2> crazy question but has anyone thought of adding a cylindrical coordinate mode to G code?
[17:53:44] <ds2> chr0n1c: ewwwwwwwwwwwwwwwwwwwwwww
[17:54:04] <chr0n1c> ewwwww ohio is right
[17:54:07] <ds2> ewww CA
[17:54:19] <ds2> no one WANTS to be in CA
[17:54:40] <chr0n1c> pfft... sign me up ASAP
[17:55:04] <ler_hydra> anyone here?
[17:55:12] <chr0n1c> * chr0n1c is gone
[17:55:19] <ler_hydra> easiest way to start image to gcode?
[17:55:22] <mec_guy> btw do u all know of a channel whre they discuss CAD CAM
[17:55:24] <chr0n1c> * chr0n1c is here but not here
[17:55:48] <ds2> ler_hydra: start? in general or you refering to a specific program/script?
[17:55:59] <chr0n1c> i do image to g-code with a proggie called traceart or i use MCX
[17:56:01] <ler_hydra> in genereal
[17:56:11] <ler_hydra> oh there's a plugin for emc called image to gcode
[17:56:31] <chr0n1c> *i haven't tried the built-into-emc convertor
[17:56:47] <ds2> you start by mapping color/pixel texture to a physical coordinate (X,Y, AND Z); Z is commonly used to encode the 'color' component
[17:57:10] <ds2> a converter can be written up with libgd in a evening
[17:57:31] <chr0n1c> search google for a program called "profiler06" and "traceart" (if you have a windoze box)
[17:57:48] <ler_hydra> oh this is a linux only box
[17:57:52] <ds2> tracing, IMHO, is the wrong way to go
[17:58:02] <ds2> ler_hydra: write one in perl
[17:58:19] <ler_hydra> ds2, it's already written and in emc
[17:58:27] <ds2> if mine wasn't such a huge mess, I'd give it you but it'd take more time to explain then it would to rewrite it
[17:58:34] <chr0n1c> i think cradek wrote it?
[17:58:41] <chr0n1c> *the one in emc
[17:58:42] <skunkworks_> jepler I think
[17:58:46] <ler_hydra> jepler I think
[17:58:53] <chr0n1c> ohhh
[17:58:54] <ds2> the one in EMC is python based, isn't it?
[17:58:57] <anonimasu> Yes
[17:59:24] <skunkworks_> I think you have to add something to the ini file to make image to gcode work
[17:59:33] <ler_hydra> oh
[17:59:41] <skunkworks_> but that is just a vauge recolection.
[18:00:41] <ler_hydra> yep, in the ini
[18:00:42] <chr0n1c> ehh you could email the pic to me and i'll convert it with mastercam X and send you the g-code
[18:01:02] <ler_hydra> chr0n1c, it's allright, got it to work now :)
[18:01:14] <skunkworks_> http://linuxcnc.org/docs/2.1/html/gui/image-to-gcode/index.html
[18:01:49] <chr0n1c> i'm gonna have to try the built-in convertor
[18:02:58] <anonimasu> chr0n1c: mcamx rocks ;)
[18:03:44] <chr0n1c> anonimasu: i am still quite fond of MC9... some nifty things in MCX worth checking out
[18:03:50] <chr0n1c> *though
[18:04:03] <ds2> MCX seems a bit crude in the in conversion (unless there is another one)
[18:04:53] <chr0n1c> you can tweak the settings (i use the c-hook, that you have to load up through the c-hook menu)
[18:05:10] <chr0n1c> and most of the time it comes out nice looking like i expected
[18:05:31] <chr0n1c> plus there is toolpath filtering and things you can use to make the final result better
[18:12:46] <chr0n1c> * chr0n1c wonders what the old timers did before there was CNC/NC machines
[18:13:06] <archivist> hard work
[18:13:14] <chr0n1c> * chr0n1c agrees
[18:13:36] <anonimasu> yeah
[18:13:39] <anonimasu> dirty work :D
[18:13:47] <chr0n1c> anyone ever looked through an old timers toolbox and noticed some of the crazy tools they used to make to get a job done?
[18:14:17] <skunkworks_> one man yelling out the x,y,z coordinates of a propeller while 40 guys turn knobs.
[18:14:21] <archivist> we still use strange tools
[18:14:32] <anonimasu> hehe
[18:14:35] <chr0n1c> lol@ Skullworks_
[18:14:57] <archivist> * archivist is making a 2.8mm dia 10 tooth pinion
[18:15:12] <archivist> aint no cnc to do that
[18:15:17] <ds2> chr0n1c: is this the same one you get by going to the C plugins and selecting a DLL?
[18:15:26] <chr0n1c> ds2: yes
[18:15:29] <ds2> Hmmm
[18:15:50] <chr0n1c> it's more of tracing than an actual image to g-code
[18:15:54] <ds2> I tried it and my astrological signs all turned out to be like caveman drawings (crude stick figures)
[18:16:18] <anonimasu> hm
[18:16:19] <chr0n1c> what sign? i'll try one...
[18:16:38] <ds2> bug me tonight... it is on a (should be on) a USB thumb drive
[18:17:22] <chr0n1c> hey ds2, what's your sign ;) ... ROFL
[18:17:56] <ds2> we were told in the MCX class to create a clock face... so I did one with astrological signs all around the clock
[18:18:50] <ds2> chr0n1c: you have full access to MCX? (real version, not EDU)
[18:20:08] <chr0n1c> kinda.. it's at a buddy's shop down the road
[18:20:15] <ds2> oh
[18:20:18] <chr0n1c> i go visit when i need to use it
[18:20:31] <chr0n1c> like only a mile away
[18:20:48] <ds2> chr0n1c: would it be too much of a bother to bug you do convert MCX files to IGES (or any other format)?
[18:21:18] <chr0n1c> i could do a couple
[18:21:26] <chr0n1c> or attempt
[18:21:50] <chr0n1c> converting something gets fuzzy sometimes
[18:21:57] <ds2> i only need that if I can't find the IGES files I thought I generated
[18:23:40] <chr0n1c> i've never actually converted iges to MCX
[18:23:47] <chr0n1c> it should be painless though
[18:24:09] <chr0n1c> load the iges.. save as mcx
[18:24:37] <ds2> the reverse
[18:24:51] <ds2> I can open IGES files with other stuff... but I got things stuck in MCX (or I think)
[18:24:57] <chr0n1c> ohh..
[18:25:04] <ds2> wish someone would put out a MCX to something else converter
[18:25:29] <anonimasu> it's very painless..
[18:25:40] <anonimasu> mcx is just the toolpath format..(operations and part)
[18:25:46] <anonimasu> you can export STL files I think..
[18:25:48] <ds2> I don't really care what format it is in as long as I can read it and don't loose the 3D aspect
[18:25:49] <anonimasu> or iges..
[18:25:51] <chr0n1c> i have had luck with dxf in autocad r14 format at the shop (for conversions to other programs... like MC TO autocad)
[18:26:28] <chr0n1c> can you import dxf?
[18:26:32] <anonimasu> yeah
[18:26:43] <ds2> sure but when I tried, DXF export on MasterCAM is 2D only
[18:26:55] <chr0n1c> ds2: does your program import dxf?
[18:27:03] <ds2> chr0n1c: yep
[18:27:14] <ds2> chr0n1c: using rhino so most formats work
[18:27:18] <chr0n1c> hmm.. i had some 3d dxf vector models loaded in mc9
[18:27:53] <chr0n1c> i never did export.. that would only be importing
[18:28:09] <chr0n1c> well never exported a 3d file in dxf
[18:28:23] <ds2> mastercam is rather asymetrical with file support
[18:28:27] <chr0n1c> it would be nice to know the outcome of that process
[18:28:33] <ds2> i.e. it won't do a 3DM export but will read 3DM
[18:32:10] <chr0n1c> there is some funny stuff when exporting dxf to autocad... sometimes it makes all the lines one solid object and you can't remove lines or delete dimensions without deleting the whole part (after it's loaded in autocad from the mastercam dxf export)
[18:32:43] <anonimasu> hm..
[18:32:50] <anonimasu> ^_
[18:32:52] <anonimasu> gui comming along nicely
[18:33:22] <ds2> anonimasu: any chance you can be convinced to make it work in 320x200? =)
[18:33:33] <chr0n1c> are you doing a on-the-machine-like gui anonimasu?
[18:33:42] <anonimasu> yeah
[18:33:50] <anonimasu> ds2: yes certainly
[18:34:04] <anonimasu> ds2: this is a longshot but I hope to make a gui editor if this works out well..
[18:34:17] <anonimasu> I'll post some images in a bit..
[18:34:24] <anonimasu> I got the outlines and stuff drawn |
[18:34:36] <chr0n1c> i was just going to ask about a screenshot
[18:34:40] <anonimasu> it's not much yet..
[18:34:49] <anonimasu> but im making controls so :)
[18:35:06] <chr0n1c> do you need any graphics done for it?
[18:35:12] <chr0n1c> i'd love to help out!
[18:35:21] <anonimasu> hm, not yet :)
[18:35:28] <anonimasu> I hope to get the nml stuff working tomorrow
[18:36:24] <chr0n1c> what about pictures of real knobs and buttons for the controls on screen?
[18:36:46] <chr0n1c> or even a real cnc control picture as the interface?
[18:37:00] <anonimasu> yeah they do have pictures
[18:37:02] <anonimasu> just not manu
[18:37:05] <anonimasu> many
[18:37:16] <anonimasu> they are kind of plain ;)
[18:37:30] <anonimasu> though that's the point of them as I see it
[18:37:47] <chr0n1c> yeah.. glitter isn't always good i guess...
[18:38:47] <chr0n1c> but.. real lcd digits cropped from a pic of a digital would be fun for the readouts
[18:38:51] <chr0n1c> if it was a toy
[18:39:20] <anonimasu> :)
[18:39:25] <anonimasu> hehe
[18:39:57] <anonimasu> page 18
[18:40:59] <chr0n1c> ahhh
[18:41:22] <chr0n1c> only 205 pages in that pdf? how tiny that is ;)
[18:41:27] <anonimasu> hehe
[18:41:31] <anonimasu> I have a control like it for real..
[18:42:19] <chr0n1c> it would be sweet if it was all ansi in a terminal window
[18:42:28] <chr0n1c> it would really feel like home then
[18:42:33] <anonimasu> haha
[18:43:48] <anonimasu> Picture comming up
[18:46:08] <anonimasu> now
[18:47:39] <anonimasu> http://imagebin.org/9192
[18:48:05] <ds2> so it just requires 4 buttons to do everything?
[18:48:14] <anonimasu> there's panelmount buttons...
[18:48:16] <anonimasu> a heap of them..
[18:48:34] <ds2> yes, but does it still require a mouse like axis?
[18:48:39] <anonimasu> no
[18:48:41] <ds2> cool
[18:48:54] <ds2> this would be great for refit uses
[18:48:54] <anonimasu> it'll be touchscreen useable..
[18:49:03] <anonimasu> I think I'll add a bar of button at the bottom..
[18:49:17] <anonimasu> so you can skip using the panel for some stuff..
[18:49:27] <anonimasu> if you have a touchscreen..
[18:49:29] <ds2> touch screens are expensive and then there is the issue of oily fingeres
[18:49:35] <ds2> fingers
[18:49:43] <anonimasu> ds2: well, you can always mount softkeys there instead..
[18:49:59] <chr0n1c> lookis interesting anonimasu
[18:49:58] <anonimasu> or you can use your mouse to navigate it..
[18:50:03] <chr0n1c> looks*
[18:50:11] <anonimasu> thanks
[18:50:32] <ds2> anonimasu: are you requiring X to run this?
[18:50:33] <anonimasu> yes
[18:50:40] <ds2> oh :/
[18:51:07] <anonimasu> it's written in mono(c#) because it's easy to develop in..
[18:51:12] <ds2> why not use directfb or just talk to the fb device directly
[18:51:19] <ds2> Ohh I see
[18:51:19] <anonimasu> and supporta all kinds of plugins and stuff..
[18:51:25] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[18:51:33] <ds2> so it will not be light weight
[18:51:33] <anonimasu> without much work..
[18:51:36] <anonimasu> no
[18:51:54] <anonimasu> :/
[18:52:37] <anonimasu> though I wonder how it compares to python..
[18:53:41] <chr0n1c> * chr0n1c vows to someday learn to code
[18:53:45] <anonimasu> performancewise..
[18:55:05] <anonimasu> ds2: hope it's still interesting
[18:55:56] <CIA-8> 03cradek 07nineaxis * 10emc2/configs/sim/servo_sim.ini: first pass: support for xyzabcuvw
[18:55:56] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/canterp/canterp.cc: first pass: support for xyzabcuvw
[18:55:56] <CIA-8> 03cradek 07nineaxis * 10emc2/lib/python/rs274/glcanon.py: first pass: support for xyzabcuvw
[18:55:57] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/ini/initraj.cc: first pass: support for xyzabcuvw
[18:55:57] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/kinematics/ (gantrykins.c rotatekins.c tc.c tc.h tp.c): first pass: support for xyzabcuvw
[18:56:00] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/motion/ (command.c control.c usrmotintf.cc): first pass: support for xyzabcuvw
[18:56:01] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/nml_intf/ (canon.hh emc.cc emcpos.h): first pass: support for xyzabcuvw
[18:56:02] <ds2> anonimasu: it is, just not as interesting as before.... I still think EMC should be able to run on a nice small SBC with limited memory
[18:56:06] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/rs274ngc/ (11 files): first pass: support for xyzabcuvw
[18:56:05] <ds2> WTF
[18:56:06] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/task/emccanon.cc: first pass: support for xyzabcuvw
[18:56:08] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: first pass: support for xyzabcuvw
[18:56:11] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/sai/saicanon.cc: first pass: support for xyzabcuvw
[18:56:18] <ds2> uh
[18:56:26] <anonimasu> ds2: then I suggest you write a framework for handling the fb.. :)
[18:56:27] <ds2> CVS hacked?
[18:56:35] <chr0n1c> holy cow... 9 axis
[18:56:59] <anonimasu> ds2: it's a real pain ;)
[18:57:04] <ds2> oh wait n/m... xyzabcuvw does make sense in this context
[18:57:18] <ds2> anonimasu: if I had the time, I'd be tempted to do one on curses
[18:59:32] <skunkworks_> cradek: cool
[19:00:02] <anonimasu> ah well..
[19:00:02] <anonimasu> :)
[19:01:50] <ds2> 320x200 LCDs are cheap but that's also the max practical resolution for really old machines using NTSC monitors
[19:03:13] <anonimasu> though you can run X in 320x200..
[19:03:22] <anonimasu> im planning on running this on X startup..
[19:03:34] <anonimasu> and ignoring the normal WM..
[19:03:41] <anonimasu> in fullscreen :)
[19:06:46] <awallin> who has a nine axis machine?
[19:06:50] <anonimasu> I have
[19:06:52] <anonimasu> in my dreams
[19:07:03] <anonimasu> and apparently cradek does ;)
[19:07:15] <chr0n1c> is that 3 actual axis' with 3 knuckles each?
[19:10:00] <chr0n1c> hey i jsut found something cool.. completely un-related to emc or cnc machines.. but htp://deadshow.org/dan/ it's greateful dead bootlegs!
[19:11:45] <skunkworks_> one thing emc doesn't do very well yet is parallel axis - like a wire edm or foam machine. I think that is part of this push. (I could be wrong)
[19:13:42] <anonimasu> :)
[19:18:52] <JymmmmEMC> ds2: What is this obsession you have with 320x200?
[19:19:20] <chr0n1c> orig cnc machine controls that run in dos are 320x200
[19:19:30] <anonimasu> hm
[19:19:37] <anonimasu> this gui runs on mono/linux
[19:19:43] <anonimasu> neat.
[19:20:09] <chr0n1c> i should say some are*
[19:20:47] <anonimasu> and it takes 0.3s to start..
[19:21:21] <chr0n1c> the miltronics i had took about 10s you could see the autoexec running and stuff when you first turn it on
[19:21:27] <ds2> Jymmm: didn't I just explain it?
[19:22:05] <anonimasu> the heidenhain takes about 10s..
[19:22:09] <anonimasu> it compiles the plc program
[19:22:12] <JymmmmEMC> ds2: not the obsession you didn't. At least get into the 90's if nothign else!
[19:22:42] <anonimasu> hehe..
[19:23:11] <ds2> BAH on the 90's
[19:23:38] <ds2> 320x200 LCDs are still very popular
[19:24:04] <ds2> i have 3 of of them around me right now
[19:24:16] <JymmmmEMC> so is chicken pox, but...
[19:24:18] <ds2> all on devices built in the last 3 years
[19:24:32] <anonimasu> :)
[19:25:16] <CIA-8> 03cradek 07nineaxis * 10emc2/configs/sim/axis.ini: fix trivkins and AXIS to show the new axes
[19:25:17] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/kinematics/trivkins.c: fix trivkins and AXIS to show the new axes
[19:25:18] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/motion/emcmotcfg.h: fix trivkins and AXIS to show the new axes
[19:25:19] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: fix trivkins and AXIS to show the new axes
[19:25:21] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: fix trivkins and AXIS to show the new axes
[19:25:25] <ds2> now had I requested 128x128 or 160x160....
[19:25:27] <JymmmmEMC> ds2: Give it up, you know you were just being a cheap bastard and got the 320x200 REALLY cheap/free ;)
[19:25:34] <anonimasu> :)
[19:25:47] <ds2> JymmmEMC: if you can get free 320x200's cheap/free, let me know
[19:25:55] <ds2> cuz best I can do is 160x160
[19:26:22] <JymmmmEMC> ds2: any car LCD
[19:26:29] <anonimasu> ew¤#!"
[19:26:30] <ds2> car?
[19:26:36] <ds2> Hmmmmmm
[19:26:41] <JymmmmEMC> yep, those are the cheap LCD's
[19:26:43] <anonimasu> arent thoose very crappy
[19:26:50] <ds2> JymmmEMC: are there real bone yards around the SJC area?
[19:27:08] <JymmmmEMC> ds2: brand new off of you FAVORITE place
[19:27:15] <chr0n1c> check ebay for cheap 12v lcds
[19:27:21] <ds2> BAH
[19:27:30] <JymmmmEMC> ds2: hamiltin ave baby!!!
[19:27:46] <ds2> JymmmmEMC: hamilton and what?
[19:27:56] <ds2> I donno of any sources around there
[19:28:09] <JymmmmEMC> ds2: between bascom and Leigh
[19:28:50] <ds2> that's all residential
[19:29:00] <ds2> give me address
[19:28:59] <JymmmmEMC> ds2: Nope
[19:29:06] <chr0n1c> ohhh.. a good source for some semi-cheap LCDs would be the lcd's from the video game consoles they sell as add-ons
[19:29:17] <ds2> chr0n1c: guess what rez those are? =)
[19:29:26] <chr0n1c> 800x600
[19:29:37] <chr0n1c> the one i had for my playstation was 800x600
[19:29:50] <ds2> the last businesses in that direction are boston market, whole foods...
[19:30:00] <anonimasu> hm..
[19:30:06] <anonimasu> now to get vmware running..
[19:30:11] <ds2> chr0n1c: the PS1 screens are 320x200 so are the Xbox ones
[19:30:19] <anonimasu> so I can try this..
[19:30:26] <JymmmmEMC> ds2: 2145 Hamilton Ave. San Jose, CA, 95125
[19:30:49] <ds2> JymmmEMC: what's the name?
[19:30:53] <chr0n1c> uhh.. i had 800x600 running on it.. i took the screen apart and made my own homebrew projector and it was hooked to my pc with the tv out on my vid card
[19:30:58] <JymmmmEMC> ds2: Ebay Inc.
[19:31:07] <ds2> *thawp*
[19:31:11] <JymmmmEMC> ROTFLMAO
[19:31:32] <ds2> aren't they on 1st ?
[19:31:38] <anonimasu> hm..
[19:31:50] <anonimasu> im not happy with this UI..
[19:31:57] <chr0n1c> i jsut took all my items off ebay and closed the my store i had on there
[19:32:00] <JymmmmEMC> ds2: Maybe there too, but HQ is on hamilton
[19:32:05] <ds2> chr0n1c: I ahve both of those I mentioned and they are 320x200; NTSC
[19:32:07] <anonimasu> though it maybe be because I run it on a 24" widescreen monitor..
[19:32:21] <anonimasu> dosent feel quite the right size..
[19:34:00] <chr0n1c> ds2: hmmmmm, i swear i ran 800x600 on it
[19:34:00] <anonimasu> it feels more sane at 640x480
[19:34:16] <anonimasu> the proportions are bette.
[19:34:17] <anonimasu> r
[19:35:09] <ds2> chr0n1c: I think some of them will take a higher rez signal but if you open it up and check the datasheet, they are 320x200 LCDs
[19:36:57] <chr0n1c> that sounds logical... i don't have the projector anymore because the ribbon cable going to the screen broke from all the moving around...
[19:36:58] <chr0n1c> :(
[19:37:41] <ds2> chr0n1c: were you projecting movies from a DVD player ?
[19:38:05] <JymmmmEMC> ds2: Buy it now!!! http://cgi.ebay.com/FARENHEIT-T-7000MHR-7-COLOR-TFT-LCD-HEADREST-MONITOR_W0QQitemZ250138987842QQihZ015QQcategoryZ94848QQrdZ1QQcmdZViewItem
[19:38:17] <chr0n1c> i was projecting everything from my pc
[19:38:24] <chr0n1c> i had it set up as a second monitor
[19:38:35] <chr0n1c> movies/games/irc chat
[19:38:49] <chr0n1c> it was 5 feet of my office wall
[19:39:07] <chr0n1c> it was awesome for playing warcraft 3: ROC
[19:39:47] <anonimasu> :)
[19:39:58] <chr0n1c> i put a halogen light behind it and used a fresnel lens magnifying sheet from office depot and built it into a cardboard box
[19:40:09] <ds2> JymmmEMC: you are calling that cheap?
[19:40:19] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/nml_intf/ (emc_nml.hh emcglb.h): fix accel problem and sticky g0/1/2/3 words
[19:40:20] <CIA-8> 03cradek 07nineaxis * 10emc2/src/emc/rs274ngc/interp_internal.cc: fix accel problem and sticky g0/1/2/3 words
[19:40:43] <chr0n1c> ds2: that is semi-cheap
[19:41:10] <ds2> JymmmEMC: its cheaper at deanza swapmeet w/o the shipping
[19:41:45] <chr0n1c> he could even trade something for it there possibly
[19:41:49] <chr0n1c> *at the swap meet
[19:42:03] <chr0n1c> and pick up some bootleg cd's
[19:42:06] <chr0n1c> muahahah
[19:42:10] <JymmmmEMC> ds2: again GET INTO THE 90's NO 320x200
[19:42:18] <ds2> *thawp*
[19:42:26] <ds2> JymmmEMC: you're stuck in the PC world
[19:42:41] <JymmmmEMC> ds2: and your stuck in the dark ages
[19:42:43] <anonimasu> http://imagebin.org/9193
[19:42:45] <ds2> 320x200 is one of a common current resolution for LCDs
[19:43:07] <JymmmmEMC> bullshit
[19:43:11] <chr0n1c> z -23" ?
[19:43:15] <chr0n1c> or -23 mm
[19:43:18] <anonimasu> mm..
[19:43:39] <chr0n1c> cus 23" on z would be a huge machine :D
[19:43:50] <anonimasu> 584mm..
[19:43:57] <anonimasu> .2 :)
[19:44:09] <ds2> JymmmEMC: it is on embedded devices... i.e. the current Treo
[19:44:28] <chr0n1c> what res is the ihype-phone
[19:44:28] <ds2> most eval boards, etc are all 320x200 (or 320x320 in some cases)
[19:44:29] <chr0n1c> ?
[19:44:36] <JymmmmEMC> ds2: so you going to run your cnc on an 2" LCD?!
[19:44:56] <ds2> JymmmmEMC: I might if my seller would complete the sale
[19:45:03] <ds2> it currently has a 3inch CRT
[19:45:14] <JymmmmEMC> * JymmmmEMC just shakes his head
[19:45:15] <chr0n1c> WOW
[19:45:39] <chr0n1c> why not just use an old computer crt?
[19:45:50] <chr0n1c> i mean 15" get thrown away all the time
[19:45:57] <ds2> don't want to modify the machine case
[19:46:16] <anonimasu> ah well.
[19:46:25] <lerman_> lerman_ is now known as lerman
[19:49:13] <anonimasu> that's how it looks now..
[19:50:05] <anonimasu> and I think that's the first window I'm going to get working.
[19:57:53] <skunkworks_> Guest144: Hi
[20:01:15] <Guest144> Question is there a script already out there that will let me on the fly set the zero for my machine? The reason I ask is I need to be able to set work zero when and were I want. I have many different designs that I carve but I have many more sizes and thicknesses of material so I must set the zero but I dont see in AXIS where I can do this but did read in the HAL book that I could write Python code to get a sidebar and I am thinking I co
[20:01:53] <JymmmmEMC> you got cut off at: a sidebar and I am thinking I co
[20:02:40] <Guest144> thinking I could do it ther but figured I would ask before I write something myself I am not a coder
[20:02:44] <cradek> Guest144: use "touch off"
[20:03:03] <Guest144> dont know what that is I never use chats
[20:03:15] <cradek> it's a button in AXIS
[20:03:44] <cradek> you select the axis of which you want to change the current value, then click Touch Off, then enter the value you want (often 0)
[20:04:22] <Guest144> oh sorry so if I have a Gcode loaded that machines a 3x3 pic but want it carved in the middle of a 24x24 peice of material I can set the machine where I want it to start and then hit touch off?
[20:04:35] <cradek> yes
[20:06:13] <Guest144> Ok I am totally new to EMC so I am having to learn what every thing does and what its called in Mach it was work zero or work ref and I am trying to get use to linux to I really love both progs so far and everyone is friendly
[20:06:46] <cradek> "touch off" is described on page 96 of the user manual
[20:07:09] <cradek> also on page 91 is "getting started" and "a typical session with AXIS"
[20:07:56] <Guest144> I knew someone had to of thought of it but couldnt figure it out so touch off great thank you very much Page 91 I will read that thanks again wifes callin baby being bad thanks again
[20:08:08] <cradek> good luck, come back anytime
[20:08:20] <JymmmmEMC> Guest144: DUCT TAPE!
[20:11:19] <chr0n1c> JymmmmEMC: wouldn't that hurt when you pulled it off the wife's mouth?
[20:18:09] <JymmmmEMC> chr0n1c: Now, why would you even think of doing that for?
[20:18:22] <JymmmmEMC> well, ok I can think of ONE reason...
[20:20:54] <CIA-8> 03cradek 07nineaxis * 10emc2/configs/sim/axis.ini: fix up sim/axis.ini some more for 9axis testing
[20:21:23] <maddash> there's something I don't get about the TP: What happens if primary_displacement.{x,y,z} is greater than INPUT_SCALE*cycle_time?
[20:23:39] <cradek> http://timeguy.com/cradek-files/emc/xyzabcuvw.png
[20:24:23] <chr0n1c> cradek: what is the axis configuration of that machine?
[20:24:32] <awallin> cradek: nice
[20:25:19] <cradek> chr0n1c: it's not a real machine, it's a sim configuration of a machine with 6 independent linear axes and 3 rotary axes, all of which can move in a coordinated fashion
[20:25:40] <cradek> by convention U,V,W are parallel to X,Y,Z
[20:25:59] <awallin> is there a seprate TP calculation for UVW?
[20:25:59] <chr0n1c> cradek: that sounds very ineresting
[20:26:16] <chr0n1c> interesting even*
[20:26:29] <cradek> awallin: yes there's a bit of new TP code
[20:26:30] <ds2> cradek: going to convince the gcam guys to support such a machine?
[20:26:32] <chr0n1c> intrest?
[20:26:38] <chr0n1c> where is my dictionary when i need it
[20:26:58] <JymmmmEMC> chr0n1c: not using FF huh?
[20:27:15] <awallin> so there are now two emc-pose objects? one with XYZABC control, and one with UVW?
[20:27:42] <cradek> the EmcPose now has another cartesian
[20:28:23] <cradek> the only thing I haven't decided is how unit/time (G94) feed rates should work
[20:28:29] <awallin> ok, but that doesn't scale real well when the next guy comes along and wants three independently movable 'things'
[20:28:51] <cradek> actually it probably would
[20:29:16] <skunkworks_> cradek: could x and w be used for a gantry? 2 servos/steppers using 1 axis? Instead of having to use kins?
[20:29:17] <chr0n1c> does anyone else think linus and mr gates look like they could be brothers or cousins or something?
[20:29:45] <cradek> skunkworks_: kins is a better solution, because you really have one axis (x) but two joints representing it.
[20:30:04] <skunkworks_> right - right. Didn't think that thru very well..
[20:30:17] <awallin> skunkworks G0X100U-100 would be interesting!
[20:30:26] <skunkworks_> :)
[20:30:50] <skunkworks_> bbl
[20:31:11] <cradek> * cradek gleefully watches g28 coordinate all 9 axes
[20:31:19] <cradek> it even looks right (vel/accel)
[20:31:41] <awallin> anyone done kins for a rotary table (or even trunnion?) ?
[20:32:29] <chr0n1c> anyone ever created a live tooled boring head with emc? that would be awesome different bore sizes on the fly with g-codes...
[20:33:39] <JymmmmEMC> This is weird... I just cut open a CAT6 STP (stranded), and there's a plastic '+' strip the whole length of the cable, and each pair is sitting in the grooves of it.
[20:34:44] <archivist> not weird, consistent impedence
[20:34:50] <JymmmmEMC> STP being shielded
[20:36:06] <JymmmmEMC> still weird in my book =)
[20:36:52] <JymmmmEMC> what I find strange is that you have to match CAT6 stuff together.
[20:37:08] <JymmmmEMC> That's gonna open a can of worms for sure
[20:41:05] <JymmmmEMC> I get it, but I think they're pushing copper to it's limits now.
[20:42:10] <chr0n1c> i think they should find a way to make cables out of water
[20:42:23] <chr0n1c> *for the conductor
[20:42:38] <chr0n1c> it would be fun anyways if not practical
[20:42:40] <JymmmmEMC> Hey, lets try making them out of light instead!!!
[20:43:01] <chr0n1c> vampires wouldn't use light cables
[20:43:12] <archivist> chr0n1c, they do for the cross channels electicity system
[20:43:13] <chr0n1c> there goes a big market chunk
[20:43:16] <JymmmmEMC> There ya go.... 1st benefit
[20:44:28] <awallin> use water to guide light. that's done too :)
[20:56:17] <anonimasu> chr0n1c: are there thoose heads?
[20:58:45] <anonimasu> cradek: there?
[20:58:53] <chr0n1c> anonimasu: i've never seen one
[20:59:05] <anonimasu> is there even that kind of heads?
[21:05:47] <anonimasu> ds2: there's a QT framebuffer project..
[21:06:38] <anonimasu> I thikerr not for console though
[21:08:03] <anonimasu> err think..
[21:08:05] <anonimasu> no..
[21:10:00] <anonimasu> http://www.helenos.eu/
[21:09:59] <anonimasu> wtf.
[21:13:51] <chr0n1c> hey that site is using drupal
[21:14:12] <anonimasu> now if we could run emc on it..
[21:14:16] <anonimasu> ;)
[21:14:21] <anonimasu> just kidding
[21:14:51] <anonimasu> their kernel is really micro..
[21:15:06] <chr0n1c> ha.. check this page out that i built: nofingclue.com same drupal theme
[21:15:28] <anonimasu> ok
[21:15:41] <chr0n1c> it's lame though!
[21:15:44] <chr0n1c> i warned you!
[21:15:49] <anonimasu> yeah
[21:16:07] <anonimasu> :)
[21:18:36] <anonimasu> chr0n1c: nice friends you have
[21:18:46] <chr0n1c> i know right?
[21:18:55] <anonimasu> answering machine...
[21:19:19] <chr0n1c> i'm not sure if he knows he is global yet or not
[21:19:37] <anonimasu> hehe
[21:19:50] <anonimasu> you have nice friends on myspace too ;)
[21:20:27] <anonimasu> *yawns*
[21:21:12] <chr0n1c> hmm.. on myspace?
[21:21:16] <chr0n1c> lol
[21:22:22] <anonimasu> did you just add every random person you could find?
[21:22:23] <anonimasu> :D
[21:22:41] <chr0n1c> no all my favorite artists
[21:22:59] <chr0n1c> a good chunk of those people added me
[21:23:01] <chr0n1c> *first
[21:23:20] <anonimasu> :)
[21:23:26] <chr0n1c> well .. the people that aren't millionaires
[21:23:59] <anonimasu> lol
[21:24:21] <anonimasu> ^_^
[21:26:20] <chr0n1c> * chr0n1c is getting ready to run to RT tests on my AMD64 motherboard on a 32 bit install (with a pci video card instead of the on-board video)
[21:26:36] <anonimasu> hope it works
[21:26:41] <chr0n1c> the RT test were horrible with the built in video card
[21:27:41] <chr0n1c> 32mb tnt2 with tv out (pci)
[21:28:03] <anonimasu> ok
[21:34:54] <chr0n1c> F%#KING SWEET! 0 overuns
[21:35:30] <chr0n1c> using the pci card instead of the on-board video card solved 100% of the problems on this machine
[21:35:39] <chr0n1c> now i don't need to use the p2 33mhz
[21:35:44] <chr0n1c> woohoo
[21:35:49] <chr0n1c> 33mhz*
[21:35:54] <chr0n1c> 333mhz*
[21:35:55] <chr0n1c> geez
[21:36:32] <chr0n1c> glxgears and the realtime test runnin for 5 mins now.. still 0 overruns
[21:36:39] <chr0n1c> and surfing with firefox
[21:36:44] <chr0n1c> and i loaded solitaire
[21:41:37] <chr0n1c> and then i loaded gimp and then loaded open office word
[21:41:47] <chr0n1c> and two more tabs in firefox
[21:42:24] <chr0n1c> it's still completey responisve with all this jazz running (and the rtai latency test)
[21:42:48] <chr0n1c> axis should be ultra smooth on this box.. i'm stoked!
[22:05:04] <maddash> psht.
[22:05:25] <jepler> chr0n1c: yay
[22:06:19] <chr0n1c> jepler: i'm holding my breath for an official 64 bit kernel ;)
[22:06:21] <CIA-8> 03jepler 07TRUNK * 10emc2/src/po/fr_axis.po: updates from Francis TISSERANT
[22:06:37] <maddash> is that his name? francis tisserant?
[22:06:46] <maddash> why's it caps-locked?
[22:06:52] <jepler> maddash: europeans often write their whole last name in caps
[22:07:10] <maddash> weird...
[22:07:29] <jepler> or maybe it's just the french, I'm not sure
[22:07:38] <chr0n1c> they also seem to like benny hill... which puzzles me
[22:09:02] <maddash> this tp thing is annoying the hell out of me
[22:14:04] <maddash> should I go with a fpga or a microcontroller to do the motion calculation/generation? microcontrollers are cheaper on the plus side, which is why I'm even asking
[22:14:43] <JymmmmEMC> dedicated>
[22:14:44] <JymmmmEMC> ?
[22:15:02] <JymmmmEMC> or still connected to a pc?
[22:15:32] <JymmmmEMC> maddash: ^^^^^^^^^^^^
[22:16:14] <jepler> maddash: "15:21:22 <maddash> there's something I don't get about the TP: What happens if primary_displacement.{x,y,z} is greater than INPUT_SCALE*cycle_time?
[22:16:19] <jepler> "
[22:16:20] <maddash> ...isn't the presence of an fpga in itself "dedicated," or am I misunderstanding your question?
[22:16:37] <jepler> is that what is still puzzling you?
[22:16:47] <JymmmmEMC> fpga's still need to be loaded and power up
[22:16:52] <JymmmmEMC> a/and/at/
[22:17:13] <JymmmmEMC> s/and/at/
[22:17:29] <maddash> jepler: :S yeah. I have an idea of how this is done, but I'm having a hard time flowing from get_pos_cmd to the stepgen.c module
[22:17:44] <maddash> s/this is/this could be/
[22:17:46] <jepler> maddash: I don't see why there needs to be a particular relationship between primary_displacement, INPUT_SCALE, and cycle_time
[22:18:34] <jepler> are you saying, "what if there isn't enough time to issue the required number of steps"?
[22:21:33] <maddash> jepler: tpruncycle grabs the current tc, updates the progress of this tc (via tcruncycle), and uses this update to calculate primary_displacement, and...
[22:21:40] <maddash> ... finally updates the position with primary_displacment. So, every traj_cycle (==cycle_time?),
[22:22:44] <maddash> the TP increments tc->progress by a bit. is this correct so far?
[22:24:33] <jepler> ok, sounds right
[22:25:30] <jepler> and assuming that there are no bugs in the planner, the change in currentPos over time obeys the acceleration and velocity constraints set out in the inifile
[22:25:46] <maddash> Since cycle_time is used to calculate the tc->progress increment, then I conclude that the kinematics/control module expects to output enough stepper pulses to get you to the correct position denoted by the updated tc->progress.
[22:26:52] <jepler> motion produces a commanded position. you can hook that position command up to many things -- one of those things is a software step generator.
[22:27:26] <jepler> if you hook it up to the software step generator, you'd better make sure that enough steps can be issued to attain the velocity you asked for in your inifile.
[22:27:38] <maddash> for simplicity, can we assume that the results of get_pos_cmd funnels into stepgen?
[22:27:45] <jepler> if you do not, you will get a following error
[22:27:53] <maddash> aha.
[22:28:02] <jepler> because the stepgen feedback position will lag behind its commanded position
[22:28:56] <maddash> so basically, base-thread >> traj_cycle, or else there could exist a following error?
[22:30:09] <maddash> because this goes back to my point in my first question: what if the stepgen can't make enough steps to actually reach the updated tc->progress?
[22:30:22] <jepler> for step+direction output at least two BASE_THREAD runs are needed to issue one step (it could be longer if 'steplen' or 'stepspace' parameters are increased from their default of "as short as possible")
[22:31:16] <jepler> so with a base period of 50000 you could issue 10000 steps per second (10000 Hz = 1 / (2 * 50 microsecond)
[22:31:18] <maddash> fyi, "INPUT_SCALE*cycle_time" was just my fancy way of denoting the max velocity the stepgen can support
[22:32:06] <jepler> if your SCALE is 8000 and your UNITS are inch, that means the speed limitation imposed by stepgen is 1.25 inches per second
[22:32:07] <maddash> hm, i would think that it is one, not two...
[22:33:22] <jepler> for one BASE_PERIOD the step output must be TRUE and for one it must be FALSE. One step per two BASE_PERIODs
[22:33:28] <maddash> why two? all you're doing each base_thread cycle is outputting a step and a dir, right?
[22:33:40] <maddash> ohhh, right.
[22:34:17] <maddash> ah, so you (and emc) and I had two separate definitions of what 'base-thread' means.
[22:35:12] <maddash> brb. battery's dying again. thanks, jepler.
[22:35:37] <jepler> ok
[22:35:39] <jepler> see you
[22:43:34] <skunkworks> crap - I left my volt meter on again.
[23:32:09] <jepler> hmm -- interesting
[23:32:45] <jepler> blend 2 parts tequila, 2 parts "margarita mix", 1 part lime juice, ice, and 1tsp dried hot pepper flakes
[23:32:51] <jepler> serve in salt-rimmed glass
[23:33:11] <jepler> it's cold, sour, and hot all in one drink
[23:33:23] <anonimasu> :)
[23:33:22] <anonimasu> nice
[23:34:11] <jepler> mmm I think I like it
[23:34:36] <jepler> the heat of the peppers lingers but is not overpowering
[23:34:59] <skunkworks> * skunkworks wonders how long before jepler becomes unintelligible
[23:35:02] <jepler> maybe I'll change my mind by the time I finish it
[23:35:16] <jepler> my alcohol tolerance is pretty low actually
[23:36:04] <jepler> (you mean I'm not unintelligible most of the time?)
[23:36:46] <skunkworks> I am sure you are understandable... I might not understand...
[23:37:55] <skunkworks> forgot to bring my box of motherboard led/switch odds and ends. they have the plug on one end that work well with the pluto..
[23:40:34] <jepler> woah, watch out for all the red pepper that ends up in the last sip!
[23:43:40] <skunkworks> * skunkworks hands jepler a 'stir stick'
[23:44:31] <jepler> I'd recommend it, as long as you like spicy
[23:46:20] <jmkasunich> what if you don't like alcohol?
[23:46:48] <skunkworks> what? everyone likes alcohol.. Don't they? that is just crazy talk
[23:47:12] <jmkasunich> * jmkasunich doesn't like any drink where I can taste the alcohol
[23:47:15] <jepler> jmkasunich: then leave out the tequila
[23:47:29] <jmkasunich> I usually drink beer, rarely wine, never mixed drinks
[23:48:58] <jepler> I never have mixed drinks except at home
[23:49:03] <jepler> I'm not prepared to pay bar/restaurant prices for them
[23:49:21] <jepler> a beer I can afford
[23:50:14] <skunkworks> At 20ipm - the maximum following error is about .0003
[23:50:50] <jmkasunich> skunkworks: that seems reasonable for all but the most precise work
[23:51:13] <jmkasunich> and as I was saying earlier, if its lag, not off-path error, the actual error in the finished parts is probably less
[23:53:50] <anonimasu> jmkasunich: that's still pretty bad
[23:54:08] <anonimasu> 0.0076mm.
[23:54:57] <jmkasunich> anonimasu: depends on the class of work
[23:55:09] <anonimasu> jmkasunich: it's still lots of error at slow speed..
[23:55:43] <jmkasunich> anonimasu: depends on the class of work
[23:55:51] <jmkasunich> bearing seats yeah, that would be a problem
[23:56:08] <jmkasunich> 90% of machining won't care about 0.0003"
[23:56:24] <jmkasunich> and 90% of machines have that much backlash or other errors
[23:56:31] <anonimasu> jmkasunich: ofcourse..
[23:56:44] <anonimasu> jmkasunich: but why is it impossible to get that even closer?
[23:56:47] <jmkasunich> besides, following error does not mean machine error
[23:57:11] <anonimasu> no, that's right it's just how much off the machine is from where it should be..
[23:57:25] <jmkasunich> where it should be at an instant in time
[23:57:31] <anonimasu> yeah..
[23:57:41] <jmkasunich> if it gets there 0.001 second later, that doesn't hurt the part
[23:58:03] <anonimasu> but shouldnt feedforward take care of that kind of lag?
[23:58:30] <jmkasunich> not entirely
[23:58:31] <jmkasunich> it can
[23:58:36] <jmkasunich> can't
[23:59:01] <jmkasunich> at 15:23:17.012 EMC tells the machine "go to X0.0110"
[23:59:17] <jmkasunich> its impossible for the machine to be there at that instant (unless its already there)
[23:59:27] <jmkasunich> it gets there at 15:23:17.013