on the axis/joints thing
I'm opposed on principle to anything that pretends a joint is an axis
that includes saying "if trivkins, then joint_0 = axis_X, etc
joint to axis mappings should be explicit - either by the specific kins module, or for trivkins, somethin like [AXIS_X] JOINT_NUM = 0 [AXIS_Y] JOINT_NUM=2
I'm also opposed in principle to having some kluge that says "if no joint sections, assume trivkins and pretend that AXIS sections are really joints
at that rate, you'll NEVER get people converted to the correct form
cradek: do you want all constant-z for the tool comp torture test?
cradek: do you want changing feeds yet?
jepler: it should change Z sometimes since that is allowed. The feeds should change, and it should definitely use inverse time mode sometimes
none of that will work yet of course
that one arc case is not even done - somehow the test program with the correctly compensated arc that I showed off earlier was a fluke! if I increase the radius it goes wrong.
(I'm still not sure I'll actually be able to pull this off.)
I wonder if line-only would have any actual value, or if it would just confuse the issue.
I guess that's what I get for doing the easiest cases first
cradek: G0 moves?
good question. G0 is allowed with comp on, but it is treated specially
I'm afraid it's going to be hard to tell what behavior is right
unless the gcode "makes sense" (has some closed paths that seem like they could be part outlines)
maybe we should start with some 2.5D shapes made up of arcs and lines
maybe they could be a lot like the example I've been showing: a path that's taken as nominal, right, and left
sorry I hadn't really thought about what I actually want.
jmkasunich, I think we more or less agree on what to do for joints/axes
I could be swayed, but I think if there are going to be ini file changes, let's just bite the bullet and convert, not do things the old way or the new, not with automagic "if we think it should be the simple way let's assume stuff"
now we just need to convince alex
I'm not sure where to put the mapping information
oh - the way you had it was in the joint section
hmmm. I think that would still require kins knowledge for the ini code - it has to know whether that should be ignored, which I think it should for a non-trivkins machine
we can be sneaky
crap, maybe we can't
heh - I was going to ask in what way
I was thinking the loadrt that loads the kins could pass the ini file data to trivkins as insmod params
one of my design parameters is to have stupid init code. the less it knows about what's actually going on (and the less it has to do differently depending on that), the better
but that loadrt isn't "loadrt trivkins <trivkins args>", it is "loadrt [KINS]KINSMODULE <can't really stick specific params here>"
no file access and all that jazz
well, the code that does "loadrt kins" can do file access
IOW, if I was writing my own hal file, I could write "loadrt mykins something=[KINS]SOME_MYKINS_PARAM1 something_else=[KINS]SOME_OTHER_MYKINS_PARAM"
I'm not sure you could pass all that data to a module - I think you need floats and stuff
there MUST be some mechanism to convey kins-specific data to the kins code
unless you've already converted to machine units there
for hexapod kins, you have to send some geometry info, for scarakins you send arm lengths, etc
there is, it's a question of defining it in the ini file, making it easy for the 94.5% of users that use trivkins, and (for me anyway) making the code as simple and unaware of what it's doing as possible
the kinses currently make hal params for that stuff
oh, so you add setp lines after the loadrt kins line
right - you have HAL params for some of it, it's the joints that have NML messages set up
the more I think about the arbitrary mapping of axes to joints, the less simple it gets
it is good for things like lathes - no more trying to trick the machine into skipping an axis
yes, even if you don't allow for gantries by just having more than one [AXIS_N]JOINT=2
gantries need their own kins, IMO
so we have "trally trivial kins"
XXY or anything like that is an abomination
"mostly trivial kins" - like lathes or XYZB
"not quite trivial kins" - like gantries (which can use nontrivkins)
"really weird kins" like hexapods or cable-cams
does that cover most of it?
crap - I didn't want to get into this now
oops - the first one was "really trivial kins"
the cat finally jumped off my lap about 15 mins ago, and I started working on my part again
ok - not a problem. I think we have a few weeks before a decision has to be made :)
(or maybe months ;) )
generates 25 short path fragments at different X, Y starting locations; each one is composed of a move to the fragment start; maybe turn on compensation (G41.1 with a specified D-number); then 4 moves, then G40 to turn off compensation, then a final move.
slick, thank you
I'll check it out tomorrow
many of the paths it generates are overlapping, but some may be useful in seeing what is going on
I'll add Z-changes, feed changes, and whatever else you want when that is useful to you
each move may be an arc or a line
cradek: "A positive Q value causes the leading edge of the tool to cut more heavily. Typical values are 29, 29.5 or 30."
is this true for internal threads as well?
yes I think so; you should be able to easily see it in the preview to be sure
yeah, that looks right
something else isn't
(probably my error, checking now)
huh, I don't think I've ever actually cut an inside thread with it
for some reason, as soon as jmk asked the question, I was reminded of Martin Short in the movie "Merlin", piloting a boat and talking about "Treacherous waters, evil beasts" ... :)
ah, I is offset from drive line, not absolute
thats better, but there is still something fishy
shouldn't all return moves be along the drive line?
I don't remember for sure. I think they're not, so entries are always the same length so it syncs
but that means that the return moves get closer to the work
in my case, the drive line was just a tiny distance from the inside thread peaks (not a lot of room to back off)
is it different from when you were doing external?
so the later return moves will crash into the thread peaks
I don't recall
oh really? that sounds bad
I can change the sign of I and look a the preview
when I wrote that I worried about the "tight for space" problem
external does the same thing
but I gotta look closer
it may be pulling out more in the early passes, so that it ends up at the drive line
I'm gonna turn off tapered entry to make it easier to understand the preview
it might need a tweak...
falling asleep.... goodnight
ok, it does respect the drive line - it won't cut into peaks
but it does retract back behind the drive line in the early passes (so that the last pass will retract to the drive line)
that could result in a rub on the inside of a small hole
you get a better thread if you allow some accel distance before it starts cutting - velocity overshoot - really bad pitch error
EMC: 03jepler 07v2_2_branch * 10emc2/share/axis/tcl/axis.tcl: from TRUNK: didn't get entire keypad fix last time.
EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: new fix
it looks like adding the right compiler flag (-mtune=i686 or -Os are two candidates) would make doubles atomic in gcc-generated code
both probably have small effects on code speed -- since few if any people are actually running on pentiums or ppros, -mtune=i686 would probably increase the code speed a tiny bit.
userspace on dapper gets a default -mtune=pentium4, while the kernel is probably getting -mtune=pentium based on CONFIG_M586TSC=Y)
although in practice using -mtune=i686 isn't a problem, it would make the design of EMC2/HAL reliant on that - ie, it changes the requirement from "any 486 or Pentium-class chip with a TSC" to "any PPro or P2"
PPro isn't 686 iirc
ppro and p2 are basically the same thing
the P2 was optimized to run 16-bit software better - the ppro sucked at that
* skunkworks_ still has a pentium pro
hi guys. sorry that cvs is down -- there's a network problem. no eta to the fix.
no sweat from my end..
* alex_joni is having fun with lrm
what is lrm anyway?
or lum for that matter
it's too bad - I downloaded the hardy beta CD, plus the ubuntu studio DVD for testing on my laptop
the beta doesn't correctly enable the nvidia drivers, and there isn't any way I can see to enable them
and the ubuntu studio boot menu option says "install ...", not "boot ...", so I didn't want to boot up (since I don't want to install it at the moment)
last time I tried it on a NVidia card, I had to enable the nonfree drivers from the menu somewhere
and it automatically downloaded and installed the lrm module
(that was on feisty I think)
I was able to install using the restricted modules manager on Feisty, even when booted from the LiveCD
in this case though, the restricted modules are shown as installed and up to date, but the restricted modules manager doesn't show any hardware that needs them - the window is empty
hmm.. can't check that here, cause I'm on i945 or whatever it's called
heh - darned open-source drivers ;)
yeah, they happen to just work
damn - that's the fastest response I've had from anyone about any purchase. ever
I ordered some DVDs of the Zeitgeist Movie, but they were old ones without subtitles
I emailed saying that, and one minute later (my mailbox check interval) I had a response "send me your address, I'll send you new ones"
yeah. so now I have 12 of them :)
or I will soon
hmm, I noticed they made compiz crap out gracefully
you barely even notice when the window managers restarts
it does "click" when you enable it, but then yes, it dies and says your hardware isn't useful (when the nvidia driver isn't present ...)
I meant that over here it mostly works
but once in a while it segfaults or whatever
I see the menus disappear for a couple of seconds, but then it's back
interesting. my wife has been using it on 7.04 for a while, and it hasn't crapped out yet
jepler_ is now known as jepler
cvs should be restored
works from here
< 2h total
hmm.. crap having some issues compiling emc2 here
EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: line->outside of arc, outside of arc->line
[22:59:57] <alex_joni> http://pastebin.ca/958819
I traced that to src/hal/classicladder/calc.c
disabling the RT build for CL gets the rest compiled just fine
wtf is that I wonder
hmm.. I also noticed 1-2 other strangenesses
I'm missing rtai_shm
let me rebuild the rtai package
jepler: I used your rtai source, but it seems it doesn't install symlinks
cradek: how can I search for files and symlinks using find?
find . -type f -type l ?
find . -type f -or -type l
well.. crap, still getting the same error for classicladder-RT as before
whine.. there's not tab completion for ./configure in hardy anymore
you may need to source the completion script in /etc/somewhere