Back
[01:57:56] <cradek> ack, this is getting more and more complex
[01:58:58] <SWPadnos> arc, this is getting more and more complex :)
[01:59:14] <cradek> not even that yet
[01:59:47] <cradek> I have to allow feed changes
[01:59:59] <SWPadnos> hmmm
[02:00:09] <SWPadnos> so it's blending + offsetting that's the trouble
[02:00:22] <cradek> if I keep thinking there are probably all sorts of things that need to be allowed with comp on
[02:00:27] <jmkasunich> what are you working on?
[02:00:40] <cradek> concave corner cutter comp
[02:00:45] <jmkasunich> ah
[02:00:50] <cradek> http://timeguy.com/cradek-files/emc/concave-cuttercomp.png
[02:01:06] <jmkasunich> interesting
[02:01:19] <cradek> that's
http://timeguy.com/cradek-files/emc/cc.ngc
[02:01:26] <jmkasunich> I'm still farting around with my setup for these parts
[02:01:57] <jmkasunich> I'll probably spend so much time setting up that I could whittle all 20 parts with a dull pocketknife before I actually make the first one
[02:02:10] <jmkasunich> but I can call it a learning experience
[02:02:25] <jmkasunich> I have three tools mounted now, and have tool table entries for them
[02:02:26] <cradek> or admit it's for fun, we won't laugh
[02:04:16] <SWPadnos> it's to speed up the order of 200 that you'll get - err - some time later
[02:04:43] <cradek> the tools will be unmounted by then...
[02:04:49] <jmkasunich> exactly
[02:05:23] <SWPadnos> well, the pocket knife would be put away too
[02:12:04] <jmkasunich> is the preview supposed to show lines that result from G43?
[02:12:12] <cradek> it's so hard to dismount tools that you've carrrrefully measured for the tool table
[02:12:14] <jmkasunich> when I did a G43 in MDI it shows a yellow line
[02:12:30] <cradek> yes, the tooltip moved
[02:12:39] <cradek> it will go back if you g0 [whatever]0
[02:12:52] <jmkasunich> I understand what the yellow line means
[02:13:02] <jmkasunich> I'm wondering why I don't see one when I preview my program
[02:13:21] <jmkasunich> it starts with G49, G0 somewhere, G43H12, G0 somewhere else
[02:14:06] <cradek> I think you'll actually see the motion (maybe even in yellow)
[02:14:20] <jmkasunich> no yellow in the preview
[02:14:46] <jmkasunich> I need to remove some cruft from the program to see exactly what is going on
[02:15:04] <jmkasunich> (I started to code it withoug using the tool table)
[02:17:10] <jmkasunich> ok, it looks like those implied moves are invisible
[02:17:40] <jmkasunich> whenever I do a G43, the next move begins somewhere out in space (at the tip of the new tool)
[02:19:07] <cradek> wonder what jepler's doing to his poor dsl
[02:19:22] <jmkasunich> its slow?
[02:19:26] <cradek> very
[02:19:29] <CIA-22> EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: inside corners are working for paths made of lines only
[02:26:18] <jepler> cradek: I think the heavy load is because I finally released 'turd'.
[02:26:39] <jepler> it's a pretty big download, and I think a lot of people are interested in it
[02:27:05] <cradek> am I supposed to know what turd is?
[02:27:23] <jepler> it's not fair to expect you to remember the name I gave that program.
http://emergent.unpy.net/01206402027
[02:27:42] <jmkasunich> 5.5kB - its bringing the internet to its knees
[02:28:05] <cradek> neat, I can use that
[02:28:11] <jepler> you have used it
[02:28:23] <cradek> I mean, I can use it in modern times
[02:28:31] <cradek> I had forgotten about it
[02:28:53] <jepler> I wonder if the modifications so that it understands freebsd's nodump flag are lost now
[02:29:04] <cradek> btw, I made a branch, so everyone who wants to can jump in and help finish this
[02:29:09] <jepler> I don't have them
[02:29:17] <cradek> hmm
[02:29:33] <cradek> I might have it?
[02:29:41] <jepler> now that you know the program name you might try looking
[02:30:25] <jepler> was it bsd that put the flag in stat.st_mode?
[02:30:49] <cradek> buh
[02:33:09] <jepler> hm, it's in st_flags which doesn't seem to be accessible from python's os.stat (it only knows about common fields)
[02:33:54] <cradek> how sure are you that it worked on bsd?
[02:34:18] <jepler> welllll
[02:34:38] <cradek> maybe you rewrote it in C?
[02:36:34] <SWPadnos> or patched python:
http://mail.python.org/pipermail/patches/2005-May/017671.html
[02:36:46] <jepler> hm the svn analog of viewcvs is useless for determining what released version a change is in
[02:37:10] <jepler> SWPadnos: following the breadcrumb trail seems to show that it got incorporated in python at some point, but not on the python on this fbsd machine I have handy
[02:37:18] <jepler> (that's Python 2.4.4 (#2, Mar 29 2007, 13:58:13)
[02:37:18] <jepler> [GCC 3.4.6 [FreeBSD] 20060305] on freebsd6
[02:37:18] <jepler> )
[02:37:19] <SWPadnos> ah
[02:37:30] <cradek> I'm amazed at how people seem to write viewcvs analogs that are worse than viewcvs
[02:37:46] <SWPadnos> it would have to be viewsvn :)
[02:38:21] <cradek> mine is 2.4.3, sorry
[02:46:23] <cradek> jepler: turd sometimes spits out a filename, but usually not
[02:46:24] <jepler> cradek: looks like you would have to upgrade to python2.5.
[02:46:45] <jepler> cradek: files above a certain size get printed; set the size with -s
[02:46:52] <cradek> ah, feature
[02:46:55] <cradek> that's nice actually
[02:47:29] <cradek> fortunately crap collects on my linux machines, not bsd machines
[02:47:49] <jepler> hah
[02:48:25] <jmkasunich> does axis take tool table data into account when it decides to print red coordinates?
[02:48:59] <cradek> I think it does now
[02:49:09] <cradek> I'm still a little iffy about how that works
[02:49:51] <jmkasunich> actually, a very interesting question is simply "what coordinate system are the printed extents in?"
[02:50:28] <cradek> the active one
[02:50:42] <jmkasunich> the active one at the time the preview is generated?
[02:50:53] <cradek> yes
[02:51:13] <cradek> your gcode wouldn't assume any particular coordinate system is in effect...?
[02:51:47] <cradek> well ... no
[02:52:12] <cradek> it updates
[02:52:22] <jmkasunich> I have set G54, and my program never changes that
[02:52:29] <jmkasunich> but it does change tool offsets with G43
[02:52:30] <cradek> the extents and coordinate axes show the current system
[02:54:51] <jepler> if you are displaying machine coordinates, though, the extents change to be machine coordinates
[02:55:08] <jmkasunich> pretty sure I'm doing relative
[02:55:26] <jmkasunich> yep
[02:55:46] <jmkasunich> anyway, I have a legal program that fools axis into putting up red numbers for the extants
[02:56:04] <jmkasunich> legal = capable of running without actually hitting a limit
[02:56:29] <jmkasunich> my X tool offsets have a range of about 8"
[02:56:56] <cradek> yuck
[02:57:05] <jepler> hm I bet the special tool offset handling was applied only to Z, not X.
[02:57:31] <jepler> (you have to subtract the tool length back out when deciding if the coordinate is acceptable)
[02:57:59] <cradek> http://timeguy.com/cradek-files/emc/useful-offset.png
[02:58:03] <jmkasunich> that would be consistent with what I'm seeing I think
[02:58:30] <jmkasunich> cradek: nice
[02:58:36] <cradek> does that kick ass or what
[02:58:44] <jmkasunich> ;-)
[02:58:59] <jepler> 'night guys
[02:59:01] <jepler> cradek: yes, it does
[02:59:05] <cradek> goodnight
[02:59:11] <jmkasunich> goodnight
[02:59:15] <SWPadnos> oh cool - I thought I was seeing double :)
[02:59:19] <SWPadnos> night jepler
[03:00:00] <LawrenceG> chris... very cool.... how about on the inside for pocketing?
[03:00:32] <SWPadnos> picky picky
[03:00:56] <SWPadnos> (note that an S has both inside and outside "corners" )
[03:01:34] <LawrenceG> no way... that is a major step..... being able to calculate valid offset paths...
[03:01:58] <SWPadnos> so I guess we're all agreed - that does kick ass :)
[03:02:14] <cradek> http://timeguy.com/cradek-files/emc/inside-offset.png
[03:02:16] <LawrenceG> major
[03:02:41] <SWPadnos> hmmm
[03:02:46] <LawrenceG> lovely
[03:02:47] <cradek> it doesn't know when the path crosses or gouges elsewhere on the part
[03:02:53] <cradek> LawrenceG: not really; look closer
[03:02:58] <SWPadnos> right - those little bowties there
[03:03:26] <SWPadnos> intersting that it goes "backwards" on those short segments :)
[03:03:49] <SWPadnos> so all you need now is 2-segment lookahead ;)
[03:03:54] <cradek> uh yeah.
[03:04:05] <SWPadnos> and then N-segment
[03:04:07] <SWPadnos> :)
[03:04:10] <LawrenceG> only a slight matter of path trimming!
[03:04:22] <cradek> it's not cam, it's radius comp
[03:04:37] <cradek> if you give a path where the tool doesn't fit, you're stuffed
[03:04:45] <SWPadnos> heh
[03:05:25] <SWPadnos> I know - there's no good way for it to see that e.g. the top part wouldn't work with a tool 3x the size of the one you used
[03:05:32] <SWPadnos> (where the lines are close on the top of the S)
[03:05:45] <cradek> http://timeguy.com/cradek-files/emc/faithful-but-stupid.png
[03:06:05] <SWPadnos> yeah, like that :)
[03:07:59] <cradek> haha
[03:08:08] <cradek> this makes some silly paths if you give it way too big a tool
[03:09:55] <cradek> the current code gives an error if anything is wrong... I wonder where the right tradeoff is.
[03:10:20] <cradek> I think it's currently almost unusable, but it does what it promises to do perfectly
[03:11:37] <jmkasunich> to be honest, I'd almost rather have it gripe about convex corners
[03:12:30] <jmkasunich> griping doesn't ruin parts - working around the comparatively easy part of offsetting but gouging when the user misses a more subtle problem isn't always good
[03:14:17] <cradek> jmkasunich: I sympathize but it bothers me that it's only usable if you hand-write all your gcode with emc's comp in mind
[03:14:48] <jmkasunich> heh, that's exactly what I do
[03:14:58] <cradek> like we discussed in KC the ability to run with -0.010 comp seems very valuable but is impossible with emc
[03:15:06] <jmkasunich> yeah, I agree about that
[03:15:18] <SWPadnos> it is sad that unless you have infinite lookahead (or at least until the end of the program), there's no way to get it right all the time
[03:15:27] <jmkasunich> but you just know people are gonna gouge parts with it
[03:15:46] <cradek> SWPadnos: that's why you generate the gcode for nominal tool size. the resharpened tool will not ever gouge.
[03:16:07] <SWPadnos> sure - pre-offset, by the CAM package which does have infinite lookahead
[03:16:13] <cradek> yes
[03:16:30] <jmkasunich> for people who have CAM it will be very nice
[03:16:45] <jmkasunich> I don't care about them (lucky bastards ;-)
[03:16:48] <cradek> if you write for .375 and put a .75 tool in and expect comp to fix it - surprise!
[03:16:57] <SWPadnos> error if the tool diameter is >0, just do it if the offset is <0
[03:17:19] <cradek> <0 vs >0 is just right vs left
[03:17:28] <SWPadnos> for the diameter?
[03:17:32] <cradek> yes
[03:17:44] <cradek> -1 left is +1 right
[03:18:17] <SWPadnos> oh, so if you have "nominal paths", and you use 0.1, that means your tool is 0.1" bigger than the path was made for
[03:18:26] <cradek> yes
[03:18:27] <SWPadnos> ?
[03:18:30] <SWPadnos> ok
[03:18:32] <SWPadnos> bummer :)
[03:18:47] <cradek> why bummer?
[03:18:52] <SWPadnos> then maybe this should be G43.279 or something :)
[03:19:14] <SWPadnos> because there's no easy way to determine if the old behavior or the new behavior should be used
[03:21:03] <cradek> I think I can detect that "bowtie" crossing. it happens when the path flips due to backing up past the beginning of the segment
[03:21:10] <jmkasunich> well, thats dissapointing - it takes a lot of force to drill - I'm losing steps
[03:21:31] <cradek> jmkasunich: yuck
[03:21:40] <SWPadnos> bummer
[03:21:54] <SWPadnos> are those the steppers shoptask sold, or others you got elsewhere?
[03:22:07] <jmkasunich> keling inc, 900 oz-in
[03:22:11] <cradek> if I can detect that and abort ("gouging!") I think there's nothing to be said for the old algorithm
[03:22:37] <jmkasunich> and the feed is quite slow, so I should be getting near full torque
[03:22:48] <cradek> dull drill?
[03:23:20] <SWPadnos> those are 5TPI screws, aren't they?
[03:23:28] <SWPadnos> or 8 or something
[03:23:48] <jmkasunich> 10 tpi
[03:23:54] <jmkasunich> drill looks pretty sharp
[03:24:11] <jmkasunich> there's a reason they call it a drill PRESS
[03:24:15] <SWPadnos> hmmm. I don't remember them being that fine pitch. do you have ballscrews or acmes?
[03:24:16] <SWPadnos> heh
[03:24:19] <jmkasunich> acmes
[03:24:33] <SWPadnos> ok - I didn't look at those for long :)
[03:24:44] <SWPadnos> (but I think I have a pair in the garage, come to think of it)
[03:25:13] <jmkasunich> 330 RPM, 0.66 ipm feed = 0.002 feed per rev, 0.001 feed per flute
[03:25:21] <jmkasunich> doesn't seem that agressive
[03:25:55] <cradek> sure it's mounted straight?
[03:25:59] <jmkasunich> yes
[03:26:45] <jmkasunich> the hole isn't deep enough for that to matter anyway - I think I lost the first step before it was even cutting full diameter
[03:28:07] <jmkasunich> would probably require a lot less force if I predrilled at least 0.075 - thats about how wide the web of the drill is
[03:28:28] <jmkasunich> a twist drill removes the web area by brute force and pressure, not cutting
[03:29:47] <jmkasunich> this is depressing
[03:30:07] <cradek> do you have room for a smaller drill too?
[03:30:17] <jmkasunich> no
[03:30:29] <jmkasunich> I'm running out of creative ways to mount tools as well
[03:31:58] <jmkasunich> I think its time to throw in the towel - use CNC to face the parts, and make a starting dimple in the center, then drill and tap them on the drill press
[03:45:03] <jmkasunich> goodnight
[03:45:18] <SWPadnos> night
[11:32:55] <BigJohnT> morning alex_joni
[11:41:30] <alex_joni> HELLO
[11:41:39] <alex_joni> sorry :)
[11:41:51] <BigJohnT> for what?
[11:42:05] <BigJohnT> caps lock on?
[11:43:55] <BigJohnT> alex_joni: do you think the HOME_VEL will make it into the next bug fix release?
[11:48:18] <alex_joni> oh, surely not :)
[11:48:23] <alex_joni> it's nto a bugfix
[11:48:40] <BigJohnT> darn
[11:50:18] <BigJohnT> when I did the update of my files it put them all in the EMC2 directory on top of the files the install put there instead of in the EMC-TRUNK directory. I must have messed up the command...
[11:50:40] <BigJohnT> anyhow the compile didn't work : (
[11:50:57] <BigJohnT> I'll have to try when I get some time to clean it up and start over...
[11:54:29] <BigJohnT> alex_joni: do you think it will ever be included?
[12:00:59] <alex_joni> BigJohnT: I would like to see it included .. but I want to talk to jmk about it first, and I forgot last night :)
[12:01:40] <BigJohnT> ok, thanks for the help on it
[15:08:03] <cradek> nobody uses inverse time feed or arcs right?
[15:08:05] <cradek> or lathes?
[15:08:16] <cradek> whee I'm done
[15:08:25] <SWPadnos> I never use inverse time feed for lathes with arcs in diameter mode
[15:08:27] <SWPadnos> ever
[15:08:41] <cradek> * cradek introduces SWPadnos to "or"
[15:08:45] <SWPadnos> heh
[15:08:53] <SWPadnos> I just noticed that
[15:09:33] <cradek> the problem with a little early success (a nice looking path) is I don't want to finish by fixing all the things I know are still wrong
[15:09:56] <SWPadnos> heh - that is a problem
[15:11:57] <alex_joni> how about the ones you don't know that are wrong?
[15:33:57] <alex_joni> can anyone look at
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges ?
[15:35:09] <alex_joni> does the second section "code changes in task startup" look ok to you?
[15:42:04] <SWPadnos> jmk and I discussed having kins export the joints instead of motion (or call a function in motion to do the right number of joints)
[15:42:46] <alex_joni> that's unrelated
[15:42:59] <SWPadnos> heh - ok :)
[15:43:05] <alex_joni> when this code is running the joints are already exported and set up
[15:43:11] <SWPadnos> * SWPadnos hasn't actually drunk the coffee yet :)
[15:43:26] <alex_joni> we simply read the config (ini) and send the proper params to motion to set them
[15:45:40] <SWPadnos> although it's easier for now, it will likely be harder later if [AXIS_0], [AXIS_X] or [JOINT_0] are all accepted for the first linear joint (looking at trivkins)
[15:45:40] <alex_joni> my question was actually: should we just fix one way of doing things from now on, or try to load older/existing configs (for trivkins machines)
[15:45:46] <SWPadnos> heh
[15:46:14] <alex_joni> SWPadnos: yes, that was why I asked in here
[15:46:35] <SWPadnos> you always need the axis data in cartesian space - limits, home position, etc.
[15:46:46] <alex_joni> for trivkins? yes
[15:47:09] <SWPadnos> you still need it for nontrivkins
[15:47:18] <SWPadnos> home maybe not, but limits for sure
[15:47:26] <alex_joni> limits in carth space?
[15:47:30] <SWPadnos> yes
[15:47:34] <alex_joni> why?
[15:47:58] <alex_joni> I don't see how you can specify limits for a scara in carthesian space
[15:48:02] <SWPadnos> so you can constrain the work volume
[15:48:11] <SWPadnos> "don't go past X=10"
[15:48:15] <SWPadnos> seems simple enough
[15:48:24] <alex_joni> SWPadnos: that's overlimited imo
[15:48:43] <alex_joni> you can go to X=11 but only for 5<Y<7
[15:48:58] <alex_joni> can't express that in the ini..
[15:49:00] <SWPadnos> it's mechanically possible, but may not be desirable
[15:49:21] <alex_joni> all robots I worked with have a spherical working range
[15:49:31] <SWPadnos> consider a robot in a slightly constrained work area - you configure soft limits so it won't hit the machine next to it :)
[15:49:32] <alex_joni> pseudo-spherical
[15:50:12] <alex_joni> I don't quite see the use for carthesian limits on nontrivkins
[15:50:20] <alex_joni> but they might exist for all I care ;)
[15:50:23] <SWPadnos> heh
[15:50:43] <SWPadnos> a gantry is nontrivkins, but you still may want soft limits
[15:50:46] <alex_joni> I would probably set them so that the actual working range is an inner tangent to the rectangle
[15:51:02] <alex_joni> SWPadnos: I agree about limits, but only joint limits
[15:51:56] <SWPadnos> I think you need to allow for both
[15:52:18] <alex_joni> well.. once there will be code to check those, I see no problem in adding the ini support :P
[15:52:26] <SWPadnos> ?
[15:52:34] <alex_joni> atm only carthesian limits are checked
[15:52:38] <cradek> if your inverse kins has singularities, you need to have a way to disallow the corresponding cartesian inputs
[15:52:41] <SWPadnos> the interp (or something) already checks limits, doesn't it
[15:52:53] <alex_joni> hmm.. no
[15:53:05] <alex_joni> currently you set up joints (named AXIS_*)
[15:53:07] <SWPadnos> "move blah blah would go out of bounds" ...
[15:53:20] <alex_joni> the limits that get checked are joint limits in carthesian space
[15:53:37] <alex_joni> sometimes..
[15:53:39] <SWPadnos> unless you have nontrivkins, in which case it's all FUBARed
[15:53:49] <SWPadnos> ?
[15:53:50] <alex_joni> yeah, I was talking about nontrivkins here..
[15:53:59] <alex_joni> and yes, it's all FUBARed
[15:54:02] <SWPadnos> heh
[15:54:41] <alex_joni> ok, back to ini file..
[15:54:50] <alex_joni> for nontrivkins I think I know how to do it right
[15:55:02] <alex_joni> but for trivkins I wasn't sure if I should go through those extra efforts
[15:58:48] <alex_joni> I wonder what's easier for us to support?
[15:59:01] <alex_joni> not knowing what the users have in the ini, but it automagically works
[15:59:22] <alex_joni> or just pointing them to the proper section where it's described how they should fix things..
[15:59:36] <SWPadnos> a script can fix the section names pretty easily
[15:59:52] <SWPadnos> sed s/\[AXIS/\[JOINT/
[16:00:06] <SWPadnos> for trivkins
[16:00:07] <alex_joni> ok, so AXIS_<X,Y,Z,..> and JOINT_0,1,2,.. for nontrivkins
[16:00:18] <alex_joni> and only AXIS_<X,Y,Z,..> for trivkins?
[16:00:39] <SWPadnos> I'd prefer to not have any module-name-dependent initialization
[16:00:44] <SWPadnos> it's just icky
[16:01:41] <alex_joni> SWPadnos: you mean KINEMATICS=trivkins or fookins?
[16:01:45] <SWPadnos> yes
[16:01:58] <alex_joni> well.. I thought that's only for convenience
[16:02:06] <SWPadnos> if KINEMATICS && KINEMATICS==trivkins.ko yadda yadda
[16:02:08] <alex_joni> we can have MACHINETYPE = TRIVIAL
[16:02:11] <SWPadnos> sure
[16:02:21] <alex_joni> or whatever, somethign that is used only for this..
[16:02:36] <SWPadnos> in any case, JOINT* has to be sent to motion
[16:02:46] <SWPadnos> JOINT* information that is
[16:03:10] <alex_joni> right
[16:04:14] <SWPadnos> maybe HOME_POS should just be one line in some other section, rahter than individual pieces in the AXIS/JOINT sections
[16:04:23] <SWPadnos> HOME_POS=0,2,3.5,0,0,0
[16:04:48] <alex_joni> hmm.. harder to parse
[16:04:51] <SWPadnos> then you don't need to treat trivkins and nontrivkins differently
[16:05:17] <alex_joni> I don't understand what you mean..
[16:05:24] <SWPadnos> you always read joints and send them to motion, you always read cartesian home and send that too
[16:05:32] <alex_joni> right
[16:05:39] <alex_joni> and for trivkins they happen to match
[16:05:43] <SWPadnos> right
[16:05:51] <alex_joni> so if you read AXIS_X,Y,.. as joints and send that to motion
[16:06:03] <SWPadnos> I'd say get rid of the AXIS notation
[16:06:16] <SWPadnos> or change it to [X] [Y] [Z] ...
[16:06:20] <alex_joni> so where do you put your carthesian limits?
[16:06:38] <SWPadnos> [KINS], [TRAJ], [WORLD] ...
[16:06:43] <SWPadnos> [EMC]
[16:07:04] <alex_joni> talk about undecided :)
[16:07:08] <SWPadnos> heh
[16:07:14] <SWPadnos> anywhere :)
[16:07:32] <alex_joni> what's wrong with [AXIS_X] MIN_LIMIT ?
[16:07:49] <alex_joni> that's the joint limit for trivkins and the world limit for nontrivkins?
[16:07:54] <SWPadnos> if that's the only thing in the [AXIS_X] section, it's a lot of words for one little setting
[16:08:09] <alex_joni> MIN_LIMIT, MAX_LIMIT, HOME, MIN_VEL, MAX_VEL, etc
[16:08:28] <SWPadnos> where is COORDINATES?
[16:08:32] <alex_joni> basicly all there is in [JOINT_<nr>] could be in [AXIS_<letter>] too
[16:08:39] <alex_joni> [TRAJ] as it is now
[16:08:42] <SWPadnos> ok
[16:08:53] <SWPadnos> wherever that is is where the home could/should go
[16:08:57] <alex_joni> I think the [KINS] is probably not needed
[16:09:06] <SWPadnos> no, that's a motion thing
[16:09:16] <alex_joni> we can stick all in [TRAJ] to have less confusion
[16:09:17] <SWPadnos> wherever motmod is
[16:10:07] <alex_joni> SWPadnos: feel free to make a new inifile with all the sections/names you'd like
[16:10:36] <SWPadnos> if there will be relatively large changes, I'd change the names of AXIS*
[16:11:08] <SWPadnos> the support problems would get bad "in your AXIS_0 or AXIS_X or JOINT_0 section, there's a setting ..."
[16:12:20] <alex_joni> SWPadnos: I'm not sure atm how intensive the changes need to be/or will be
[16:12:58] <alex_joni> we definately want JOINT_<nr> sections.. agreed?
[16:13:05] <SWPadnos> yes
[16:13:12] <alex_joni> atleast for nontrivkins machines
[16:13:26] <SWPadnos> or even MOTOR_<nr> or something like that
[16:13:37] <SWPadnos> people using non-motor actuators can probably figure it out ;)
[16:13:43] <alex_joni> well.. a gantry has 2 motors but only one joint
[16:13:55] <SWPadnos> hmmm
[16:14:07] <SWPadnos> that'll be confusing for sure
[16:14:20] <alex_joni> ok, I think we should stick with JOINT_<nr>
[16:14:30] <alex_joni> now, the vast majority of users are on trivkins machines
[16:14:39] <alex_joni> 95%+ ?
[16:15:26] <alex_joni> according to
http://www.linuxcnc.org/component/option,com_poll/task,results/id,2/lang,en/ only 5.4% are on nontrivkins machines
[16:15:32] <SWPadnos> heh
[16:15:55] <SWPadnos> ok, so what do you do for a gantry?
[16:16:11] <alex_joni> treat it in hal?
[16:16:22] <alex_joni> have only one joint in the ini
[16:16:26] <SWPadnos> no, I think you still need UI support for homing
[16:16:31] <alex_joni> or have 2 joints in the ini, with nontrivkins, etc
[16:16:37] <alex_joni> gantrykins :D
[16:16:40] <SWPadnos> heh
[16:16:59] <SWPadnos> I think the only real problem is homing - we know how to synchronize two motors in HAL
[16:17:20] <alex_joni> did you see the recent "hack" for homing a gantry?
[16:17:38] <SWPadnos> so when you try to home, you have to move both motors in sync, and count the difference between their home positions, which you then continue to offset one motor by
[16:17:44] <SWPadnos> slam it into a rubber stop? :)
[16:17:58] <alex_joni> start homing, first motor that hits the switch gets disabled, second motor that hits the switch stops homing
[16:18:14] <SWPadnos> yep - I did see that
[16:18:20] <SWPadnos> you could do that in HAL even
[16:18:24] <alex_joni> right :P
[16:18:31] <alex_joni> that's why I said HAL before :)
[16:18:37] <SWPadnos> heh
[16:18:56] <alex_joni> cradek: mind sharing your ideas on this?
[16:19:07] <SWPadnos> that's not quite all you need, but it's most of the way there
[16:19:33] <SWPadnos> it only deals with the simple homing to a switch with no slow search afterwards case
[16:20:03] <alex_joni> you can probably extend it for afterwards too..
[16:20:33] <cradek> alex_joni: sorry I don't want to spend the time it deserves right now. I trust you guys.
[16:20:35] <SWPadnos> you have to deal with the direction of requested motion, homing state, and limit switches (and index)
[16:21:25] <alex_joni> SWPadnos: lets get back to trivkins ini file
[16:21:35] <alex_joni> cradek: ok, point taken
[16:21:53] <SWPadnos> heh - I should be in the same boat as cradek - not spending the time :)
[16:22:29] <alex_joni> cradek: without going into any details.. what do you think would be best for trivkins users in the ini (a couple [AXIS_X,Y,Z] sections?)
[16:24:03] <cradek> sure, or what it is now, I think it doesn't really matter
[16:32:50] <alex_joni> SWPadnos: I changed it a bit:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges
[16:33:26] <SWPadnos> hmmm. I think I'd go the other way :)
[16:33:34] <SWPadnos> read joints and pass them along
[16:34:02] <SWPadnos> maybe also read axis_# home positions and pass them along, otherwise use [TRAJ]HOME_POSITION (or similar)
[16:34:28] <SWPadnos> I think it's a better design if there is no "if trivkins do this else do that" step
[16:34:33] <alex_joni> what do you mean by "read joints and pass them along"
[16:34:44] <SWPadnos> section 3.1.1
[16:35:04] <alex_joni> ok, so all configs must have JOINT_<nr> ?
[16:35:18] <SWPadnos> yes, I think so
[16:35:33] <alex_joni> how do you do joint<-> axis mappings?
[16:35:48] <alex_joni> JOINT_0 refers to X?
[16:35:59] <SWPadnos> probably
[16:36:12] <alex_joni> that's one of the most common sources of confuseness in the past
[16:36:43] <alex_joni> "why are they called AXIS_0, AXIS_2 and AXIS_3" when I really want a XZA machine?
[16:37:41] <SWPadnos> ok, let's look at the possibilities:
[16:38:27] <alex_joni> lets talk about most of the users first (trivkins machine)
[16:38:39] <alex_joni> - with the others in mind
[16:39:24] <SWPadnos> for trivkins the only issue is what you just pointed out - a lathe has no Y
[16:39:40] <SWPadnos> and a rotary could be A B or C, so you could have a gap there
[16:39:46] <alex_joni> right
[16:39:54] <alex_joni> so what would be the possibilities?
[16:40:02] <alex_joni> having AXIS_0,2,3,5 as it is now
[16:40:09] <SWPadnos> COORDINATES=
[16:40:11] <alex_joni> having AXIS_X,Z,A,C
[16:40:37] <alex_joni> or having JOINTS_0,1,2,3 with mappings to X,Z,A,C somehow
[16:40:51] <SWPadnos> the basic problem is that there is no way to map joints to axes now
[16:40:56] <SWPadnos> it's implicit in the section name
[16:40:58] <alex_joni> well.. there is
[16:41:12] <alex_joni> but not with trivkins
[16:41:29] <alex_joni> only with gantrykins (you can set JOINT_* and have AXIS = 0
[16:41:37] <SWPadnos> also, if you stick to the definition of a joint as one actuator, a gantry does have two joints that drive one axis
[16:41:48] <alex_joni> then setp gantrykins.<somedetailIforgot> [JOINT_0]AXIS
[16:42:07] <SWPadnos> [JOINTMAP]
[16:42:10] <SWPadnos> X=0
[16:42:14] <SWPadnos> Y=2
[16:42:16] <SWPadnos> :)
[16:42:51] <alex_joni> anyways.. I think I'm enclined towards a more *easy* solution/config for the vast majority
[16:43:03] <alex_joni> and the generic joints stuff for the rest
[16:43:27] <SWPadnos> well, there's another way to do this, which keeps things easy for most people but makes it completely configurable for the advanced user
[16:43:57] <SWPadnos> use the names AXIS_# just as they are now if there's nothing telling you otherwise
[16:44:02] <alex_joni> hmm.. otoh.. the same simple machines will be configured by stepconf usually so maybe the whole thing is pointless
[16:44:09] <SWPadnos> but allow for a [MAPPING] section in the ini
[16:44:28] <SWPadnos> just stick section names there:
[16:44:30] <alex_joni> SWPadnos: can't do mapping on trivkins
[16:44:54] <SWPadnos> AXES=XZ
[16:45:00] <SWPadnos> AXIS_X=JOINT_0
[16:45:06] <SWPadnos> AXIS_Z=JOINT_1
[16:45:14] <alex_joni> can't do that
[16:45:24] <SWPadnos> no, I'm talking about section names
[16:45:41] <SWPadnos> you could say AXIS_X=LENGTHWISE
[16:45:43] <alex_joni> ahh
[16:45:48] <SWPadnos> AXIS_Z=CORSS_SLIDE
[16:45:50] <SWPadnos> CROSS
[16:46:05] <alex_joni> well.. it's still fubared
[16:46:08] <SWPadnos> actually, get rid of AXIS
[16:46:14] <alex_joni> because you need AXIS_Z=JOINT_2
[16:46:15] <SWPadnos> just AXES= X Z
[16:46:19] <SWPadnos> X=BED
[16:46:23] <SWPadnos> Z=SLIDE
[16:46:35] <alex_joni> and having JOINT_0 and JOINT_2
[16:46:48] <alex_joni> otherwise it won't work
[16:46:57] <alex_joni> pos->tran.z = joints[2];
[16:47:00] <SWPadnos> no, you need a way of telling HAL which motion.xx to connect to stepgen/PID y
[16:47:31] <alex_joni> SWPadnos: look at src/emc/kinematics/trivkins.c please
[16:48:04] <SWPadnos> I understand that there is a fixed mapping of RS274 names to axis.xx.motor-pos-cmd outputs
[16:48:15] <SWPadnos> (which should be joint.xx ....)
[16:48:50] <alex_joni> SWPadnos: then I'm missing something here
[16:49:09] <SWPadnos> ok - by default just do what's done now
[16:49:16] <SWPadnos> [AXIS_0] = X
[16:49:22] <SWPadnos> [AXIS_2] = Z
[16:49:30] <SWPadnos> etc
[16:49:44] <SWPadnos> that makes things no harder than they are now for trivkins
[16:50:14] <SWPadnos> though it doesn't make them easier - even trivkins is nontrivial when you get into gantries and missing joints/axes
[16:50:32] <SWPadnos> that's a separate problem though, I think
[16:50:41] <alex_joni> well one of them is (gantries)
[16:50:47] <alex_joni> as you need a different kins file
[16:50:54] <alex_joni> but missing joints/axes is just semantics
[16:51:16] <alex_joni> if the sections are called AXIS_X, AXIS_Z, etc I think it's quite easy for users to figure things out
[16:52:05] <SWPadnos> ok - I'm not strongly opposed to that
[16:52:12] <SWPadnos> I just thinik it'll
[16:52:14] <SWPadnos> gah
[16:52:38] <SWPadnos> I just think it'll get confusing for support if we have two or three different names for the joint setup sections
[16:52:57] <SWPadnos> so I'd prefer to allow only one, whichever one is "easiest"
[16:53:19] <alex_joni> for trivkins? or for everything?
[16:53:35] <SWPadnos> "easy" implies trivkins IMO
[16:53:54] <alex_joni> ok.. I'd say AXIS_[X,Y,Z,A,B,C,U,V,W] for trivkins
[16:53:56] <SWPadnos> if you're setting up a nontrivial machine, you can look at the manual and write your own ini file
[16:54:32] <SWPadnos> I would like it if trivkins would be extended to allow for gantries, but that's a mostly separate issue
[16:55:05] <alex_joni> right
[20:56:05] <cradek> http://timeguy.com/cradek-files/emc/concave-line2arc.png
[20:57:02] <alex_joni> whee.. it seems workable :)
[20:57:52] <cradek> going one case at a time, seems like there are a lot of them
[20:59:04] <cradek> I'll have to ask jepler to write a torture test like he did for the planner
[21:10:20] <alex_joni> hmm.. did you try that one?
[21:10:25] <alex_joni> or is it too hard to follow?
[23:34:50] <jmkasunich> hi guys
[23:34:59] <jmkasunich> I bet alex_joni is asleep
