Back
[00:40:11] <cradek> any thoughts about probe compensation?
http://timeguy.com/cradek-files/emc/0001-maintain-probe-compensation-values-and-use-them.patch
[00:47:27] <jepler> it looks straightforward enough
[00:50:47] <cradek> I wonder a few things: is it what is really needed for compensation? did I pick the right var numbers to use?
[00:51:16] <jepler> I wonder about existing probing code
[00:51:27] <cradek> it will work the same because these will default to zero
[00:51:46] <jepler> ok, but it's true that when you put in nonzeros existing code might not calculate the right things
[00:52:13] <jepler> 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
[00:52:32] <cradek> ok I see what you mean
[00:53:08] <cradek> maybe this is a bad idea and the user should do it himself if he wants (no reason this has to be hardcoded)
[00:53:30] <jepler> nice thing about this is that it accounts for units automatically
[00:53:38] <jepler> but, yeah
[00:53:49] <jepler> the user can now perform any desired calculation before logging the points
[00:57:52] <jepler> seems like the probe tip is considered a sphere
[00:58:42] <cradek> yes probe tips seem to be spheres
[00:58:55] <jepler> so you want to offset the probed point by the tip radius in the reverse direction of the move, too
[00:59:20] <cradek> welllll
[00:59:29] <cradek> I bet that depends
[00:59:37] <jepler> er, forget it
[00:59:39] <cradek> but that's an interesting idea
[01:00:23] <jepler> you don't know what spot on the sphere's surface touches
[01:00:32] <jepler> it's not necessarily the spot that's exactly in the direction of movement
[01:00:56] <cradek> true
[01:05:56] <jepler> why not just expand tool offsets to all 9 axes instead?
[01:06:02] <jepler> isn't this simply a tool offset you want?
[01:06:31] <jepler> then you don't have the "you didn't get what you asked for" problem
[01:06:36] <cradek> I'm not sure if it is or not
[01:06:52] <cradek> can you elaborate?
[01:07:38] <jepler> I was thinking about how even a perfect probe is likely to have a nonzero tool length
[01:07:43] <cradek> no, I don't think this is a tool offset thing
[01:07:48] <jepler> but you can compensate for that fine right now -- it's called TLO
[01:09:20] <jepler> if your probe is cockeyed by 1" in Y, then enter a TYO of 1 (or maybe I mean -1)
[01:10:00] <jepler> 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
[01:12:43] <cradek> ok, I finally see it
[01:15:35] <jepler> I guess I'm not sure how TLO is treated in probe results
[01:16:04] <jepler> looking at your patch, it seems that you actually are getting absolute machine coordinates in native units; is that right?
[01:16:30] <cradek> umm
[01:16:38] <cradek> heck I don't know what coordinate system probe results are in
[01:17:53] <jepler> CANON_POSITION GET_EXTERNAL_PROBE_POSITION()
[01:17:57] <jepler> // first update internal record of last position
[01:18:01] <jepler> // now calculate position in program units, for interpreter
[01:18:06] <jepler> position = unoffset_and_unrotate_pos(pos);
[01:18:20] <cradek> ok, uh I guess I wrote that
[01:18:25] <jepler> so it's in native machine units (?) but at least it has offsets (including tool offsets?) unapplied
[01:19:23] <cradek> I think that moves it back into the active gcode coordinate system
[01:21:32] <jepler> unoffset_x subtracts tool offset
[01:24:51] <jepler> isn't that the behavior needed for my suggestion, except that there's no TYO?
[01:26:12] <cradek> yes I think so
[01:29:11] <cradek> 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
[01:30:00] <jepler> you mean the tool file format, or something else?
[01:30:12] <cradek> yeah the file format problem
[01:30:22] <cradek> the answer to that is surely just "suck it up"
[01:30:26] <jepler> yeah
[01:30:37] <jepler> I still think it would be cool to make the format happen to also be valid gcode
[01:31:06] <cradek> yeah that would have good side-effects
[01:33:37] <jepler> there's something wrong with cpu frequency scaling on my laptop
[01:33:56] <jepler> it will get 'stuck' at 800MHz, even when at 200% CPU for awhile
[11:37:51] <jthornton> Is the vti driver for the Vigilant Technologies PCI-ENCDAC 4 channel card still supported?
[11:39:41] <jthornton> I don't think there was anything in the manual about it... but there is a sample config
[11:45:56] <jthornton> 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"
[12:14:12] <jepler> jthornton: when insmod fails, always look at dmesg
[12:15:16] <jthornton> ok
[12:17:04] <jthornton> it must be like the Mesa cards and you have to have on in the PCI bus to load
[12:17:25] <jthornton> VTI: ERROR: vti_init_card() failed
[12:22:38] <jepler> yes, looking at the source it looks for a specific pci device
[12:23:16] <jepler> 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
[12:23:52] <jthornton> ok, thanks for looking
[12:24:11] <jthornton> should I add anything about it in the Integrators Manual?
[12:28:53] <jepler> 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)
[12:28:53] <jepler> 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
[12:29:44] <jthornton> ok thanks
[13:05:39] <alex_joni> jepler: seen the new Core i5 ?
[13:05:49] <alex_joni> seems that's gonna be even less usefull for emc2 :/
[13:06:17] <jepler> alex_joni: I don't pay much attention to processor news
[13:06:40] <alex_joni> they are quad-core processors
[13:06:53] <alex_joni> but if you only run one core, and the others are more or less idle
[13:07:18] <alex_joni> it will overclock the active core, so that total power isn't exceeded
[13:07:54] <alex_joni> but that means 6-7 multiplicator steps more on the active core (2.5Ghz -> 3.3 GHz or so)
[13:08:12] <jepler> that's interesting
[13:08:13] <alex_joni> I imagine running rtai in that condition is a bit of a problem
[13:08:29] <alex_joni> yes, for single-threaded software it's nice
[13:17:32] <mozmck1> mozmck1 is now known as mozmck
[15:01:35] <cradek> huh, wonder if jeff or sf sent that message twice
[15:01:45] <cradek> message-id is the same, other headers are different
[15:06:02] <jepler> found this in my local mail.llg:
[15:06:04] <jepler> Sep 26 07:58:51 lamp postfix/smtp[9368]: 1D9AD11514C: to=<
[email protected]>, relay=mx.sourceforge.net[216.34.181.68]:25, delay=2343, delays=1719/0.02/5.2/619, dsn=4.4.2, status=deferred (conversation with mx.sourceforge.net[216.34.181.68] timed out while sending end of data -- message may be sent more than once)
[15:06:21] <jepler> mail.log, of course
[15:22:53] <cradek> bizarre
[21:43:41] <CIA-7> EMC: 03bigjohnt 07v2_3_branch * r2813882a8695 10/docs/src/hal/basic_hal.lyx: Clear up examples and fix a few errors
[21:50:32] <alex_joni> jepler: around?
[22:19:08] <jthornton> do we still have digin and digout as shown in the HAL manual?
[22:21:43] <CIA-7> EMC: 03bigjohnt 07v2_3_branch * r78b3c13c9ce7 10/docs/src/hal/general_ref.lyx: Remove incorrect Encoder description.
[22:23:53] <cradek> whew, got the bridgeport moved out of its old corner in the shop
[22:24:19] <jthornton> That can be fun
[22:24:38] <cradek> only a couple minorly squished fingers - so it was a success
[22:24:50] <jthornton> I'm glad we have a fork lift... but we didn't have it when the BP arrived :)
[22:25:15] <cradek> yes that would be nice.
[22:25:30] <cradek> 4" more of door would be nice too - I have to take the head way apart to get it through the door
[22:25:48] <jthornton> do you know if EMC still has the HAL components digin and digout?
[22:26:15] <CIA-7> EMC: 03bigjohnt 07master * r5bbb4d0d11e2 10/docs/src/hal/general_ref.lyx: Remove incorrect Encoder Discription.
[22:26:26] <cradek> I don't know what those are/were supposed to be, but I'm sure we don't have them now
[22:26:40] <jthornton> crap I can't spell today
[22:26:56] <cradek> if you have a checkout just look in rtlib/
[22:27:08] <jthornton> ok will do thanks
[22:28:45] <jthornton> nope none are there
[22:31:23] <CIA-7> EMC: 03bigjohnt 07master * r0b3887250e39 10/docs/src/hal/general_ref.lyx: Remove reference to removed components
[22:34:42] <CIA-7> EMC: 03bigjohnt 07v2_3_branch * r00f25e659cdb 10/docs/src/hal/general_ref.lyx: Remove reference to removed components
[22:35:42] <jthornton> and they are gone
[22:36:00] <cradek> wonder what they were
[22:36:51] <alex_joni> me too
[22:38:50] <alex_joni> hmm.. the only thing I see in an old checkout are references to canon digital in and out
[22:39:06] <alex_joni> which are actually guidelines how people writing drivers should code dig. i/o's
[22:39:10] <jthornton> looked like some early work on digital input and outputs and analog
[22:39:41] <alex_joni> -name "cha:Canonical-Device-Interfaces"
[22:39:47] <alex_joni> oopsy.. ;)
[22:40:06] <alex_joni> jthornton: you should revert those changes
[22:40:23] <jthornton> are they still there?
[22:40:56] <alex_joni> they aren't "there"
[22:41:12] <alex_joni> the text you removed is reference for developers
[22:41:24] <alex_joni> how any I/O should be implemented in new drivers
[22:41:30] <jthornton> opps
[22:41:43] <jthornton> * jthornton tries to figure out how to revert
[22:41:57] <cradek> 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
[22:42:34] <alex_joni> jthornton: we'll blame cradek anyways, he ok'd the commit
[22:42:47] <cradek> at least I asked alex first too
[22:43:08] <alex_joni> err.. I was distracted with xml+xsl+python
[22:43:40] <alex_joni> jthornton: so simply: 'git revert 0b3887250e39' in master
[22:44:11] <alex_joni> then you can either cherry-pick the new commit, or do the revert in v2_3 too (with the other commit..)
[22:45:09] <jthornton> I can't cherry-pick the docs as they are different lyx versions
[22:46:17] <alex_joni> ah, ok.. then the revert
[22:51:52] <jthornton> do I just ctrl x to Exit after the git revert?
[22:53:49] <alex_joni> err.. ctrl-x ?
[22:54:10] <alex_joni> I would have typed the git revert in a terminal..
[22:54:23] <alex_joni> then git push .. (but haven't tested this)
[22:54:36] <jthornton> ok I didn't do a git push
[22:55:17] <CIA-7> EMC: 03bigjohnt 07master * rc246e7ebf53c 10/docs/src/hal/general_ref.lyx: Revert "Remove reference to removed components"
[22:55:43] <CIA-7> EMC: 03bigjohnt 07v2_3_branch * r0917fa27a41c 10/docs/src/hal/general_ref.lyx: Revert "Remove reference to removed components"
[22:55:59] <jthornton> seems to have worked
[22:57:03] <jthornton> and it is back in the HAL manual
[22:57:10] <jthornton> thanks alex_joni
[22:57:57] <jepler> alex_joni: I'm here now
[22:58:08] <alex_joni> jepler: managed to get it working myself ;)
[22:58:17] <alex_joni> would have had a question about python..
[22:58:25] <jepler> alex_joni: ah, glad I dodged it then
[22:58:29] <alex_joni> but it turned out to be something else
[23:01:10] <jepler> of course
[23:01:12] <jepler> python is perfect
[23:01:32] <alex_joni> perfectly dense
[23:02:02] <alex_joni> when I'm reading python code, I also get a feeling something's missing
[23:02:07] <alex_joni> there's too much magic going on ;)
[23:26:14] <mozmck> * mozmck agrees with alex_joni!
[23:36:56] <mozmck> If I call printf from a userspace component, where does the string get printed to?
[23:56:34] <CIA-7> EMC: 03bigjohnt 07v2_3_branch * r889bd4857023 10/docs/src/hal/basic_hal.lyx: Fix error in example