any thoughts about probe compensation? http://timeguy.com/cradek-files/emc/0001-maintain-probe-compensation-values-and-use-them.patch
it looks straightforward enough
I wonder a few things: is it what is really needed for compensation? did I pick the right var numbers to use?
I wonder about existing probing code
it will work the same because these will default to zero
ok, but it's true that when you put in nonzeros existing code might not calculate the right things
for instance if you have a probe that's written as an X-only move, you can't assume that probed Y and commanded Y were the same
ok I see what you mean
maybe this is a bad idea and the user should do it himself if he wants (no reason this has to be hardcoded)
nice thing about this is that it accounts for units automatically
the user can now perform any desired calculation before logging the points
seems like the probe tip is considered a sphere
yes probe tips seem to be spheres
so you want to offset the probed point by the tip radius in the reverse direction of the move, too
I bet that depends
er, forget it
but that's an interesting idea
you don't know what spot on the sphere's surface touches
it's not necessarily the spot that's exactly in the direction of movement
why not just expand tool offsets to all 9 axes instead?
isn't this simply a tool offset you want?
then you don't have the "you didn't get what you asked for" problem
I'm not sure if it is or not
can you elaborate?
I was thinking about how even a perfect probe is likely to have a nonzero tool length
no, I don't think this is a tool offset thing
but you can compensate for that fine right now -- it's called TLO
if your probe is cockeyed by 1" in Y, then enter a TYO of 1 (or maybe I mean -1)
then when you write G0Y0X1 / G38.1X0 you know the tip starts centered at X1Y0 and its center moves along the line between there and X0Y0
ok, I finally see it
I guess I'm not sure how TLO is treated in probe results
looking at your patch, it seems that you actually are getting absolute machine coordinates in native units; is that right?
heck I don't know what coordinate system probe results are in
// first update internal record of last position
// now calculate position in program units, for interpreter
position = unoffset_and_unrotate_pos(pos);
ok, uh I guess I wrote that
so it's in native machine units (?) but at least it has offsets (including tool offsets?) unapplied
I think that moves it back into the active gcode coordinate system
unoffset_x subtracts tool offset
isn't that the behavior needed for my suggestion, except that there's no TYO?
yes I think so
adding all the tool offsets isn't too hard except for how they have to be in the tool table - I wish there was a good answer for that
you mean the tool file format, or something else?
yeah the file format problem
the answer to that is surely just "suck it up"
I still think it would be cool to make the format happen to also be valid gcode
yeah that would have good side-effects
there's something wrong with cpu frequency scaling on my laptop
it will get 'stuck' at 800MHz, even when at 200% CPU for awhile
Is the vti driver for the Vigilant Technologies PCI-ENCDAC 4 channel card still supported?
I don't think there was anything in the manual about it... but there is a sample config
I get this when I try and run the config "insmod: error inserting '/usr/realtime-2.6.15-magma/modules/emc2/hal_vti.ko': -1 No such device"
jthornton: when insmod fails, always look at dmesg
it must be like the Mesa cards and you have to have on in the PCI bus to load
VTI: ERROR: vti_init_card() failed
yes, looking at the source it looks for a specific pci device
contrary to the comments at the top, it does not have a base= parameter; I don't see any sign that there's an ISA variant of the board
ok, thanks for looking
should I add anything about it in the Integrators Manual?
looks like that driver was written by/added for Eric Johnson. If you want to write something, he is probably the person to get information from (like typical 'halcmd show' output to write documentation from)
it would be nice to have accurate documentation for every supported hardware interface, but I don't think a lot of new users are going to be buying that kind of card
jepler: seen the new Core i5 ?
seems that's gonna be even less usefull for emc2 :/
alex_joni: I don't pay much attention to processor news
they are quad-core processors
but if you only run one core, and the others are more or less idle
it will overclock the active core, so that total power isn't exceeded
but that means 6-7 multiplicator steps more on the active core (2.5Ghz -> 3.3 GHz or so)
I imagine running rtai in that condition is a bit of a problem
yes, for single-threaded software it's nice
mozmck1 is now known as mozmck
huh, wonder if jeff or sf sent that message twice
message-id is the same, other headers are different
found this in my local mail.llg:
Sep 26 07:58:51 lamp postfix/smtp: 1D9AD11514C: to=<firstname.lastname@example.org>, relay=mx.sourceforge.net[184.108.40.206]:25, delay=2343, delays=1719/0.02/5.2/619, dsn=4.4.2, status=deferred (conversation with mx.sourceforge.net[220.127.116.11] timed out while sending end of data -- message may be sent more than once)
mail.log, of course
EMC: 03bigjohnt 07v2_3_branch * r2813882a8695 10/docs/src/hal/basic_hal.lyx: Clear up examples and fix a few errors
do we still have digin and digout as shown in the HAL manual?
EMC: 03bigjohnt 07v2_3_branch * r78b3c13c9ce7 10/docs/src/hal/general_ref.lyx: Remove incorrect Encoder description.
whew, got the bridgeport moved out of its old corner in the shop
That can be fun
only a couple minorly squished fingers - so it was a success
I'm glad we have a fork lift... but we didn't have it when the BP arrived :)
yes that would be nice.
4" more of door would be nice too - I have to take the head way apart to get it through the door
do you know if EMC still has the HAL components digin and digout?
EMC: 03bigjohnt 07master * r5bbb4d0d11e2 10/docs/src/hal/general_ref.lyx: Remove incorrect Encoder Discription.
I don't know what those are/were supposed to be, but I'm sure we don't have them now
crap I can't spell today
if you have a checkout just look in rtlib/
ok will do thanks
nope none are there
EMC: 03bigjohnt 07master * r0b3887250e39 10/docs/src/hal/general_ref.lyx: Remove reference to removed components
EMC: 03bigjohnt 07v2_3_branch * r00f25e659cdb 10/docs/src/hal/general_ref.lyx: Remove reference to removed components
and they are gone
wonder what they were
hmm.. the only thing I see in an old checkout are references to canon digital in and out
which are actually guidelines how people writing drivers should code dig. i/o's
looked like some early work on digital input and outputs and analog
jthornton: you should revert those changes
are they still there?
they aren't "there"
the text you removed is reference for developers
how any I/O should be implemented in new drivers
* jthornton tries to figure out how to revert
so glad I never make mistakes or else I couldn't be laughing!
[22:42:13] <alex_joni> http://www.kernel.org/pub/software/scm/git/docs/git-revert.html
jthornton: we'll blame cradek anyways, he ok'd the commit
at least I asked alex first too
err.. I was distracted with xml+xsl+python
jthornton: so simply: 'git revert 0b3887250e39' in master
then you can either cherry-pick the new commit, or do the revert in v2_3 too (with the other commit..)
I can't cherry-pick the docs as they are different lyx versions
ah, ok.. then the revert
do I just ctrl x to Exit after the git revert?
err.. ctrl-x ?
I would have typed the git revert in a terminal..
then git push .. (but haven't tested this)
ok I didn't do a git push
EMC: 03bigjohnt 07master * rc246e7ebf53c 10/docs/src/hal/general_ref.lyx: Revert "Remove reference to removed components"
EMC: 03bigjohnt 07v2_3_branch * r0917fa27a41c 10/docs/src/hal/general_ref.lyx: Revert "Remove reference to removed components"
seems to have worked
and it is back in the HAL manual
alex_joni: I'm here now
jepler: managed to get it working myself ;)
would have had a question about python..
alex_joni: ah, glad I dodged it then
but it turned out to be something else
python is perfect
when I'm reading python code, I also get a feeling something's missing
there's too much magic going on ;)
* mozmck agrees with alex_joni!
If I call printf from a userspace component, where does the string get printed to?
EMC: 03bigjohnt 07v2_3_branch * r889bd4857023 10/docs/src/hal/basic_hal.lyx: Fix error in example