#emc-devel | Logs for 2009-11-08

[01:18:39] <jepler> cradek: good!
[01:18:47] <jepler> I'm working on new new probing
[01:21:26] <jepler> (with a latch-enable for each joint)
[01:54:39] <jepler> hmph, I now intermittently get 'Queue is not empty after probing'
[03:23:11] <cradek> hmm
[04:00:30] <CIA-3> 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
[04:09:44] <CIA-3> 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
[13:06:24] <CIA-3> EMC: 03jthornton 07v2_3_branch * r026ed41aa264 10/docs/src/gcode/images/ (g2.dxf g2.png): Add to image
[13:43:01] <CIA-3> EMC: 03jthornton 07master * r5c57253a44a5 10/docs/src/gcode/images/ (g2.dxf g2.png): Add to image
[17:44:34] <jepler> also, a Probe is already tripped when starting G38.2 or G38.3 move
[17:45:03] <jepler> I'll revert this stuff on master soon if I can't get it fixed up..
[18:16:27] <dgarr> for consideration: a patch to tooledit.tcl http://www.panix.com/~dgarrett/stuff/0001-notify-user-when-tooltable-file-is-altered-elsewhere.patch
[18:58:29] <CIA-3> EMC: 03jepler 07master * ra7d6b4b1e5f2 10/src/emc/usr_intf/tooledit.tcl: notify user when tooltable file is altered elsewhere
[19:23:06] <jt-plasma> does the probing problem have any effect on a parallel port probe input?
[19:24:31] <jepler> jt-plasma: any 2.3-compatible probing setup will not work on master
[19:24:45] <jepler> if I work out the kinks in what I'm doing, I'll give some instructions on how to update configs
[19:24:51] <jepler> if I don't, then I'll take it out
[19:24:56] <jt-plasma> jepler: thanks
[19:25:06] <jepler> either way, I wouldn't use master for probing or try to document what it currently does
[19:25:22] <jt-plasma> I'll have to back up mine a bit then
[19:25:44] <jt-plasma> I was setting up the new computer with the 5i20 and THC on the plasma :)
[19:26:01] <jepler> and that relies on probing?
[19:26:13] <jt-plasma> on the z axis only
[19:26:27] <jt-plasma> it floats and I find the top of the surface with a probe move
[19:26:49] <jt-plasma> then carry on at the correct height for the cutting tip
[19:28:18] <jepler> http://mid.gmane.org/20091107143154.GA6322@unpythonic.net
[19:28:55] <jt-plasma> thanks
[19:32:02] <robh> did someone fix threading with spindle in reverse?
[19:32:08] <robh> or is it not in 2.3
[19:37:34] <jepler> doesn't ring a bell for me
[19:43:54] <robh> just other day went to do thread with spindle backwards and it would not do it, using 2.3.4
[19:44:06] <jt-plasma> jepler, works like a champ thanks
[20:00:28] <cradek> dgarr: is tooledit working again? I've screwed up the tool table format so many times I've lost track...
[20:05:58] <dgarr> i never knew it was not working -- works for me?
[20:06:13] <cradek> oh, good!
[20:06:36] <cradek> I'd been using the random_toolchange branch for a while, where it was certainly broken
[20:06:52] <cradek> but now, at least I hope, the tool tables are compatible with the old ways
[20:07:00] <dgarr> i've been using it with sim/random_tc.ini
[20:07:22] <cradek> cool.
[20:08:52] <dgarr> i will post a link to a work-in-progress patch for named parameters for tools later, now it writes tooltable
[20:09:10] <dgarr> oops i meant numbered not named
[20:09:43] <dgarr> i did make the numbered paramter for toolno readonly -- seems like too many consequenes to allow writing it (for me at least)
[20:11:24] <cradek> you're doing the loaded-tool introspection but you decided to use names instead of numbers for the variables?
[20:11:41] <dgarr> no-- numbers
[20:12:08] <cradek> ah ok
[20:45:52] <dgarr> for comment -- numbered parameters for current tool http://www.panix.com/~dgarrett/stuff/0001-Numbered-parameters-for-current-tool-items.patch
[21:13:30] <alex_joni> dgarr: why use _n_readonly_parameters ?
[21:15:33] <dgarr> dont understand your question?
[21:49:55] <alex_joni> dgarr: having readonly parameters is a nice idea
[21:50:22] <alex_joni> but probably all parameters could be set as readonly
[21:50:45] <alex_joni> (for certain cases .. disabling program access to them)
[22:00:41] <alex_joni> and this shouldn't be compile-time fixed
[22:07:06] <micges> alex_joni: ini file option? it would be nice
[22:11:48] <dgarr> 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
[22:31:44] <alex_joni> dgarr: I don't see the reference to readonly there
[22:33:01] <dgarr> 2009-11-04 19:00:05
[22:34:07] <dgarr> i had thought read-only for all tool parameters but cradek makes good points against that especially considering current behavior
[22:34:30] <dgarr> you probably have to read the whole discussion
[22:34:59] <alex_joni> dgarr: I did read it the other day
[22:35:36] <alex_joni> still, I don't see how it's related to our conversation ;)
[22:38:00] <dgarr> 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
[22:38:32] <alex_joni> oh sure.. but if I want to set some as readonly I should be able to
[22:38:45] <alex_joni> and some would be chosen out of all possible ones
[22:39:24] <alex_joni> 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)
[22:39:35] <alex_joni> probably not all at once
[22:44:57] <dgarr> 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
[22:47:39] <alex_joni> right, it doesn't
[22:48:28] <dgarr> one thing at a time:P
[22:54:19] <alex_joni> dgarr: looks ok
[22:54:25] <alex_joni> off to bed for me
[22:54:42] <dgarr> good night, thanks for looking at it
[23:57:52] <cradek> 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
[23:58:33] <Jymmm> Is jmkasunich AWOL?
[23:58:41] <cradek> 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
[23:58:48] <cradek> Jymmm: he's around occasionally
[23:58:52] <Jymmm> k
[23:59:52] <cradek> dgarr: I think configurable read-only is unnecessary complexity with no purpose. it makes sense to have some vars writable and others not.