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