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