I'm working on new new probing
(with a latch-enable for each joint)
hmph, I now intermittently get 'Queue is not empty after probing'
EMC: 03cradek 07master * r80bcdbd8df6f 10/ (configs/sim/axis.ini src/emc/rs274ngc/interp_convert.cc): fix tool change never completing if using quill-up or at-g30
EMC: 03cradek 07v2_3_branch * r866bbe808e92 10/ (configs/sim/axis.ini src/emc/rs274ngc/interp_convert.cc): fix tool change never completing if using quill-up or at-g30
EMC: 03jthornton 07v2_3_branch * r026ed41aa264 10/docs/src/gcode/images/ (g2.dxf g2.png): Add to image
EMC: 03jthornton 07master * r5c57253a44a5 10/docs/src/gcode/images/ (g2.dxf g2.png): Add to image
also, a Probe is already tripped when starting G38.2 or G38.3 move
I'll revert this stuff on master soon if I can't get it fixed up..
for consideration: a patch to tooledit.tcl http://www.panix.com/~dgarrett/stuff/0001-notify-user-when-tooltable-file-is-altered-elsewhere.patch
EMC: 03jepler 07master * ra7d6b4b1e5f2 10/src/emc/usr_intf/tooledit.tcl: notify user when tooltable file is altered elsewhere
does the probing problem have any effect on a parallel port probe input?
jt-plasma: any 2.3-compatible probing setup will not work on master
if I work out the kinks in what I'm doing, I'll give some instructions on how to update configs
if I don't, then I'll take it out
either way, I wouldn't use master for probing or try to document what it currently does
I'll have to back up mine a bit then
I was setting up the new computer with the 5i20 and THC on the plasma :)
and that relies on probing?
on the z axis only
it floats and I find the top of the surface with a probe move
then carry on at the correct height for the cutting tip
[19:28:18] <jepler> http://mid.gmane.org/20091107143154.GA6322@unpythonic.net
did someone fix threading with spindle in reverse?
or is it not in 2.3
doesn't ring a bell for me
just other day went to do thread with spindle backwards and it would not do it, using 2.3.4
jepler, works like a champ thanks
dgarr: is tooledit working again? I've screwed up the tool table format so many times I've lost track...
i never knew it was not working -- works for me?
I'd been using the random_toolchange branch for a while, where it was certainly broken
but now, at least I hope, the tool tables are compatible with the old ways
i've been using it with sim/random_tc.ini
i will post a link to a work-in-progress patch for named parameters for tools later, now it writes tooltable
oops i meant numbered not named
i did make the numbered paramter for toolno readonly -- seems like too many consequenes to allow writing it (for me at least)
you're doing the loaded-tool introspection but you decided to use names instead of numbers for the variables?
for comment -- numbered parameters for current tool http://www.panix.com/~dgarrett/stuff/0001-Numbered-parameters-for-current-tool-items.patch
dgarr: why use _n_readonly_parameters ?
dont understand your question?
dgarr: having readonly parameters is a nice idea
but probably all parameters could be set as readonly
(for certain cases .. disabling program access to them)
and this shouldn't be compile-time fixed
alex_joni: ini file option? it would be nice
alex_joni: i think there are multiple opinions on readonly 2009-11-04 19:05:14 http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-11-04.txt
dgarr: I don't see the reference to readonly there
i had thought read-only for all tool parameters but cradek makes good points against that especially considering current behavior
you probably have to read the whole discussion
dgarr: I did read it the other day
still, I don't see how it's related to our conversation ;)
you say "but probably all parameters could be set as readonly", what i got from that conversation was that currently: parameters are not readonly nor (in general) should they be
oh sure.. but if I want to set some as readonly I should be able to
and some would be chosen out of all possible ones
that's what I meant with all could be set as readonly.. (there might be cases when somebody might want to set some parameters readonly)
probably not all at once
i guess all i'm proposing in the patch is: add a compile-time-option of readonly, and apply it to one specific item. that doesn't preclude other patches that would implement a user/gcode-program/inifile way of making some parameters readonly
right, it doesn't
one thing at a time:P
dgarr: looks ok
off to bed for me
good night, thanks for looking at it
dgarr: I think I like it. If we have more introspection one of these days (and why not now that you have the scheme?), your read-only parameters will be very useful
Is jmkasunich AWOL?
I think having them in _required_parameters causes them to be written to the var file and preserved. [untested -- if so,] I think that's not what you want
Jymmm: he's around occasionally
dgarr: I think configurable read-only is unnecessary complexity with no purpose. it makes sense to have some vars writable and others not.