Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-04-09.txt
EMC: 03cradek 07master * r0074a4789679 10/docs/src/gcode/ (4 files in 2 dirs): add a bit more to the g76 section and markup fixes
EMC: 03cradek 07master * rb8eb1be3d826 10/src/emc/kinematics/tc.c: Approximately fix overblending of arcs.
EMC: 03cradek 07master * r10990ad37af9 10/configs/common/configurable_options/pyvcp/ (m5i20panel.xml parportpanel.xml): Fix panels to use correct disable pin spelling
EMC: 03cradek 07master * r4018a76cd3c5 10/lib/python/pyvcp_widgets.py: Fix inconsistance spelling of disable pin option
EMC: 03cradek 07master * r4ca13e5d0674 10/src/emc/rs274ngc/rs274ngc_return.hh: Remove unused string after merge of tlo_all_axes
EMC: 03cradek 07master * r15b145450f4d 10/src/po/pl.po: Updated Polish translations
EMC: 03cradek 07master * ree4f691d383f 10/docs/src/hal/pyvcp.lyx: added some missing info on disable pins
EMC: 03cradek 07master * rd12728e00d40 10/docs/src/common/User_Concepts.lyx: Fix wrong discription for G61
EMC: 03cradek 07master * rf642d5da3f57 10/docs/src/Master_User.lyx: Change order of chapters
EMC: 03cradek 07master * r2662f56a49ec 10/ (13 files in 10 dirs): Merge branch 'v2.4_branch'
[14:39:13] <cradek> http://timeguy.com/cradek-files/emc/0001-Export-motor-offset-to-HAL.patch
cool. I had thought about that
I wonder if this is sufficient to satisfy those needs being discussed on the list
but the latest mail by dave has a point - you can probably do this in HAL, if you're clever about thread ordering
I thought there was already an offset pin
I've only tried it on sim, and oddly the offset switches between two close values when I home repeatedly
isn't the difference between joint_pos_cmd and motor_pos_cmd the offset?
not quite, because I think screw comp and backlash comp cause more offset
but that's one of the reasons I'm reluctant to push this - I don't understand all of it
I should at least try it on a machine with index homing first
I probably won't have time for a while though
It seems like a misplaced request anyway
well, I definitely see the value for an index homed machine
I can't tell if the machine in question gets turned off
it would be great if you could detect 'it occasionally loses 4 encoder counts'
it could be of interest on any machine that has real homing
sure, but you can only detect that when you re-home
usually after noticing that something doesn't look right
and you can't home in G-code, it's a manual process
so the machine can't check itself
if the problem is minor you might never notice. it'd be nice to be able to test it.
well, fwiw, an machine with index encoders CAN monitor itself, but that's another issue
yeah. I'm just not sure how useful it really is
yes, the machine can check its position whenever an index arrives - that's useful
yeah except our encoder interface sure doesn't support it
the encoder interface doesn't have to
hmmm. well actually I guess it does
no, actually the index input (with parport and Mesa) is available to HAL, which is all that's needed
pico, STG, etc. wouldn't work
at the end of being on all day, it'd be very nice to be able to verify that no encoder counts have been lost... On my machine a count is a micron. It would take a pretty huge number of them lost for me to notice.
what do you mean index input is available to hal?
move very slowly, look for index in software, check encoder counts when encoder is seen
with hostmot2, aren't all the I/O pins readable in HAL, even if they're attached to an advanced function?
IMO that's so limited and inadequate it's not worth doing
you'd want to use the capture-count-on-index in the fpga
sure, that's a better idea
might be available only to Mesa though
huh. why isn't that file in the nc_files dir?
it's somewhere in AXIS lib
ries_ is now known as ries