Back
[00:00:44] <aystarik> ok.
[00:01:57] <alex_joni> aystarik: glad to see another translation..
[00:02:00] <alex_joni> good night all
[00:02:21] <aystarik> good night!
[00:05:43] <jt-plasma> goodnight
[00:58:22] <skunkworks> heh
http://groups.yahoo.com/group/mach1mach2cnc/message/114427
[00:59:54] <skunkworks> from what I can tell it is close to what the 'real time delay' does with emc.
[03:43:31] <cradek> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120485992619
[03:43:53] <cradek> what the hell? why is tooling so cheap? 8 bids under $6? these chucks are like $200 new
[03:44:48] <mozmck> did you get it?
[03:45:08] <cradek> yes - I put in a throwaway bid of $8 or something like that
[03:45:37] <mozmck> great! shipping brings it up a bit it looks like, but not bad.
[03:45:41] <cradek> good grief, it keeps happening - end mill holders for 99c + shipping
[03:46:09] <cradek> pretty soon I'm going to have more than I'll ever need - which is exactly the right amount of tooling
[03:46:45] <mozmck> economy. businesses going under and there's more stuff on the market and less people needing it.
[03:47:03] <cradek> guess so - it's buying time...
[03:47:12] <mozmck> seems like.
[03:47:43] <cradek> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=170399784493
[03:47:48] <mozmck> It ran 'git checkout v2_3_branch' and it said the following:
[03:47:51] <mozmck> Switched to branch 'v2_3_branch'
[03:47:51] <mozmck> Your branch is behind 'origin/v2_3_branch' by 113 commits, and can be fast-forwarded.
[03:47:56] <cradek> another one I bought - I was wrong - 99c for two holders, not one
[03:48:02] <mozmck> what does that mean?
[03:48:24] <cradek> it means there are 113 changes since you were last on that branch - just do a git pull to update ("fast forward") your copy
[03:49:21] <mozmck> ok. I thought it was updating it when I did a pull from master. It always says something about it...
[03:49:22] <cradek> "fast forward" means you have no local commits that need to be merged with others', so the update is trivial - just get the new stuff.
[03:49:45] <cradek> well it does pull it down, but doesn't fast forward your branch unless you ask for it.
[03:50:34] <mozmck> weird.
[03:50:53] <mozmck> when I do a checkout it does switch the code in my working dir doesn't it?
[03:51:29] <cradek> yes, to your own v2_3_branch tag, which was an earlier state of origin/v2_3_branch
[03:51:52] <cradek> to update your v2_3_branch tag, you can do a merge (or pull, which is fetch+merge)
[03:52:29] <mozmck> ok. I did that now.
[03:53:05] <mozmck> to build debs can I just run ./configure and dpkg-buildpackage in the debian directory?
[03:53:42] <cradek> yes, except I believe the invocation is ./configure -r
[03:54:16] <cradek> trying a 2.4 package build? I bet at least touchy is not yet in it
[03:54:45] <jepler> run one of "debian/configure sim" or "debian/configure -a" to prepare to build packages. Run from the top dir, not inside debian/.
[03:54:46] <mozmck> it told me my kernel '2.6.31.4-rtai' is not known. but it said it was successful.
[03:55:00] <jepler> lots of the dependencies in debian/control.in are wrong (they name versions older than 9.10)
[03:55:12] <jepler> python, tcl, tk at least
[03:55:15] <mozmck> no, right now I'm trying to build 2.3 packages.
[03:55:44] <jepler> .. but there's not machinery for choosing different versions of those packages as build dependencies because of the detected ubuntu version ..
[03:56:09] <mozmck> I see. I'll see what I have to do to get it to work.
[03:57:17] <mozmck> I wonder if there's a way to build the control.in in the configure somehow?
[03:58:04] <jepler> I think the solution is to make more things in control.in determined by debian/configure based on the distro version
[03:58:15] <jepler> debian/configure builds debian/control from debian/control.in
[03:58:35] <jepler> some things are configurable, like whatever @KERNEL_DEPENDS@ gets replaced with
[03:59:17] <mozmck> I see. I'll play with it some and see where I get.
[04:00:28] <jepler> I see that the version of the python package isn't given explicitly -- that's good
[04:00:59] <jepler> maybe tcl/tk is the only problem
[04:01:31] <jepler> if so I'd consider making the thing substituted be the @TCL_VERSION@ and its value would be 8.4 or 8.5
[04:01:46] <jepler> 'night
[04:02:03] <mozmck> ok, thanks. good night
[04:12:11] <mozmck> how do I pull my changes in hostmot2 from master to 2.3.x?
[04:13:20] <cradek> find the commit ID, and while on the 2.3 branch, do a git cherry-pick that-id
[04:13:41] <cradek> looks like it is f88ea06895
[04:13:43] <mozmck> ok, thanks
[04:17:21] <mozmck> looks like that worked. how do I find the commit IDs? I looked at qgit but didn't see them
[04:17:50] <cradek> gitk shows them in the middle of the window - git log shows them at the top of every log block - I have not used qgit
[04:18:18] <cradek> personally I typed git log --author=moses and the change you wanted was the first line I saw
[04:18:38] <cradek> (I'm on master)
[04:18:52] <cradek> you'd have to type 'git log --author=moses master'
[04:19:00] <cradek> ... assuming you're on the branch
[04:19:47] <mozmck> thanks. I think I used gitk before but typed qgit now. I forget what I learn if I don't use it for a while :(
[04:21:45] <cradek> sometimes I wonder if I've forgotten more than I currently know - I think not, but how would I know for sure?
[04:22:59] <mozmck> heh, I don't know...
[04:29:15] <Dave911> take notes ??? ;-)
[04:29:30] <cradek> I've tried that
[04:29:41] <cradek> "hmm, I see this is my handwriting - wonder what it meant"
[04:29:43] <mozmck> you lose 'em
[04:30:40] <Dave911> cradek: The guy who sold that chuck has been dumping stuff on Ebay ... you might want to watch him... I've been buying inserts for my lathe very cheaply. $1 each or less.... Some are $22 in the MSC book
[04:31:20] <cradek> Dave911: I am currently the only one on the planet buying BT40 tooling. it's OK by me...
[04:31:28] <mozmck> the commit IDs git log gives me are much longer than the one you gave.
[04:31:29] <Dave911> >> wonder what it meant"
[04:31:32] <Dave911> better notes.. ;-)
[04:31:47] <Dave911> $6 for that chuck ??? The key costs that much!
[04:31:54] <cradek> mozmck: you can use an abbreviated ID if it's unique
[04:32:10] <mozmck> I see.
[04:32:19] <Dave911> Oh well.. happy buying :-)
[04:32:22] <cradek> Dave911: yes, they're $200+, holder is $75+, pull stud (surely wrong) is $20+
[04:32:50] <Dave911> $6 is plain crazy
[04:33:25] <cradek> I've got about 5 of them now, all for < $15 each
[04:34:00] <cradek> so nice to have enough drill chucks ... luxury
[04:34:13] <Dave911> I should really buy a mill. Perhaps next spring. I've seen more than a few go by.
[04:34:16] <mozmck> that is nice.
[04:35:00] <cradek> on the bridgeport if I needed several drills, I'd change it out and then move the knee to adjust for the new length - huge pain
[04:35:47] <Dave911> Yep, but you will fill all of the chucks with tools - then say if I only had just 1 more chuck ..
[04:36:25] <cradek> I have an albrecht I like to keep empty for one-off holes
[04:36:40] <cradek> they're very nice, but (even now) go for real money
[04:37:31] <Dave911> I don't think it is possible to have too many tools - albrechts - I have one in a lathe I own... I thought they were pricey
[04:38:00] <cradek> yes but so nice to just hand tighten and I've NEVER had one slip
[04:38:27] <cradek> I've drilled 3/4 holes in steel, just hand tightened
[04:38:51] <cradek> they are a great design
[04:39:13] <Dave911> The one I have is a little mangled as some idiot put some channelocks on it.... that is really quite amazing..
[04:39:20] <cradek> ugh
[04:39:57] <Dave911> yep
[04:41:00] <Dave911> I thought my lathe encoder was bad.... turns out my LPT board has "one" flaky input!
[04:41:41] <cradek> bizarre!
[04:43:17] <Dave911> Yep, I didn't think it was at all likely, but I tested it in my office with an encoder simulator and it is clearly bad. I think I will be able to try the lathe threading tomorrow, but it sounds like it is fixed from what I have heard.
[04:43:44] <cradek> yes I'm getting good feedback about the latest change I put on master
[04:44:48] <mozmck> so 2.3.x doesn't have autogen.sh it looks like.
[04:44:54] <Dave911> I'll let you know how it goes.. it will probably be fine ....
[04:44:55] <Dave911> Well... I have to get some rest .... good night
[04:45:00] <cradek> mozmck: nope
[04:45:03] <cradek> Dave911: thanks
[04:45:25] <Dave911> thank you!
[04:47:00] <mozmck> how do I revert a cherry-pick?
[04:49:04] <cradek> do you mean discard it?
[04:49:21] <cradek> [revert means to make a new, but opposite commit]
[04:49:41] <mozmck> yes, I cherry-picked some old changes and I think they may not be good for 2.3
[04:50:19] <cradek> do you want to discard all your changes you've made since pull, or just some?
[04:51:20] <mozmck> just some, but I can just reset and redo the others. I had made changes on master in the makefile to put some stuff in different places, but I'm thinking we didn't want to do that in 2.3 for some reason.
[04:51:49] <cradek> yeah changes in 2.3 should be the absolute minimum possible to fix bugs
[04:52:20] <mozmck> what about the one I made yesterday?
[04:52:24] <cradek> you can discard some, using 'git rebase --interactive' (a little bit of a complex process) or discard all with something like 'git reset --hard origin/v2_3_branch'
[04:53:01] <cradek> you should probably ask jepler about that one
[04:53:51] <mozmck> ok. it should be good for existing stuff and fix bugs for newer kernels. I had to do it to make it compile
[04:54:25] <cradek> yeah, sounds good to me then - if it didn't build before and does now, how can that be a bad change
[04:55:04] <cradek> (assuming you were able to find the exact version cutoff)
[04:55:56] <mozmck> well, I know it worked on 2.6.29.4, and I know that the dev_set_name is in that version and higher (maybe a few back as well), so I made the cutoff at 2.6.30
[04:56:43] <cradek> ack, I should go to bed too
[04:56:51] <cradek> goodnight
[04:56:54] <mozmck> me too. goodnight
[06:14:35] <Dave911> cradek: >>turns out my LPT board has "one" flaky input! --I was wrong, my test setup had a bad ribbon cable! pin 13 is an outside strand - PP board checks out fine, I'm back to a bad encoder Geez
[12:47:23] <jepler> mozmck: for now at least, don't push any changes to 2.3 yourself. But if you want a change on 2.3, reporting that it works for you when cherry-picked to your local 2.3 branch is valuable.
[14:09:57] <skunkworks> logger_dev: bookmark
[14:09:57] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-11-04.txt
[14:49:17] <micges_work> jepler: I have suggestion: in Makefile instead of listing all dirs in usr_intf/ could be script that include all dirs in usr_intf/
[14:50:33] <micges_work> so if one want to add new interface to emc could only include link to external dir in usr_intf/
[14:50:51] <micges_work> without all makefile messing
[14:58:34] <micges_work> logger_dev: bookmakr
[14:58:34] <micges_work> I'm logging. I don't understand 'bookmakr', micges_work. Try /msg logger_dev help
[14:58:44] <micges_work> logger_dev: bookmark
[14:58:44] <micges_work> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-11-04.txt
[15:11:59] <micges_work> here is proposed patch for above problem:
http://www.pastebin.ca/1656761
[15:13:07] <mozmck_work> jepler: ok.
[15:17:13] <cradek> micges_work: does that even work?
[15:17:57] <micges_work> yes
[15:18:17] <micges_work> for sure I'll test it again, jas
[15:18:35] <cradek> I'm surprised
[15:19:06] <cradek> include $(wildcard $(SUBMAKEFILES))
[15:19:09] <cradek> aha, this is why
[15:20:04] <micges_work> I'm not familiar with make scripts (yet)
[15:21:15] <cradek> I think the explicit list is better. I don't really understand why it is a problem. Someone adding a gui already has to add make rules to build it, so this is not a particular obstacle
[15:23:11] <micges_work> I'm not saying this is problem
[15:57:26] <jepler> -include $(wildcard $(SUBMAKEFILES))
[15:57:32] <jepler> huh, I wonder why I made this not fail for missing submakefiles
[15:57:52] <jepler> because I sure never intended for wildcards to be used in SUBDIRS
[16:01:48] <dgarr> a patch to allow clearing axis info or errors notifications:
http://www.panix.com/~dgarrett/stuff/0001-add-support-for-clear-by-iconname.patch
[16:01:58] <dgarr> posted earlier but not sure it was noticed?
[16:02:45] <jepler> I saw it go by but didn't take the time to look at it
[16:49:41] <CIA-3> EMC: 03jepler 07defer-format * r419bef46fcd5 10/src/hal/drivers/mesa-hostmot2/ (hm2_7i43.c hm2_pci.c hm2_test.c): prefer rtapi_snprintf to snprintf
[16:49:42] <CIA-3> EMC: 03jepler 07defer-format * rc6d47337dfa1 10/src/emc/motion/motion.c: this declaration was unneded
[16:49:45] <CIA-3> EMC: 03jepler 07defer-format * r02888daee8c9 10/src/rtapi/vsnprintf.h: a convenience function for adding a single character
[16:49:46] <CIA-3> EMC: 03jepler 07defer-format * rf63621f26cef 10/src/rtapi/vsnprintf.h: "formatting" a double as hex is better than nothing
[16:49:47] <CIA-3> EMC: 03jepler 07defer-format * r7d1ce2b675a6 10/src/rtapi/ (rtai_rtapi.c rtapi.h vsnprintf.h): use our vsnprintf for %f support
[16:49:49] <CIA-3> EMC: 03jepler 07defer-format * r293a8126cdf9 10/src/emc/motion/stashf.c: in realtime use our snprintf for %f support
[16:49:52] <CIA-3> EMC: 03jepler 07master * r0798a048e3c8 10/src/emc/usr_intf/axis/extensions/emcmodule.cc: fix rendering error of selected lines
[16:49:55] <CIA-3> EMC: 03jepler 07master * ra463346aa76b 10/lib/python/rs274/interpret.py: fix appearance of arcs when abcuvw offsets are in effect
[16:50:00] <CIA-3> EMC: 03jepler 07master * r3f5bfd6f29ea 10/lib/python/rs274/interpret.py: these comments were misleading
[16:54:24] <jepler> hm, on the other hand I'm surprised push pushed those defer-format changes; on the other hand, I am surprised to find I had anything in that branch that I hadn't pushed
[16:55:09] <jepler> cradek: ah, I *do* have push.default = tracking, but the /usr/bin/git on india is so old that it doesn't support that option
[16:55:38] <jepler> but I thought I had my path set to use my own git
[16:58:42] <jepler> hi LawrenceG
[16:58:50] <CIA-3> EMC: 03jepler 07master * r74d6628d9679 10/src/emc/usr_intf/axis/scripts/axis.py: add support for clear by iconname
[16:59:20] <LawrenceG> hi Jeff
[16:59:49] <LawrenceG> any excitement in the east?
[17:02:51] <cradek> jepler: but: ii git-core 1.6.1.2-1~ppa~dapper fast, scalable, distributed revision control system
[17:03:02] <cradek> are you sure? that's the same one I put everywhere.
[17:04:56] <jepler> LawrenceG: hm, I'm not accustomed to thinking of myself as being in the east..
[17:05:58] <jepler> cradek: india:/usr/share/man/man1/git-config.1.gz doesn't mention push.default.
[17:06:15] <jepler> lucky2's does
[17:06:46] <jepler> cradek: hm, 2/3 of those changes don't apply cleanly on v2_3_branch
[17:06:47] <cradek> I'm very surprised that appeared between 1.6.1.2 and 1.6.3.3
[17:06:59] <cradek> jepler: coordinate system rotation, surely
[17:08:15] <jepler> cradek: it looks like uvw offsets were also broken and you accidentally fixed them when adding rotation
[17:08:25] <cradek> yay me!
[17:08:53] <cradek> clearly I need a 9-axis mill for testing
[17:09:40] <jepler> I think I'm not going to touch this on the branch .. if someone else wants to tackle it, test it, and give me the results I'll consider it for inclusion though
[17:13:36] <alex_joni> hahaha:
http://pastebin.ca/1656914
[17:15:13] <jepler> "Planification" sounds like the perfect 'this will make me look smart' word. It goes nicely alongside "implement" and "utilize".
[17:15:49] <jepler> planning = creating a plan (from scratch). planification = turning something that isn't a plan into one
[17:16:53] <cradek> I encountered "6. Resources have been identified to participate in the pilot:" today
[17:17:14] <cradek> only from the context could I guess what it meant
[17:17:25] <alex_joni> cradek: nice one
[17:17:41] <cradek> it means a list of people who will attend a meeting
[17:18:39] <cradek> in the same email: "to finalize the agenda and confirm the logistics of the service package."
[17:18:55] <cradek> that means decide what time the meeting starts
[17:33:17] <skunkworks> maybe Yishin should be pointed to the joints/axis branch - He could help :)
[18:29:42] <cradek> jepler: uh-oh, stuart says touch off is borken
[18:30:44] <jepler> cradek: uh oh -- where
[18:30:44] <jepler> ?
[18:30:53] <cradek> emc-users
[18:32:22] <jepler> g91 g28 x0y0z0 ?
[18:33:57] <cradek> =~ g0 g53 x0y0z0
[18:34:04] <cradek> wfm, btw
[18:34:34] <jepler> did you use the g91 g28 formulation or the g53 formulation?
[18:34:44] <jepler> g91 = relative mode?
[18:34:50] <jepler> I wonder if touch off accounts for g91 in effect (or needs to)
[18:35:46] <cradek> I used the g91 one
[18:36:12] <cradek> G10 doesn't care whether you are in G90 or G91 (and that is by design and documented)
[18:36:31] <jepler> ok
[18:36:40] <cradek> yes in this case it means a move to the current point (relative to 0,0,0)
[18:36:58] <cradek> this odd formula is because of the odd way g28 works when given axis words
[18:40:42] <jepler> I think you can get behavior like this if your config directory is not writable
[18:41:12] <cradek> yes - I asked him to check that in my response
[18:41:23] <jepler> though I see that Interp::save_parameters tries to check for errors
[18:41:28] <jepler> CHKS((rename(filename, line) != 0), NCE_CANNOT_CREATE_BACKUP_FILE);
[18:41:28] <cradek> oh the directory too? hmm
[18:42:08] <jepler> rename("sim.var", "sim.var.bak") = -1 EACCES (Permission denied)
[18:42:15] <jepler> I get ghese in strace but no error reported..
[18:42:18] <jepler> these
[18:42:44] <cradek> somewhere along the line of calls something isn't using CHKF then
[18:43:15] <cradek> er CHP
[18:43:53] <jepler> yes
[18:45:20] <jepler> hm, now it behaves even more oddly
[18:45:22] <jepler> :-/
[18:45:36] <cradek> ha
[18:45:42] <jepler> Issuing EMC_TASK_PLAN_SYNCH -- (+516,+12, +0,)
[18:45:42] <jepler> emc/task/emctaskmain.cc 2076: error executing command 516:EMC_TASK_PLAN_SYNCH
[18:45:42] <jepler> emcTaskIssueCommand() returning: -1
[18:45:45] <jepler> it does this over and over again
[18:45:53] <jepler> but without displaying an operator message
[18:46:01] <cradek> ouch
[18:46:21] <cradek> I bet it should only give that error once
[18:46:28] <cradek> I think it synchs all the effing time
[18:59:29] <dgarr> jepler: thanks for applying that patch:)
[19:00:05] <dgarr> i propose to offer a patch to populate #parameters with the current tool id,diameter, etc but am not sure i know all relevant issues
[19:00:08] <dgarr> http://www.panix.com/~dgarrett/stuff/tool_parms.txt
[19:01:20] <jepler> cradek: if I make it just error once, it errors too early to appear in the GUI
[19:02:18] <jepler> or maybe I'm doing it wrong
[19:03:16] <cradek> dgarr: would you modify the tool table if the user writes #5071=1?
[19:03:50] <dgarr> no -- i see it for just immediate use (eg within a gcode subroutine) read-only
[19:05:14] <cradek> that feels kind of incomplete to me
[19:06:40] <cradek> people often ask about accessing all sorts of internal state through # variables. especially current coordinates.
[19:07:36] <dgarr> are there philosophical or practical objections to that?
[19:08:56] <cradek> philosophical: no; practical: you have to pick # numbers, and I think there is no existing "reserved" space so you might step on existing programs
[19:09:22] <cradek> also, some things aren't really numbers (is tool compensation currently off, left, or right?)
[19:09:32] <cradek> it just all smells kind of bad
[19:16:42] <cradek> dgarr: seems like pretty much everything in the setup struct could be made available - not sure how to do that and keep it maintainable (since we add stuff to setup willy-nilly)
[19:17:14] <dgarr> do you see problems with tool parameters specifically?
[19:18:50] <cradek> no, and I see a very useful way to use it: a roughing pass with G41.1 D[#5072 + 0.010]
[19:19:36] <dgarr> i think modifying the tool table if a user wrote #5071 would not be appropriate since it would be trying to maintain the same data in multiple places -- thats why read-only makes sense to me. if a user wrote #5071 etc. he would be on his own.
[19:19:50] <cradek> but to feel complete I think it should write the tool table for the current tool if you modify those. I think anything else will feel like a surprise to users. compare with how you can set offsets with #...=...
[19:20:01] <cradek> heh
[19:20:38] <cradek> the tool table is already written by the intepreter in many situations including G10 and tool change on a random-toolchange machine
[19:22:09] <cradek> your patch is against an old version: be sure you're working on git-master
[19:23:53] <cradek> (I stirred it all up merging random-toolchange)
[19:24:51] <cradek> now, the tool in the spindle is settings->tool_table[0]
[19:24:57] <dgarr> i guess i don't understand something: are there #parameters that have side effects from the (only) action of a user writing them from gcode?
[19:25:20] <cradek> yes, all the coordinate systems work that way
[19:25:41] <cradek> also g28/g30 saved points
[19:26:22] <cradek> try #5221=9, then G54
[19:26:31] <cradek> you will see the X origin move
[19:26:44] <cradek> then, also that is saved in the var file
[19:28:51] <cradek> looks like the top parameter is currently #5400. you could be sure to not break any programs by raising it and putting new stuff above there
[19:29:30] <dgarr> i'll have to study that, thanks for the example.
[19:29:32] <cradek> if doing this I recommend you leave space for eventual tool offsets in all 9 axes
[19:32:50] <dgarr> does that mean make RS274NGC_MAX_PARAMETERS 5400 + 9 * 7 (7== no. of items in tool table)?
[19:33:15] <dgarr> and reserve the numbers somehow?
[19:34:03] <cradek> I guess I mean you'd want id, x,y,z,a,b,c,u,v,w offsets, diameter, front/back angle, orientation
[19:34:20] <cradek> so 14? vars would be used
[19:34:37] <cradek> today the unused tool offsets would read as zero
[19:35:47] <cradek> in the very old days someone had the foresight to leave holes in the coordinate system offset #vars so when we added a,b,c,u,v,w axes it did not mess up existing programs which read/wrote the x,y,z offsets
[19:49:17] <dgarr> is it a good idea to increase RS274NGC_MAX_PARAMETERS? the 5400 number is cited in rs2274 documentation. Is there a downside to using 5071-5084? it seems to me that it would be better to use use gaps when no conflict exists?
[19:52:30] <cradek> I definitely think you should put the new variables where it was previously forbidden (above 5400) since existing program may use 5071-5084 for other things
[19:56:13] <dgarr> by programs do you mean existing gcode programs or other programs? i'm confused what would break? (sorry to be dense)
[19:56:34] <cradek> existing gcode programs
[19:56:40] <cradek> it's unlikely, but possible
[19:56:54] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JMKsFusee
[19:57:32] <cradek> here's an example of a program that uses a bunch of parameter space - I think it doesn't happen to hit the area you are going to modify, but possibly could have
[19:57:52] <cradek> by raising the max and putting new stuff above it, you make it impossible to break any existing gcode
[19:59:04] <cradek> if we subsequently add full introspection (approximately everything in the setup struct) we will definitely want to use that scheme
[19:59:08] <dgarr> i understand -- no problem. i thought i had read that there was a range of #numbers for user (gcode) and a range for system (sourcecode) but i can't find it
[19:59:37] <cradek> I vaguely remember something like that too - let me know if you find it... :-/
[19:59:56] <dgarr> i guess each extension of #numbers would extend RS274NGC_MAX_PARAMETERS by the right amount -- this makes sense.
[20:00:07] <cradek> right
[20:00:43] <dgarr> i would think most new gcode would use the #<namedparameters> -- it makes code much easier to read and learn from
[20:00:47] <cradek> we may want to call that 'the introspection area', and treat it specially (for instance, don't write it in the varfile, maybe even error if someone manually puts it in the varfile because that makes no sense)
[20:01:18] <cradek> it's an interesting idea that maybe 'the introspection area' could be in named-parameter-space
[20:02:04] <cradek> not sure how to do that cleanly - partly for the same reason of clashing with existing gcode
[20:05:13] <dgarr> ok, i will work on a more comprehensive patch for tool parameters -- thanks for your input
[20:05:19] <dgarr> i'm still hoping _someone_ will try my gui for subroutines:P
http://www.panix.com/~dgarrett/ngcgui/ngcgui.txt
[20:06:17] <cradek> you're welcome for my input - but I'm a little worried that I'm the only one who said anything - don't mistake me for someone whose ideas are always good... :-)
[20:50:10] <robh_> has any one done any work on rear tool post lathe? or should i say slantbed type
[20:55:58] <cradek> I mounted a tool in the back once
[20:56:01] <cradek> or twice even
[21:03:08] <robh_> i ment as in the display as for slantbed its wrong way on graphics on axis
[21:03:35] <cradek> ah, wondered what your real question was :-)
[21:03:39] <robh_> tool offsets just wrap around spindle to other side in effect so no difference there,
[21:03:44] <cradek> yep
[21:03:57] <cradek> only problem is jogging arrows and display are upside-down
[21:05:00] <robh_> yea so i didt know wether to do a ini setting write a patch
[21:05:14] <cradek> I don't think it's an ini setting, but it should be
[21:05:24] <robh_> im sure other are looking for the function also
[21:05:25] <cradek> maybe LATHE=2 instead of =1
[21:05:33] <cradek> yep I'm sure you're right
[21:05:38] <cradek> I've seen it on the list once in a while
[21:05:40] <robh_> i througt lathe=2 should mean a two turret lather later on?
[21:05:54] <cradek> heh, no idea
[21:06:08] <cradek> it could also be a preference on the display menu
[21:06:21] <robh_> for sliding head also,as have two turrets
[21:08:18] <robh_> im just fitting this machine out,
http://cnczone.com/forums/showthread.php?t=92057
[21:09:13] <robh_> so ill be looking at ways to add tool offsets for bottom turret also later on
[21:09:55] <cradek> is the bottom turret something like ER for drilling/tapping?
[21:10:02] <cradek> looks like it's for end stuff only
[21:10:12] <robh_> drill tapping bar stoping only as its only a 2nd Z in effect
[21:10:40] <cradek> oh I see, it's always aligned with the center, neat
[21:10:45] <robh_> they did make them with a top turret on bottom so two Z X axes
[21:11:09] <cradek> that will surely be W, but you can't have both W and Z offsets, grr
[21:11:18] <robh_> and also with power tooling and C axes , and also a rear tail stock also, so not bad for a 1980s machine
[21:11:53] <robh_> yea i through two extra turrets on a althe should be U W no hence why lathe=2 ini setting later on
[21:57:56] <jepler> once upon a time I had this snippet of code in my ~/.axisrc file to turn the view "upside down"; I don't recall whether there was a problem or limitation of the code, or whether I just never took the time to make it an easily-enabled optional setting:
http://pastebin.ca/1657438
[22:17:10] <robh_> jepler thx ill try and have a play with it see how it works out,
[22:31:32] <alex_jon1> alex_jon1 is now known as alex_joni