Back
[04:01:20] <CIA-22> EMC: 03jmkasunich 07new-telop * 10emc2/src/Makefile: replace old free mode TP, should be no functional changes - now working on branch
[04:01:31] <CIA-22> EMC: 03jmkasunich 07new-telop * 10emc2/src/emc/motion/ (command.c control.c homing.c motion.h): replace old free mode TP, should be no functional changes - now working on branch
[04:14:01] <fenn> ooo
[04:14:10] <fenn> somebody is working on teleop
[04:14:54] <jmkasunich> yep
[04:15:02] <jmkasunich> some stuff that we talked about in wichita
[05:14:46] <fenn> pyrex seems a lot easier than even swig:
http://wiki.aims.ac.za/mediawiki/index.php/Pyrex
[17:41:34] <jmkasunich> would anybody care if the cubic interpolator went away?
[17:41:59] <jmkasunich> in the mid 90's, it was used so the compute intensive kins and TP could run 1/10th as often as the servo code
[17:42:19] <jmkasunich> computers have gotten more than 10x faster since then
[17:45:47] <alex_joni> hmm.. if we decide it's needed it can come back again I guess
[17:46:57] <jmkasunich> as currently coded, I'm about 99% sure that the interp doesn't actually help things
[17:47:24] <alex_joni> interp = cubic interpolator?
[17:47:42] <alex_joni> for me interp = rs274ngc interpreter
[17:47:48] <jmkasunich> sorry
[17:48:09] <jmkasunich> I'm talking about motion - the interpreter doesn't exist at that level
[17:48:31] <alex_joni> I know.. that's what got me a bit confused ;)
[17:48:33] <jmkasunich> interp = cubit interpolator, I'll try to remember to at least say interpolator
[17:48:43] <alex_joni> cubic_i :)
[17:48:51] <jmkasunich> something like that
[17:49:09] <jmkasunich> I wrote cubit interp a second ago - I think Noah used one of those to build the ark
[17:49:49] <jmkasunich> I'm working on a block diagram of motion that I want to post and discuss - maybe a half hour or so....
[17:50:25] <alex_joni> ok, I'm aroung, although not very late tonight, as I want to get up at 6 tomorrow
[17:52:36] <jmkasunich> what time is it now?
[17:52:51] <alex_joni> close to 8pm
[17:52:55] <jmkasunich> (I need to get up early tomorrow too - gotta catch a plane)
[17:53:04] <alex_joni> so I still have 3-4 hours available
[17:53:06] <jmkasunich> but my early and your early aren't the same
[17:53:13] <jmkasunich> that should be plenty
[17:53:31] <alex_joni> I was thinking about G0 for nontrivkins
[17:53:44] <alex_joni> and I'm fairly sure it can be implemented really easy
[17:54:00] <alex_joni> the issue is that g-code can't express joint positions though.. :/
[17:54:25] <jmkasunich> G0 is by definition in cartesean space
[17:54:31] <jmkasunich> as is all g-code
[17:54:39] <alex_joni> it shouldn't imo :)
[17:54:42] <jmkasunich> or are you thinking of robotics stuff?
[17:54:58] <alex_joni> there should be a difference between G0 and G1 F99999999999
[17:55:19] <alex_joni> yeah, thinking of robotic stuff, and any nontrivkins I can think off
[17:55:40] <jmkasunich> what difference do you think there should be between G0 and G1 Fbig?
[17:56:01] <alex_joni> different trajectory
[17:56:11] <jmkasunich> oh
[17:56:14] <alex_joni> G1 Fbig is along a straight line
[17:56:29] <alex_joni> G0 should just move each joint from starting position to end position
[17:56:37] <alex_joni> easy and fast
[17:56:40] <jmkasunich> you mean, for G0, transform the endpoint into joint coords, and then make all joints go to that endpoint
[17:56:46] <alex_joni> right
[17:57:02] <alex_joni> although the transfor to joints is problematic
[17:57:12] <alex_joni> because of multiple solutions in some kins
[17:57:19] <jmkasunich> there might be some machines for which your G0 passes thru an illegal pose
[17:57:39] <alex_joni> jmkasunich: that's up to the programmer
[17:58:02] <alex_joni> a G0 might also pass straight through the workpiece
[17:58:02] <jmkasunich> what is the benefit (to the programmer/user) of your style of G0)?
[17:58:13] <alex_joni> the machine moves way faster
[17:58:54] <alex_joni> usually coordinated moves on robots are 30% of uncoordinated ones
[17:59:01] <jmkasunich> why?
[17:59:11] <alex_joni> probably to get rid of vel constraints
[17:59:37] <jmkasunich> I can see that in some special cases where one joint's motion subtracts from another an uncoordinated move might be faster, but in general the difference shouldn't be nearly that big
[18:00:04] <fenn> sounds like a great idea until you crash into something at > max vel
[18:00:17] <fenn> because it didnt follow a line
[18:00:20] <alex_joni> fenn: that's why you have teach-in on robots
[18:00:40] <alex_joni> and testing modes (where you run the program at 20% of max)
[18:00:45] <alex_joni> till it proves right ..
[18:00:46] <fenn> what you are arguing for is essentially the same argument as for dog-leg trajectories
[18:01:01] <jmkasunich> fenn: not exactly
[18:01:01] <fenn> which is universally agreed to be a Bad Idea
[18:01:13] <jmkasunich> dog-legs don't save any time
[18:01:18] <alex_joni> fenn: I'm only stating how robot controls do it
[18:01:27] <alex_joni> so far all of the ones I saw do it like this
[18:01:32] <jmkasunich> so its not a cost/benefit tradeoff, since there are no benefits
[18:01:39] <alex_joni> (I'm not saying we _must_ do the same in emc2)
[18:02:15] <alex_joni> as it is now, I don't see the current interpreter good enough for robots anyways
[18:02:36] <fenn> g-code is not good enough for robots
[18:02:37] <jmkasunich> robots have a bunch of issues
[18:03:01] <jmkasunich> emcmot commands would have to be changed - right now all we have is arc and line
[18:03:06] <jmkasunich> (and jogs)
[18:03:26] <jmkasunich> G0 is a line, just like G1, only diff is the velocity
[18:03:32] <fenn> it would be an inverse time joint level move
[18:03:59] <jmkasunich> even inverse time G1 are still lines at the motion level - the interp or task figures out what the velocity needs to be
[18:04:06] <jmkasunich> motion doesn't do inverse time
[18:04:29] <alex_joni> anyways, maybe we should drop this for now
[18:04:37] <alex_joni> jmkasunich was getting busy on a schem.
[18:04:46] <fenn> yes get back to your hacking and slashing
[18:05:08] <alex_joni> * alex_joni and fenn can argue some more :)
[18:05:09] <jmkasunich> right now what I'm aiming for is distinguishing between joints and axes, and providing correct and usefull jogging in both spaces
[18:05:25] <fenn> jmk did you read my last email to the list?
[18:05:40] <jmkasunich> that means scrapping the current teleop mode, and providing for keyboard and wheel jogs instead, in axis and joint space
[18:06:11] <jmkasunich> fenn: in the tool length comp thread?
[18:06:14] <alex_joni> fenn: see, I told you it was too long
[18:06:15] <fenn> yeah
[18:06:52] <jmkasunich> you and I are both fighting an uphill battle, because we are looking for a single meaning for UVW
[18:07:17] <jmkasunich> when in reality, every different group (like robot folks, 5-axis folks, EDM folks, etc) have a different meaning
[18:07:25] <fenn> the EDM guys are doing it wrong :|
[18:07:40] <alex_joni> don't forget wire-cutting machines
[18:07:51] <jmkasunich> I lump them under edm ;-)
[18:07:53] <fenn> but, if we can add joint-level control to emc, then we can have it both ways
[18:08:11] <alex_joni> fenn: 'xplain
[18:08:16] <fenn> in edm you're really concerned about the angle and position of the wire
[18:08:20] <jmkasunich> ultimately, kinematics determines the mapping of UVW to whatever
[18:08:27] <alex_joni> right
[18:08:48] <fenn> if you use kinematics of an xy/uv machine you can specify the angle of the wire you want
[18:09:08] <fenn> but i guess in 1980s that was not an option, so they just used joint level positioning
[18:09:16] <fenn> and called the extra joints UV
[18:09:32] <jmkasunich> you are saying that they should use A and B instead?
[18:09:39] <jmkasunich> and spec the taper in degrees?
[18:09:56] <fenn> yes, but i realize the futility in trying to change decades of cultural inertia
[18:10:18] <jmkasunich> besides inertia, there are real cases where UV would be preferred
[18:10:25] <fenn> like what
[18:10:30] <fenn> if you're moving more than one object?
[18:10:46] <jmkasunich> for example, suppose I'm making an extrusion die, where the inlet side is a simple circle, and the outlet is a complex form
[18:10:54] <jmkasunich> the angles are non-trivial to compute, and irrelevant
[18:11:06] <jmkasunich> I truly do want to describe two paths, one for each end of the wire
[18:11:34] <fenn> then you're doing something that is beyond the simple one-tool-object model
[18:12:04] <jmkasunich> no its not - the tool is a line connecting two points
[18:12:13] <jmkasunich> and the XYUV model works just fine
[18:12:33] <jmkasunich> tool length offsets obviously don't make sense with such a tool
[18:13:07] <jmkasunich> tool diameter offsets can make sense, dunno if the EDM folks would use TDO to compensate for wire diameter or not
[18:13:17] <fenn> i just dont like the concept of multiple paths, unless we explicitly acknowledge that there are two things moving
[18:13:44] <alex_joni> 2 things moving with the tool between them :)
[18:13:52] <fenn> that and the fact that the normal usage of UVW gets broken
[18:13:57] <jmkasunich> EDM is a case where we at least implicitly acknowledge that two things are moving
[18:14:10] <jmkasunich> if you are running EMC kins, you are moving two things
[18:14:15] <jmkasunich> bah
[18:14:21] <jmkasunich> if you are running EDM kins, you are moving two things
[18:14:49] <fenn> you're moving four things, X, Y, U, and V
[18:15:09] <alex_joni> well.. in that case for a regular 5-axis machine, you move 5 things?
[18:15:12] <jmkasunich> no, you are moving two things - the upper and lower wire guides
[18:15:27] <fenn> alex_joni: sure, as long as it has 5 joints
[18:15:28] <alex_joni> fenn: I thought you were asking about tools..
[18:15:35] <jmkasunich> in a conventional machine (3, 4, or 5 axis) you are moving one thing - the tool
[18:15:43] <fenn> dunno, i sorta lost track of what we were talking about
[18:15:48] <alex_joni> rofl
[18:16:04] <fenn> my tummy hurts.. too much ice cream, and its past my bedtime
[18:16:17] <jmkasunich> goodnight fenn
[18:16:26] <fenn> no, i was just whining
[18:16:31] <jmkasunich> darn
[18:16:38] <fenn> thanks :)
[18:17:19] <jmkasunich> I wish cradek was here, to talk about things like TLO along W, etc
[18:17:59] <fenn> redundant kinematics provides lots of interesting programming..
[18:18:08] <jmkasunich> in my ideal world, all the weirdness would be in the kins - but things like W axis TLO, and also arcs in UV, etc, must be in the interp
[18:21:13] <alex_joni> if we want to keep motion sane :)
[18:21:19] <jmkasunich> we do
[18:21:25] <fenn> one way of dealing with it is to provide weights or costs to different joints
[18:21:32] <jmkasunich> I'm trying to find the definition of U, V, and W
[18:21:40] <fenn> but then you dont have ultimate fine grained control over every detail
[18:22:23] <jmkasunich> thats one reason why g-code has UVW
[18:22:30] <fenn> UVW are simply three vectors. sometimes they are cartesian, sometimes they are aligned with the tool in some way, sometimes they are just references to joint coordinates
[18:22:54] <jmkasunich> I'm almost certain that NIST defined those axes as parellel to XYV, _not_ as relative to the tool
[18:23:05] <jmkasunich> XYZ
[18:23:16] <fenn> ok, but what is the value of that?
[18:23:52] <jmkasunich> things like redundancy - knee is Z, quill is W (or vice versa), lets the g-code tell you which one to move
[18:23:53] <fenn> we already have incremental moves and hal blocks (for summing onto X for example)
[18:24:34] <jmkasunich> we did not have hal blocks in 1995 when these things were defined, and hal blocks are not the right way to do that anyway
[18:24:45] <fenn> that's joint level control then, and has nothing to do with cartesian vectors
[18:24:47] <jmkasunich> the interp should be aware of what is going on, as much as possible
[18:25:16] <fenn> or are you saying the interp should have information about the machine's kinematics?
[18:25:17] <jmkasunich> I _think_ the 1995 version of UVW was intended to cover one of your cases only
[18:25:29] <jmkasunich> no
[18:25:50] <jmkasunich> I do believe the interp needs to know some minimal things about the machine kins
[18:26:26] <jmkasunich> specifically, you've defined three cases for UVW. Cartesean axies (parallel to XYZ), Cartesean axes (in the tool frame), and joints
[18:26:34] <fenn> maybe you're mixing interp up with task? i'm fuzzy on how it all actually works
[18:26:42] <jmkasunich> the interp needs to know which of those cases the machine uses
[18:26:57] <alex_joni> does it?
[18:27:25] <jmkasunich> I think so - things like W aligned TLO certainly need to know if W is parallel to Z or aligned with the tool
[18:28:03] <jmkasunich> this is why I want cradek here - he's thought about this more than I have - I only do motion control
[18:28:15] <alex_joni> hmmm..
[18:28:35] <alex_joni> but TLO and diameter compensation get applied before the stuff gets sent from interp to motion
[18:28:41] <fenn> what is the advantage to having direct control over whether W moves or not? vs specifying a cost to moving W (representing inertia or whatever)
[18:28:44] <alex_joni> so if motion gets the already modified values..
[18:29:05] <alex_joni> fenn: that's for case 1?
[18:29:11] <jmkasunich> alex_joni: exactly - the TLO mods happen in the interp, so the interp has to know something about the machine to do it right
[18:29:15] <fenn> alex_joni: yes
[18:29:25] <alex_joni> we were just talking case 2
[18:29:31] <alex_joni> which I think is more general than 1
[18:29:50] <fenn> er. "W aligned TLO" means you dont move the knee?
[18:30:18] <jmkasunich> fenn: W aligned TLO means that the tool length offset is applied to W, not to Z
[18:30:28] <fenn> ok, but.. what is W??
[18:30:37] <jmkasunich> if W happens to be tilted from Z, then some offset must also be applied to X and Y at the same time
[18:30:45] <jmkasunich> W is an axis ;-)
[18:30:48] <alex_joni> a Z axis which starts at the tool-base
[18:30:58] <alex_joni> with proper ""
[18:33:06] <jmkasunich> dang - about 40 mins since I said I'd have a drawing in 30 mins
[18:33:15] <fenn> one disadvantage to moving the kene throughout a cut is the accuracy of movement could be worse than the quill
[18:33:53] <jmkasunich> knees often have some sag about them - on the mills I've used, I like to move the knee, then lock the knee gib during a cut
[18:34:07] <fenn> do cnc's have automatic locks?
[18:34:13] <fenn> er, computer controlled
[18:34:13] <jmkasunich> no clue
[18:34:34] <jmkasunich> to be honest, most CNC'ed bports only have three axes - the knee remains manual
[18:34:37] <fenn> this would be a moot point but i'm worrying about hexapods with rotary attachments :)
[18:36:08] <jmkasunich> somebody should make a list of the different kins cases
[18:36:28] <jmkasunich> you can have cases where the number of inputs (XYZABCUVW) is greater than the number of machine joints
[18:36:35] <jmkasunich> those are overspecified, and something has to give
[18:36:40] <fenn> alex_joni: on a typical robot control, how do you specify moving the robot's gantry table vs moving the arm's end-effector in XYZ?
[18:37:00] <fenn> jmkasunich: the orocos project has pretty good list of kinematics types
[18:37:02] <jmkasunich> you can have cases where the number of inputs is less than the number of joints - 5-axis g-code driving a hexapod, for example
[18:37:22] <jmkasunich> fenn: with machine tool specific examples?
[18:37:32] <alex_joni> fenn: you don't have coordinate based moves
[18:37:49] <jmkasunich> I want a list with concrete examples and use cases that apply to machining
[18:37:50] <alex_joni> you store positions, the positions contain all currently controlled joints
[18:37:57] <fenn> aw that's cheating
[18:38:32] <alex_joni> fenn: try to express stuff for 18+ joints
[18:38:46] <fenn> you should be able to do that, which is why i asked
[18:39:06] <alex_joni> I don't see how you could do that ..
[18:39:26] <fenn> in martial arts for example there are different stances
[18:39:29] <alex_joni> but anyways.. you usually have a tooltip attached XYZABC for the robot only
[18:40:45] <fenn> in kendo, each stance has a set of attacks. the attacks are basically endpoints, but the stance tells you about the various joint configurations (arm up, arm down, foot forward, foot backward)
[18:41:13] <fenn> it's not an intractable problem
[18:42:41] <fenn> of course you have a common kinematic architecture, so that simplifies things a lot
[18:47:16] <fenn> g-code is too simple for this stuff to ever be easy
[18:57:51] <SWPadnos> hmmm. how would one program a UVW move when UVW are tooltip-aligned?
[18:57:57] <SWPadnos> the origin moves with the tooltip
[18:58:05] <alex_joni> SWPadnos: you wouldn't
[18:58:08] <SWPadnos> ok :)
[18:58:13] <alex_joni> you program XYZABC moves
[18:58:16] <SWPadnos> problem solved
[18:58:18] <alex_joni> and UVW tool offsets
[18:58:42] <fenn> i thought the point of UVW aligned to tool was for things like drill cycles
[18:59:05] <SWPadnos> ok - I was looking at jmkasunich's statement that you could have XYZABCUVW specified, which could be overconstrained
[18:59:07] <fenn> but obviously you'd have to be able to do custom cycles too
[18:59:12] <alex_joni> SWPadnos: not tool-tip aligned
[18:59:17] <SWPadnos> TOV ...
[18:59:19] <alex_joni> tool-holder aligned
[18:59:30] <SWPadnos> yep
[18:59:42] <alex_joni> but still, fenn makes an interesting point
[18:59:59] <fenn> they'd always be incremental moves right?
[19:00:04] <SWPadnos> yes, it's more of a plane specification than a programming facility
[19:01:24] <fenn> you could define a coordinate system with XYZABC and then move around in it instead
[19:01:28] <jmkasunich> well, cradek has done V aligned moves - he tilts the tool till its perpendicular to the surface of a triangle sitting on the table
[19:01:39] <jmkasunich> then issues a V move and it skims the surface of the triangle
[19:01:40] <cradek> people keep misunderstanding the UVW that I want on my machine (and that I therefore wrote into my kins) as some new vision or commandment from god that should apply to everyone
[19:01:49] <jmkasunich> I don't know if that is absolute or relative
[19:01:59] <cradek> it's just one thing you can do with the extra linear axes
[19:02:11] <jmkasunich> exactly - one of at least three
[19:02:16] <alex_joni> cradek: seen the 3 cases jmk defined above?
[19:02:22] <fenn> * fenn coughs
[19:02:23] <SWPadnos> for me it's more a question of what's generally useful, or at least generally understood
[19:02:37] <cradek> * cradek pokes Page Up 300 times
[19:02:40] <cradek> arg
[19:02:42] <SWPadnos> heh
[19:02:59] <SWPadnos> there aren't enough letters
[19:03:04] <fenn> 1) cartesian axes aligned with XYZ 2) cartesian axes aligned with tool(something) 3) joint coordinates
[19:03:15] <cradek> jmkasunich and I have talked about it a bit, so without reading back, I say he's probably right
[19:03:21] <cradek> :-)
[19:03:25] <SWPadnos> heh
[19:05:08] <jmkasunich> for case 3, the interpreter and task can be blissfully clueless - they just pass along what they read
[19:05:31] <jmkasunich> TLO applies to Z as always, TDO applies to X and Y as always, done
[19:05:42] <alex_joni> yay, we got one finished
[19:06:10] <fenn> 4) arbitrary vectors in cartesian space 5) arbitrary vectors in joint space :P
[19:06:23] <jmkasunich> fenn: bugger off
[19:06:45] <jmkasunich> do you really have reasonable use cases for those?
[19:07:22] <SWPadnos> even if there were, I'm not sure G-code can work for those
[19:07:47] <jmkasunich> I'm not sure if fenn was joking or not - either way I think those cases are a waste of time to think about
[19:07:48] <fenn> i can think of some, but UVW is not the best way to do it
[19:07:53] <fenn> i was joking
[19:08:04] <jmkasunich> good
[19:08:29] <jmkasunich> so, case 1: cartesean aligned with XYZ
[19:08:35] <fenn> still, the concept of being able to use arbitrary joint space vectors is nice
[19:08:37] <SWPadnos> arbitrary vectors are trivial since you can write your own HAL component to provide joint positions :)
[19:08:47] <jmkasunich> that means redundancy, like knee and quill
[19:09:03] <jmkasunich> waste of time, waste of time
[19:09:13] <SWPadnos> that is in at least one draft of the RS274NGC spec - I found it recently
[19:09:19] <SWPadnos> (UVW aligned with XYZ)
[19:09:31] <jmkasunich> I think that was the original definition of UVW
[19:09:49] <SWPadnos> yes, but I couldn't find it in at least one recent copy of the spec
[19:10:11] <cradek> brb, pizza
[19:10:28] <jmkasunich> anyway - if ABC are zero, then case 1 and case 2 (tool aligned cartesean) are the same
[19:11:45] <jmkasunich> I'm trying to think of a situation where at least one of ABC are non-zero but UVW are still aligned with XYZ
[19:12:02] <micges> logger_dev: bookmark
[19:12:02] <micges> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-02.txt
[19:12:28] <fenn> jmkasunich: a knee mill with a trunion table
[19:12:49] <jmkasunich> that is a case where you would NOT want them parallel
[19:13:02] <jmkasunich> well, maybe
[19:13:23] <jmkasunich> suppose you want to write your name on an angled face of the work
[19:13:51] <jmkasunich> you could tilt the work and then use XY, but that abandons the idea that XYZ are in work space
[19:14:05] <jmkasunich> since XYZ are now angled with respect to the workpiece
[19:14:24] <jmkasunich> actually, trunion tables are an interesting case even without the knee
[19:14:34] <fenn> or any angular movement
[19:15:00] <jmkasunich> if XY are relative to the work, then tilting the table and doing a Y move would require both quill and saddle to move
[19:16:12] <jmkasunich> suppose I want to engrave on an angled face, and I have two machines - one has a tilting head, the other tilts the work
[19:16:35] <jmkasunich> can I use the same g-code on both? should I? what should that g-code look like?
[19:17:07] <fenn> you could define a coordinate system with rotational offsets
[19:17:25] <jmkasunich> UVW centered on the tool does exactly that
[19:17:33] <fenn> not really
[19:17:53] <jmkasunich> splain
[19:18:43] <fenn> hmm, well there's a lot of differences
[19:18:58] <fenn> subroutines wouldn't work the same
[19:19:16] <fenn> adding angular cuts would be a big pain
[19:19:37] <fenn> it would pretty much have to be incremental moves
[19:19:47] <jmkasunich> I guess I have no clue what you meant when you said "coordinate system with rotational offsets"
[19:19:55] <fenn> take a chunk of space and rotate it
[19:19:55] <jmkasunich> lets go back to the case I proposed
[19:20:13] <jmkasunich> two machines, one tilts the head, one tilts the work, I want to machine something on an angled face of the work
[19:20:17] <fenn> just like you take a chunk of space and move it to get a g54 offset
[19:20:23] <jmkasunich> and lets NOT digress for a bit
[19:20:56] <alex_joni> jmkasunich: I don't think g-code can do both with the same program
[19:21:05] <alex_joni> as you can't define the point of rotation/tilting
[19:21:22] <jmkasunich> I think it should be able to
[19:21:32] <fenn> coordinate offsets are so bad already it wouldn't hurt to add a new way to use them
[19:21:35] <alex_joni> and the 2 machines obviously have different geometries
[19:21:55] <fenn> * fenn strains to hold back the tide of digression
[19:21:58] <jmkasunich> fenn: please don't go off on tangents
[19:22:31] <jmkasunich> alex_joni: if g-code describes part geometry, then you should be able to use the same g-code for both cases - its the same part
[19:22:51] <jmkasunich> the kins would need to know where the centers of rotation are, but thats a kins problem
[19:22:53] <alex_joni> afaik g-code doesn't describe part geometry
[19:23:14] <alex_joni> that's what CAD does, CAM then translates the part geometry into machine movements (g-code) to build that part
[19:23:20] <jmkasunich> maybe thats part of the issue - some people think it does, and want to use it that way
[19:23:28] <fenn> g-code describes tool paths though, surely we can agree on that
[19:23:32] <alex_joni> but CAM definately needs to know about your machine..
[19:23:41] <alex_joni> fenn: I can agree on that
[19:23:50] <jmkasunich> g-code describes tool-paths some of the time
[19:24:01] <alex_joni> but I can't see how those tool paths are "portable"
[19:24:03] <jmkasunich> as soon as you put tool diameter offsets into the picture, thats not true
[19:24:22] <fenn> diameter comp is a gross hack
[19:24:38] <jmkasunich> irrelevant - it exists, and people use it
[19:24:40] <fenn> oops i'm digressing
[19:24:46] <alex_joni> it's poor man's CAM ...
[19:24:54] <alex_joni> no account for cutting shape, etc
[19:25:14] <jmkasunich> I can agree with that - and I'll extend it to say that UVW are a poor man's CAM too
[19:25:34] <alex_joni> jmkasunich: sounds ok to me as a definition :P
[19:25:40] <alex_joni> wanna stick it in the docs? :P
[19:26:03] <jmkasunich> lets ignore UVW for a moment, and go back to my example
[19:26:09] <alex_joni> k
[19:26:32] <jmkasunich> for the tilting head machine, its not hard - you can say "tilt the tool by 20 degrees, and then follow this path in workpiece coords"
[19:26:46] <fenn> *crash*
[19:26:50] <jmkasunich> where "this path" takes the tilt into account, moving Y and Z to cut the angled face
[19:27:01] <jmkasunich> fenn: why?
[19:27:11] <fenn> didnt you just tilt the head by 20 degrees?
[19:27:15] <jmkasunich> yea
[19:27:25] <fenn> and the tool swings around in an arc?
[19:27:29] <jmkasunich> sorry, let me be more precise:
[19:27:53] <jmkasunich> you can say "tilt the tool by 20 degrees, with the center of tilt at its tip, and then follow this path in workpiece coords"
[19:28:34] <jmkasunich> kins can do that, trivially if the tool length is fixed, less trivially if the length varies - but thats a kins problem - g-code can certainly describe what I just wrote
[19:28:44] <fenn> but it's not really workpiece coords, since they're parallel to XYZ
[19:29:30] <jmkasunich> if I want to machine a 20 degree angled flat on a part, I can say tilt 20 degrees, then move sin(20) in Z and cos(20) in Y
[19:29:49] <jmkasunich> and I'll get my angled face, without ever using UVW or any weird coords
[19:30:34] <jmkasunich> can we agree on that much?
[19:32:24] <fenn> sin(20) and cos(20) are always <= 1, so wouldn't the face be smaller than your programmed xyz dimensions?
[19:32:36] <fenn> er, XY dimensions
[19:32:39] <jmkasunich> nitpick nitpick
[19:32:45] <jmkasunich> K*sin(20), OK?
[19:32:57] <fenn> well, i had to think about it
[19:33:15] <jmkasunich> my point is that you can machine a 20 degree flat without using anything but XYZA
[19:33:22] <jmkasunich> on a tilting head machine
[19:33:25] <alex_joni> sure thing
[19:33:32] <alex_joni> even on one with a tilting workpiece
[19:34:01] <alex_joni> jmkasunich: is it XYZA?
[19:34:23] <jmkasunich> yeah, rotate around X (A), then machine using Y and Z
[19:34:31] <alex_joni> sorry.. right
[19:34:47] <fenn> actually i think what would happen is you'd get a sort of trapezoidal hunk taken out of the workpiece (like a dovetail)
[19:35:01] <jmkasunich> what?
[19:35:10] <fenn> oh crap sorry nevermind
[19:35:22] <alex_joni> fenn: no, you first go along the tool (using XZ move)
[19:35:29] <alex_joni> then sideways.. etc
[19:36:41] <jmkasunich> damn what I wouldn't give for a whiteboard and the ability to point
[19:37:01] <fenn> you'd do YZ move then X then YZ then X
[19:37:15] <jmkasunich> for this conversation we can completely ignore X - assume that you don't need to make a cut any wider than your tool
[19:37:58] <jmkasunich> also assume that you can cut as deep as you want in one pass, so you don't need to worry about stepping down
[19:38:34] <fenn> i think alex and I each had one of those assumptions :)
[19:39:26] <jmkasunich> anyway, with the tilting head machine, you tilt A by 20 degrees, then cut along YZ, using slopes of sin(20) on Z and cos(20) on Y
[19:39:42] <alex_joni> right
[19:39:49] <jmkasunich> the center of rotation for the tilt needs to be at the tooltip
[19:39:58] <alex_joni> and entry/exit with cos(20) on Z and sin(20) on Y
[19:40:38] <jmkasunich> if the mechanical center of rotation is not at the tooltop, kins can adjust Y and Z during the tilt, so the tool does pivot around its tip
[19:40:59] <fenn> ok, where are you going with this?
[19:41:19] <jmkasunich> heh - I want to move from tilting tool to tilting work
[19:41:35] <fenn> same thing, kins takes care of it
[19:41:45] <jmkasunich> thats what I'd like
[19:41:52] <jmkasunich> but not how it works now
[19:42:06] <jmkasunich> with tilting work, you tilt A, then move Y only - Z doesn't move
[19:42:09] <fenn> only because you are using joint level control (tivial kinematics)
[19:42:17] <jmkasunich> because when you tilted the work, you didn't tilt XYZ
[19:43:14] <alex_joni> jmkasunich: so for the tilting head machine you attach UVW to the tool
[19:43:16] <fenn> with tilting work, using kinematics, Z should move (if you arent at the center of rotation)
[19:43:28] <alex_joni> and for the tilting workpiece machine, you attach UVW to the workpiece
[19:43:34] <jmkasunich> alex_joni: lets not bring UVW into it yet
[19:43:36] <alex_joni> after both tiltings you can machine in UVW
[19:43:47] <alex_joni> * alex_joni takes UVW back
[19:43:53] <fenn> er, "joint 2" should move, not "Z"
[19:44:00] <jmkasunich> what you described would still not be able to use the same g-code
[19:44:21] <jmkasunich> I'm suggesting that XYZ should _always_ be attached to the workpiece
[19:44:37] <fenn> agreed
[19:44:57] <fenn> unless you do something like rotational coords
[19:45:07] <fenn> s/coords/work offsets/
[19:45:10] <jmkasunich> then you could cut that angle by doing G1 A20; G1 Z[len*sin(20)] Y[len*cos(20)]
[19:45:31] <jmkasunich> fenn: pleeeeeease stop digressing into things that don't even exist yet
[19:46:32] <jmkasunich> rotational offset may well be a good feature, but they have absolutely nothing to do with what we are talking about
[19:46:50] <jmkasunich> I'm talking about being able to cut the same part on two machines with the same g-code
[19:47:16] <jmkasunich> this stuff is hard enough to talk about over the interweb when we stay focused
[19:47:44] <jmkasunich> you know, just forget this
[19:48:04] <jmkasunich> its taken a half hour to convey an incredibly simple concept that is just the tip of the iceberg
[19:48:07] <jmkasunich> it will never work
[19:48:09] <fenn> hah
[19:49:07] <fenn> i thought it already did work
[19:49:15] <jmkasunich> "it" = this discussion
[19:49:38] <fenn> cutting the same part with the same code (with angular moves in it) on two different machines
[19:49:46] <jmkasunich> and no, you cannot machine the same part with the same g-code on tilting head and tilting table machines today
[19:50:21] <alex_joni> jmkasunich: I need to run for a while, gotta grab some things from work
[19:50:25] <alex_joni> back in 30 mins
[19:50:29] <jmkasunich> ok
[19:51:08] <fenn> so, you can't cut the same part on the maxnc as on a puma560?
[19:51:25] <jmkasunich> not without re-writing the program
[19:51:38] <fenn> i dont believe that
[19:52:02] <fenn> sure the puma560 will be slow and weird, but it will move the tool to the same position
[19:52:15] <jmkasunich> we have vismach models of puma and I think max5 (or a bridgemill variant with the same joints) - show me
[19:54:02] <fenn> ugh. hang on a while, computer problems
[19:54:52] <fenn> x crashes on my laptop when i run vismach and axis at the same time
[19:55:08] <fenn> not an emc bug
[19:55:12] <jmkasunich> the last time I played with the bridgemill sim, it wouldn't even jog right in cartesean space - fixing that is where I started, and I wish I had been smart enough to stay there
[20:00:49] <fenn> 5axis kins are screwy
[20:01:29] <jmkasunich> well yeah, thats the gist of this whole discussion isn't it?
[20:02:17] <fenn> oops disregard that last comment, i had modified the config file
[20:02:48] <jmkasunich> I would not be even remotely surprized to see strange things happening when you try to run the bridgemill
[20:04:43] <fenn> i needed a 'basic mill' to test out my 'virtual rotary table' and 5axis was the closest thing
[20:07:15] <jmkasunich> cradek: (or anybody else)
[20:07:26] <jmkasunich> what is joint 8 on the 5-axis sim?
[20:07:53] <fenn> W
[20:08:03] <jmkasunich> joint 8, not axis 8
[20:08:13] <jmkasunich> when I jog it, nothing moves
[20:08:38] <jmkasunich> I haven't gone into axis mode yet, still in joint moce
[20:08:40] <jmkasunich> mode
[20:08:50] <fenn> you have to specify 9 joints if you want to use the 9th axis (w)
[20:09:05] <jmkasunich> oh, you mean "a bug"
[20:10:27] <jmkasunich> loads of those actually
[20:11:00] <fenn> jmkasunich: basically i dont know how to "show" you angular moves in vismach, except for something real basic like g0 a45
[20:11:43] <fenn> since W aligned with tool orientation only seems to work with 5axis kins
[20:12:03] <fenn> so my original idea of using cone.ngc failed spectacularly
[20:12:11] <jmkasunich> I am convinced that the same g-code will not work with tilting table and tilting work
[20:12:39] <jmkasunich> where "work" means "produce the same part"
[20:12:54] <jmkasunich> bah, I can't talk
[20:13:05] <jmkasunich> tilting tool and tilting work
[20:14:46] <fenn> hmm there's no tilting work kinematics yet
[20:15:19] <jmkasunich> man, 5-axis is really borked
[20:15:32] <fenn> why do you say that?
[20:15:43] <jmkasunich> cause its full of weirdness
[20:15:59] <fenn> right when you start up, switch to world mode
[20:16:02] <jmkasunich> I probably should run head instead of code that has my changes in it
[20:18:05] <jmkasunich> same result
[20:19:03] <fenn> pumakins has this annoying habit of going 'nan'
[20:19:04] <jmkasunich> F1, F2, home-all, View->WorldMode, jog x a bit, jog y a bit, jog Z a bit, jog B a bit, jog C and get a soft limit message
[20:19:36] <jmkasunich> clear the message, and jogs are borked - if I attempt a C+ jog it goes a tiny tiny bit and stops, a C- jog goes about 20 degrees and stops
[20:20:55] <fenn> how far did you jog in C?
[20:21:06] <jmkasunich> tried to to all the way around
[20:21:25] <jmkasunich> ok, repeated without the xyz jogs
[20:21:46] <jmkasunich> jogged B to 74 degrees, and tried a complete circle in C, got a soft limit
[20:22:52] <jmkasunich> jogging C- now seems to go 30 degrees and stops (with no messages), jogging C+ goes about 0.1 degrees and stops
[20:23:29] <jmkasunich> probably teleop bugs
[20:24:41] <fenn> ok i see that (C- goes 40 degrees and C+ goes 3 degrees)
[20:25:57] <fenn> an MDI move seems to reset the behavior
[20:27:02] <fenn> actually just switching to MDI
[20:27:41] <jmkasunich> yeah, teleop is borked
[20:29:26] <jmkasunich> thats ok, I intend to debug teleop with a gas axe anyway
[20:34:28] <fenn> heh kins and vismach dont quite match up, so my circle is a potato chip shape
[20:34:56] <fenn> but it did do what i expected once i got all the axes homed and zeroed
[20:42:41] <alex_joni> back..
[20:43:55] <fenn> jmkasunich: both of these were cut at a 45 degree angle in B:
http://fennetic.net/pub/irc/puma-cursive.png http://fennetic.net/pub/irc/5axis-cursive.png
[20:48:48] <alex_joni> * alex_joni pukes over
http://en.wikipedia.org/wiki/Oblate_spheroidal_coordinates
[20:49:02] <cradek> I think I never got U,V kins right on anything but max
[20:53:22] <jmkasunich> at this point I've stopped caring about anything except making teleop work
[20:54:26] <alex_joni> what parts of teleop did you notice aren't/weren't working before?
[20:54:33] <jmkasunich> cradek: do you know what kins are in 5-axis?
[20:54:49] <alex_joni> (except the regular hickups when errors show up, modes are switched, etc)
[20:54:59] <jmkasunich> alex_joni: isn't that enough?
[20:55:10] <alex_joni> that's not an issue in the teleop code itself
[20:55:27] <alex_joni> there are a couple of bugs I noticed
[20:55:50] <alex_joni> * you can sometimes move the machine in world mode (when not properly homed, usually right after starting up)
[20:56:15] <cradek> jmkasunich: yes I wrote them
[20:56:17] <fenn> that's not a bug it's a feature :)
[20:56:26] <jmkasunich> things that suck (some of which may be "bugs", some of which are architecture issues)
[20:56:26] <alex_joni> fenn: no, it's not
[20:56:44] <alex_joni> if you do that, and then switch to joint mode and try to home it won't ever work
[20:56:45] <jmkasunich> 1) having to have a joint 8 just because you want axis W
[20:56:48] <alex_joni> because of another "feature"
[20:57:02] <jmkasunich> 2) world to joint transitions
[20:57:11] <jmkasunich> (that code is absolutely horrible)
[20:57:14] <alex_joni> jmkasunich: that's a architecture issue num_joints == num_axes
[20:57:27] <jmkasunich> doesn't mean it doesn't suck
[20:57:37] <alex_joni> oh, I totally agree it sucks
[20:57:56] <alex_joni> and I started "fixing it" once, and got lost in the details
[20:58:03] <alex_joni> it's horrible :)
[20:59:55] <jmkasunich> it looks like somebody must have fixed something, because the last time I played with 5-axis, I could get B spinning about 500 RPM
[21:00:19] <alex_joni> oh, too bad you can't anymore :)
[21:00:36] <jmkasunich> 3) Teleop ignores soft limits
[21:00:56] <alex_joni> oh-oh..
[21:01:04] <alex_joni> * alex_joni wonders if he should say anything
[21:01:15] <jmkasunich> about?
[21:01:19] <alex_joni> soft limits
[21:01:31] <alex_joni> how do you think those are defined?
[21:01:40] <jmkasunich> in joint space
[21:01:52] <alex_joni> and how do you think they get applied? ;)
[21:01:58] <jmkasunich> I know
[21:02:07] <alex_joni> same as speed and accel constraints
[21:02:25] <jmkasunich> its a mess
[21:02:31] <alex_joni> it really is
[21:02:39] <fenn> so, joint numbers to axis letters seems easy enough
[21:02:49] <alex_joni> fenn: really?
[21:03:33] <fenn> apply this
http://cvs.linuxcnc.org/cvs/emc2/src/emc/task/taskintf.cc.diff?r1=1.79;r2=1.80 and then change all the config files that rely on silly joint numbering
[21:05:18] <fenn> basically you're using axis_mask as a bit vector, rather than just a number
[21:05:43] <alex_joni> fenn: it's 11pm, and I need to go to bed soon
[21:05:50] <fenn> yeah me too
[21:05:54] <alex_joni> but before that I need to finish another important email
[21:06:04] <alex_joni> so anything beyond conceptual is unfortunately out for me
[21:06:21] <alex_joni> can't affort starting to think about implementation details atm
[21:07:39] <jmkasunich> implementing without a concept isn't a good plan anyway
[21:07:45] <alex_joni> right
[21:07:57] <jmkasunich> IMO, we need [AXIS] and [JOINT] sections in the ini
[21:08:02] <alex_joni> that's why I said I want to stick around a bit, the concept I'm interested in
[21:08:04] <jmkasunich> with the appropriate values in each one
[21:08:23] <jmkasunich> well, I've given up for the moment on any high level stuff (userspace, inifile, etc)
[21:08:33] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges
[21:08:34] <jmkasunich> I'm still trying to do my drawing of motion
[21:09:24] <alex_joni> that's some old stuff I started working on, and it's not fully thought through..
[21:09:42] <jmkasunich> better than nothing though
[21:09:55] <jmkasunich> and better than starting from scratch on IRC
[21:10:16] <alex_joni> well.. you might not remember, but we talked about this back then
[21:10:22] <jmkasunich> I believe that COORDINATES and AXES are not needed
[21:10:22] <alex_joni> february 2007
[21:10:30] <jmkasunich> AXES is always 9 (was always 6)
[21:10:39] <alex_joni> ok, I can agree with that
[21:10:42] <jmkasunich> and COORDINATES are always XYZABCUVW in that order
[21:10:51] <alex_joni> yes and no
[21:10:58] <jmkasunich> there may be a desire to mask display of some axes
[21:11:05] <alex_joni> you need a way to tell the GUI what the appropriat axes are for teleop jogging
[21:11:19] <alex_joni> right
[21:11:27] <jmkasunich> but thats not the same as allowing arbitrary things like XYYZ or AXYB
[21:12:16] <jmkasunich> [AXIS_X]
[21:12:23] <jmkasunich> JOGABLE=1
[21:12:25] <alex_joni> well.. I didn't mean arbitrary things..
[21:12:28] <jmkasunich> UNITS=LINEAR
[21:12:34] <alex_joni> ok, sounds good
[21:12:49] <alex_joni> JOG_INCREMENTS=...
[21:12:56] <jmkasunich> yeah, stuff like that
[21:13:01] <alex_joni> JOG_SPEED,etc
[21:13:24] <jmkasunich> jog speed comes from the sliders, regardless of whether you are jogging a joint or an axis
[21:13:35] <alex_joni> DEFAULT_JOG_SPEED
[21:13:46] <jmkasunich> but yes - the general idea of per-axis stuff and per-joint stuff
[21:13:51] <alex_joni> the one that AXIS uses to position the slider initially
[21:13:52] <jmkasunich> some things will appear in both axes and joints
[21:13:56] <alex_joni> right
[21:14:00] <jmkasunich> others are joint only, like scale
[21:14:05] <alex_joni> feel free to extend that page if it helps..
[21:14:37] <alex_joni> on my page:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Alex_Joni I started with some things needed to clean up this joint/axes mess
[21:15:03] <jmkasunich> should I attempt to retain history, or can I go ahead and remove things like [TRAJ]AXES (from the wiki page)
[21:15:21] <alex_joni> you can do what you please
[21:15:30] <alex_joni> there is a backup from 1-2 weeks ago ;)
[21:15:55] <jmkasunich> there is also history in the wiki I think
[21:16:03] <alex_joni> yeah, that too
[21:18:49] <fenn> per-axis seems like a waste of time to me, if it's not based on joint limits
[21:19:19] <jmkasunich> per axis what?
[21:19:33] <fenn> accel, velocity, position
[21:19:53] <jmkasunich> I think I agree, sort of
[21:20:10] <fenn> a more sophisticated way to define a cartesian workspace would be handy
[21:20:28] <jmkasunich> each cartesean axis can (and IMO should) have its own limits, etc, but by default they vel and accel limits should come from the TRAJ section
[21:20:41] <jmkasunich> any value in the [AXIS_X] section would override the default
[21:21:12] <fenn> can you give me a specific case where you want to limit an axis velocity or accel?
[21:21:22] <jmkasunich> not off the top of my head
[21:21:34] <jmkasunich> which is why I'd take the defaults from the TRAJ section
[21:22:03] <jmkasunich> so the 99.999% of people who want the same limits on all axes don't have to screw around duplicating that value in 6 or 9 places
[21:22:09] <fenn> right
[21:23:06] <fenn> hey does ini format support redirection? like [AXIS_X] vel = [TRAJ] vel
[21:23:38] <alex_joni> nope
[21:23:46] <alex_joni> but that's not an issue..
[21:24:26] <fenn> well if you have a mill with three identical axes you could change all the joint values with one variable
[21:24:27] <alex_joni> fenn: you could have examples where you want to limit an axis..
[21:24:38] <fenn> (or six)
[21:24:39] <jmkasunich> does today's TRAJ section have DEFAULT_ACCEL and MAX_ACCEL?
[21:24:41] <alex_joni> but for the general cases it can live without
[21:24:46] <alex_joni> jmkasunich: yes
[21:24:52] <jmkasunich> I would think that default accel only makes sense if you are gonna have an accel slider
[21:24:55] <alex_joni> not sure if DEFAULT_ACCEL is ever used
[21:25:38] <jmkasunich> if we have it, we should have different ones for linear and angular, just like velocity
[21:28:15] <jmkasunich> hmm, the per-axis defaults and max'es present a problem for the GUI
[21:28:26] <jmkasunich> should it re-render the slider based on what axis you have selected?
[21:28:37] <alex_joni> or have lots of sliders :)
[21:28:48] <alex_joni> whatever.. that's GUI design issues..
[21:28:59] <alex_joni> not the problem now.. if it's in the ini it's up to the GUI
[21:29:13] <jmkasunich> if its not in the INI, the GUI doesn't have to worry about it
[21:29:15] <alex_joni> if it's not in the ini, then the GUI *has* to implement it only one way
[21:29:19] <jmkasunich> we can put it in the ini later
[21:29:47] <jmkasunich> hmm, I think we are talking past each other
[21:29:56] <fenn> * fenn doesnt see what ini has to do with what the GUI is capable of
[21:30:12] <fenn> a "complete" gui would have a way to send every NML message
[21:30:28] <jmkasunich> I'm suggesting that if we define [AXIS_X]MAX_VELOCITY, even if nobody _ever_ puts it in their ini, we are making the GUI writer think about and cover the case where each axis has a different limit
[21:30:38] <fenn> or at least the ones that make sense for a GUI
[21:30:47] <alex_joni> or he can just ignore the ini entry and move on
[21:30:56] <jmkasunich> that won't work
[21:30:57] <alex_joni> but the point is it's up to the GUI designer
[21:31:08] <alex_joni> oh, MAX_VELOCITY?
[21:31:33] <jmkasunich> suppose the GUI has a single jog speed slider, and its is set on 50, but AXIS_X has a max velocity of 40 (all other axes are 60)
[21:31:55] <jmkasunich> what does the GUI do when the user tries to jog X? can't send a "jog X at 50" message
[21:31:57] <alex_joni> then a poorly designed GUI won't change while selecting X
[21:32:04] <alex_joni> you can send a jog at 50
[21:32:09] <alex_joni> but it will only go at 40
[21:32:20] <alex_joni> just like a program can select a F of 99999999
[21:32:21] <jmkasunich> ok, you convinced me
[21:32:41] <alex_joni> it's up to TP to clamp ;)
[21:33:03] <alex_joni> just as it does now with FO
[21:34:28] <jmkasunich> trying to think of the variable name for "this axis is used"
[21:34:48] <alex_joni> what context?
[21:35:06] <jmkasunich> [AXIS_X]ENABLE = 1 [AXIS_V]ENABLE=0
[21:35:09] <alex_joni> machine can move along that axis?
[21:35:19] <jmkasunich> so V doesn't appear on DRO, can't be jogged, etc
[21:35:27] <alex_joni> ok, gotcha
[21:35:52] <jmkasunich> I suppose the total absence of a section is an easy way to disable it
[21:36:25] <alex_joni> FAQ-#1
[21:36:31] <alex_joni> why can't I jog my machine in X?
[21:36:47] <alex_joni> Answer1: you didn't define an [AXIS_X] section
[21:36:54] <jmkasunich> cause you don't have an [AXIS_X] in your inifile
[21:37:03] <alex_joni> we have a winner :P
[21:37:15] <alex_joni> ok, sounds sane so far
[21:37:46] <jmkasunich> otoh, if every file contains [AXIS_X] through [AXIS_W] sections, some with ENABLE=0 in them, that question might not arise
[21:38:08] <jmkasunich> but I hate the clutter
[21:38:50] <fenn> what other parameters would you put in [AXIS_X]
[21:39:17] <jmkasunich> so far, I have HOME (cartesean home position), and optional MAX_VEL and MAX_ACC
[21:39:25] <jmkasunich> travel limits I guess
[21:39:41] <fenn> hmm
[21:41:52] <fenn> if we make users do drastic changes to their ini files, we should go with a better markup language than .ini
[21:42:22] <jmkasunich> and what would that be?
[21:42:35] <alex_joni> .oni
[21:42:49] <fenn> demon lover!
[21:42:50] <alex_joni> .c#
[21:43:19] <alex_joni> have an abstract template declared for the axis section
[21:43:22] <fenn> jmkasunich: yaml and slip-xml are easy to understand
[21:43:27] <alex_joni> then you need to inherit and expand that :)
[21:43:34] <alex_joni> * alex_joni stops kidding
[21:44:17] <jmkasunich> fenn: you gotta be shitting me
[21:44:51] <fenn> or straight python
[21:45:30] <jmkasunich> * jmkasunich turns the fenn filter back on
[21:47:25] <jmkasunich> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges
[21:47:49] <jmkasunich> I only did the first one
[21:48:24] <alex_joni> jmkasunich: a math wiz would probably slap you
[21:48:30] <alex_joni> but it's good enough for me
[21:48:41] <jmkasunich> why the slappage?
[21:48:48] <alex_joni> "the machine doesn't have those axes"
[21:48:59] <alex_joni> but it's only wording..
[21:49:08] <jmkasunich> axes = plural of axis, what is wrong with that?
[21:49:13] <alex_joni> can't move along those axes maybe
[21:49:28] <alex_joni> but I don't think you can define a carthesian coord. system with axes missing
[21:49:30] <jmkasunich> ah, space always hase those axes
[21:49:43] <alex_joni> anyways, not important
[21:49:54] <alex_joni> </nitpick>
[21:50:00] <jmkasunich> fixed
[21:50:31] <jmkasunich> more precise would be "those axes can't appear in g-code for this machine"
[21:51:08] <alex_joni> yeah.. that's another "feature" in emc2 atm
[21:51:27] <alex_joni> if g-code with such words is encountered, the machine simply hangs
[21:51:38] <cradek> not true
[21:51:43] <cradek> it now gives a real error
[21:51:48] <alex_joni> cradek: has this been fixed?
[21:51:49] <alex_joni> yay.
[21:51:58] <alex_joni> it used to be a while ago..
[21:52:07] <jmkasunich> I was about to say I thought I saw such an error when I did an MDI with an A value on 5-axis
[21:52:20] <alex_joni> ok, great
[21:52:29] <alex_joni> (actually it was a trap to delurk cradek)
[21:52:36] <jmkasunich> and it worked!
[21:52:52] <jmkasunich> he tends to relurk though
[21:52:54] <cradek> curses!
[21:52:58] <alex_joni> heh
[21:53:07] <jmkasunich> <cradek>bbl
[21:53:39] <cradek> ``Bad character 'w' used''
[21:54:09] <jmkasunich> I'm gonna change the scara ini on that page to use the new syntax, and do a lathe version
[21:54:35] <SWPadnos> aaahhh - ok. I thought there was something odd about the scara ini section
[21:55:50] <alex_joni> cradek: my bad, great that you fixed it :)
[21:56:18] <cradek> I think jepler did most or all of that fix
[21:56:38] <alex_joni> jepler: great that you fixed it
[21:57:16] <alex_joni> * alex_joni is here on and off.. packing my bag
[21:57:22] <jmkasunich> alex_joni: does the Z axis on a scara have a name?
[21:57:28] <jmkasunich> other than Z?
[21:58:50] <fenn> i dont think anyone mentioned that users are lazy by nature and won't go through their .ini files changing axis_0 to joint_0 and then adding new values for axis_x, they'll just copypaste and change the names
[21:59:27] <fenn> not to mention trying to get everyone to understand the subtle technical difference between axis and joint and why they have to change their perfectly good ini file
[22:00:14] <jmkasunich> fenn: those are all reasons why we should have done this ages ago so we wouldn't have so many lazy users to correct
[22:00:26] <jmkasunich> but I'm sick of it being wrong, and its time to bite the bullet
[22:00:51] <jmkasunich> multi-axis stuff just plain sucks when you don't use the proper terminology
[22:03:03] <fenn> can we at least change the joint numbers in hal at the same time? so there's only one format change
[22:03:41] <jmkasunich> joint numbers?
[22:03:54] <fenn> so scara would have joint 0 1 2 3
[22:04:08] <jmkasunich> you mean, change from axis.0.motor-pos-cmd to joint.0.motor-pos-cmd?
[22:04:20] <fenn> yes that too (forgot about that)
[22:04:35] <jmkasunich> of course - that was assumed from the very beginning
[22:05:25] <fenn> ug i need to go to bed, goodnight
[22:05:36] <jmkasunich> goodnight
[22:06:36] <alex_joni> fenn: and we can always publish "converters"
[22:06:44] <alex_joni> which do the proper sed with the inis
[22:06:58] <alex_joni> jmkasunich: no, not that I know of
[22:07:03] <alex_joni> I only know names for puma
[22:07:11] <alex_joni> like shoulder, wrist ,etc
[22:07:12] <jmkasunich> I just used "z-slide"
[22:07:31] <alex_joni> fairy nuff
[22:08:34] <alex_joni> there is another thing we can do for trivkins
[22:08:47] <alex_joni> have an AXIS = <axis_letter> for each joint
[22:09:07] <alex_joni> that will then work with gantrykins as it is now
[22:09:33] <jmkasunich> I don't even know what gantrykins does
[22:09:35] <SWPadnos> that would get interesting for homing gantries
[22:09:57] <jmkasunich> if gantrykins uses two AXIS for one cartesean direction, then IMO it is wrong
[22:09:59] <SWPadnos> it lets you use more than one motor per axis, like a dual-drive gantry
[22:10:15] <jmkasunich> I knew that - I meant I didn't know how it did it
[22:10:19] <SWPadnos> oh :)
[22:10:25] <jmkasunich> some XXYZ abomination?
[22:10:45] <alex_joni> jmkasunich: it maps axes and joints arbitrarly
[22:10:54] <alex_joni> well.. userassigned actually
[22:10:56] <jmkasunich> a three axis gantry with two screws for X should only have X, Y, and Z axes
[22:11:03] <alex_joni> right
[22:11:07] <alex_joni> so it will have
[22:11:21] <alex_joni> [JOINT_0] AXIS = X
[22:11:24] <alex_joni> [JOINT_1] AXIS = X
[22:11:28] <alex_joni> [JOINT_2] AXIS = Y
[22:11:32] <alex_joni> [JOINT_3] AXIS = Z
[22:11:48] <alex_joni> and only [AXIS_X] [AXIS_Y] [AXIS_Z]
[22:12:17] <jmkasunich> so gantrykins and trivkins can be the same module really
[22:12:31] <alex_joni> yes
[22:12:41] <alex_joni> and ideally called generickins or soemthing like that
[22:12:52] <alex_joni> gantrykins is too narrow for what it can do
[22:13:06] <jmkasunich> any machine where a joint(s) follows simply one axis would use that module, and specify which axis with [JOINT_n]AXIS=
[22:13:23] <SWPadnos> the homing issue still exists
[22:13:31] <alex_joni> SWPadnos: for gantries
[22:13:39] <jmkasunich> homing is a joint issue
[22:13:42] <alex_joni> but with gantrykins you could define something like:
[22:13:48] <SWPadnos> for parallel machines in general, I think
[22:13:52] <alex_joni> [JOINT_0] AXIS = Y
[22:13:56] <alex_joni> [JOINT_1] AXIS = X
[22:14:00] <jmkasunich> again, IMNSHO I don't think you should be able to get into world mode (axes) until joints are homed
[22:14:08] <jmkasunich> not sure everybody is gonna agree with that
[22:14:15] <SWPadnos> jmkasunich, that's true, but when two joints are physically connected together, the two joints have to be controlled in tandem
[22:14:18] <alex_joni> why wouldn't they..
[22:15:47] <jmkasunich> gantry homing code is a project in itself
[22:15:53] <alex_joni> right
[22:16:01] <alex_joni> and a can of different worms :)
[22:16:08] <jmkasunich> just cause gantrykins sends the same command to both joints doesn't mean it won't break something
[22:16:50] <SWPadnos> sure, and recovering from e.g. a single motor stall is far from trivial
[22:17:51] <jmkasunich> thats the kind of stuff that a real gantrykins (as opposed to generickins) can and should do
[22:18:12] <jmkasunich> or maybe that needs to be done outside of kins, below the joint level instead of above it
[22:19:17] <jmkasunich> I'm pretty sure my gantry is gonna use two screws connected to one motor by a belt ;-)
[22:20:06] <alex_joni> how about a lathe with synchronized head and tailstock
[22:20:10] <SWPadnos> cheater
[22:20:18] <alex_joni> those are harder to do with a belt..
[22:20:38] <alex_joni> heh, btw.. seen the timingbelt pulley done by drilling?
[22:20:49] <jmkasunich> yeah, kind of cleverl
[22:20:52] <jmkasunich> -l
[22:21:54] <alex_joni> back to topic
[22:23:30] <jmkasunich> I forgot the topic
[22:23:42] <jmkasunich> inifile changes? I think the wiki is a good place for those
[22:24:00] <jmkasunich> teleop? still working on my drawing (well, more talk than work)
[22:24:23] <jmkasunich> but the general plan for teleop is that axis space jogs will work exactly like joint space jogs
[22:24:27] <jmkasunich> including wheels, etc
[22:24:42] <jmkasunich> I intend to seriously revise the mode-changing code
[22:24:52] <cradek> kickass
[22:25:00] <jmkasunich> there are four modes, disabled, joint, world, and coord
[22:25:07] <alex_joni> jmkasunich: if there's fun to share.. let me know
[22:25:19] <alex_joni> I might be available the next couple of days to throw in some code
[22:25:21] <jmkasunich> and I intend to define the conditions etc for switching between modes
[22:25:44] <alex_joni> what's the difference between world and coord?
[22:26:13] <jmkasunich> world is decoupled - each axis is controlled by a single axis planner, driven by keyboard or wheel jog commands
[22:26:25] <jmkasunich> coord is coordinated - all axes move together, driven by the main TP
[22:26:33] <alex_joni> hmm..
[22:26:41] <alex_joni> how does the single axis planner work?
[22:26:50] <jmkasunich> same as the current jogging planner
[22:26:57] <alex_joni> doesn't it need to run through kins, and move more than one joint?
[22:27:09] <alex_joni> what happens when 2 axes are beeing jogged?
[22:27:13] <jmkasunich> it has a current position and vel, a target position, max_vel and max_acc
[22:27:36] <jmkasunich> the world mode planners are upstream of kins, so yes, it runs thru kins
[22:28:07] <jmkasunich> there are 9 of them - when you switch into world mode they are primed with the current cartesean pose, if you move one (or more), the pose changes
[22:28:07] <alex_joni> so the output from all planners need to be merged
[22:28:18] <jmkasunich> from that point on everything is the same for world and coord
[22:28:34] <alex_joni> output beeing joint cmd's
[22:28:46] <jmkasunich> yes, all axes get merged into a cartesean pose, that goes thru kins to get joint commands
[22:29:10] <alex_joni> ah, so the merge is before the kins
[22:29:24] <alex_joni> (that does kinda feel like coordinated to me..)
[22:29:30] <jmkasunich> yep - kins always needs a complete pose as inpit
[22:29:32] <jmkasunich> ut
[22:29:42] <SWPadnos> it probably is coordinated, but you're controlling axes independently
[22:29:57] <alex_joni> ok, I understood it now
[22:30:36] <alex_joni> so world is actually teleop as it is now (for nontrivkins) ?
[22:32:20] <jmkasunich> http://jmkasunich.com/pics/emc2-motion-dataflow.pdf
[22:32:47] <jmkasunich> yes, world is what we call teleop now - jogging in cartesean instead of joint space
[22:33:18] <jmkasunich> but it will be based on existing jogging code, not on the completely differnent teleop code as it is today
[22:33:45] <CIA-22> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/emc_mods.c: fix off by one error of s32 pins
[22:34:22] <jmkasunich> in that drawing, the first switch (after "single axis traj planner") is up for coord mode, down for world (aka teleop)
[22:34:46] <jmkasunich> the second switch is up for world and teleop, down for joint (aka free)
[22:35:26] <alex_joni> hoa, hold your horses for a while :)
[22:35:42] <jmkasunich> I still have to draw the stuff that follows the last switch, and the entire feedback path
[22:36:14] <alex_joni> there's another thing
[22:36:15] <jmkasunich> what's wrong with my horsies?
[22:36:25] <alex_joni> they are a bit fast ;)
[22:36:33] <alex_joni> single joint traj planner has another input
[22:36:37] <alex_joni> homing code
[22:36:53] <jmkasunich> homing is to the right of everything in that drawING
[22:37:09] <alex_joni> hmm.. redesign?
[22:37:15] <jmkasunich> not really
[22:38:07] <jmkasunich> http://www.linuxcnc.org/docview/html//code_Code_Notes.html#r3_2
[22:38:23] <jmkasunich> that is the existing joint control block diagram
[22:38:36] <jmkasunich> it will go pretty much unchanged on the right hand side of the new drawing
[22:39:31] <jmkasunich> see the switch that switches between "free mode" and "teleop & coord mode"? in the old drawing? that is the second switch in the new drawing
[22:39:40] <alex_joni> oh ok
[22:40:08] <alex_joni> I confused single joint traj planner with free planner as it was before
[22:40:29] <jmkasunich> the single joint planner is the same code as the old free planner
[22:40:51] <alex_joni> I thought the free planner also took care of homing
[22:40:52] <jmkasunich> it was inline, I pulled it out and slightly objectified it so we can have single axis planners wherever we need them
[22:41:09] <jmkasunich> s/took care of/is used by/
[22:41:21] <alex_joni> right
[22:41:28] <jmkasunich> homing is a state machine, that issues commands to the free mode planner - that won't change
[22:41:41] <alex_joni> ok, so then my point is valid
[22:41:43] <jmkasunich> kb and wheel jogs are disabled, and the homing state machine takes over
[22:42:02] <jmkasunich> what point?
[22:42:03] <alex_joni> another arrow towards single joint traj planner, marked homing
[22:42:13] <jmkasunich> yes, good idea
[22:42:54] <alex_joni> hmm.. too bad I can't stick around much longer
[22:42:54] <alex_joni> gotta get up in 5h :/
[22:44:10] <jmkasunich> ouch
[22:44:26] <jmkasunich> well, I'll post the finished drawing (same place as it is now)
[22:44:34] <jmkasunich> and we can discuss tomorrow or whenever
[22:44:51] <jmkasunich> I'm traveling too, so I probably won't be online till after dinner my time - very late your time
[22:45:05] <jmkasunich> (traveling one time zone west, so that will make it even worse)
[22:46:24] <alex_joni> heh
[22:46:25] <jmkasunich> dinner time..... goodnight alex, have a safe trip
[22:46:30] <alex_joni> well. it's been fun as usual
[22:46:40] <alex_joni> thanks, it's not really far, hope to be back by evening
[22:46:44] <alex_joni> night all
[22:46:51] <SWPadnos> see you Alex
