Back
[00:27:07] <dgarr> today i encounter this restriction (interp_convert.cc): (_("Cannot call user-defined M code with cutter radius compensation on"))); // XXX
[00:27:33] <dgarr> and wonder if it is necessary?
[01:11:06] <alex_joni> dgarr: haven't seen that one
[01:17:45] <dgarr> do you think it is necessary? what does the XXX comment mean?
[01:18:09] <alex_joni> no idea what XXX stands for
[01:18:17] <alex_joni> * alex_joni misses lxr
[01:20:49] <dgarr> i see this in gcodemodule.cc: XXX: This needs to be re-thought.
[01:21:23] <dgarr> so maybe the restriction on user-defined M codes and radius compensation could be reconsidered?
[01:21:43] <alex_joni> I think it's on purpose
[01:21:48] <alex_joni> it wasn't there a year ago
[01:22:41] <dgarr> sha1 --> e0c96fbe
[01:23:16] <dgarr> merge concave_comp2 branch: new cutter compensation algorithm that handles inside corners
[01:26:07] <alex_joni> http://git.linuxcnc.org/gitweb?p=emc2.git;a=commitdiff;h=e0c96fbe3c1850adf090bc52c0a1756513e232d2
[01:26:15] <alex_joni> right
[01:26:32] <alex_joni> you'd have to bug cradek about this one
[01:27:03] <alex_joni> I'm sure he had a reason, but I don't see what it could be ..
[01:27:08] <alex_joni> * alex_joni is off to bed
[01:27:20] <dgarr> gnight
[03:40:55] <Dave911> logger_dev:bookmark
[03:40:55] <Dave911> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-01-06.txt
[03:43:32] <cradek> dgarr: XXX only means this spot might merit attention/reexamination later
[03:44:48] <dgarr> thanks -- what necessitates the restriction for user m-codes and radius compensation?
[03:47:33] <cradek> it's more a matter of that not being handled yet, since it requires extra code to be written, and I figured nobody cared
[03:48:25] <cradek> I think you'd just have to add the enqueue/dequeue code
[03:49:49] <cradek> ... and test
[03:50:13] <dgarr> my example isn't very important ==> using mcode files to do things like reset axis info notifications. surprised when errors occurred with cutter compensation.
[03:50:32] <cradek> I can't think of any particular problem with it
[03:52:18] <cradek> yeah it's just an unhandled case. so an error is better than issuing the mcode sometime out of order (in this case, it would appear to be early)
[03:53:14] <cradek> looks like there are quite a few disallowed things - the more obscure the feature the less likely I was to make it work with cutter comp :-)
[14:23:03] <cradek> I never for a second thought of 'can excel import it' as a requirement for a tool table format
[14:24:39] <jepler> if you say "excel" you've automatically lost
[14:24:55] <cradek> what did I lose?
[14:25:31] <jepler> any inclination I might have had to listen to your nutty ideas
[14:25:39] <cradek> oh
[14:28:41] <cradek> and roland j's idea is exactly the opposite of what we were trying to accomplish...
[14:30:57] <jepler> yeah it's a different direction entirely
[14:31:43] <cradek> the whole point is you can add words without breaking existing tool tables - his commas are just the same as what we have now (fixed number of columns) but clumsier
[15:08:16] <SWPadnos> but you can have spaces in his fields ...
[15:09:41] <mhaberler> has any of you guys ever looked at the ConfigObj Python library for handling '.INI' type files? readable, editable, type-checking, type converting - and not XML
[15:10:36] <cradek> touchy and AXIS use ConfigParser
[15:11:05] <jepler> .. and they use emc's own ini parsing routines when actually parsing emc .ini files
[15:11:56] <cradek> (btw, all parts of EMC involving the tool table are C, not Python)
[15:12:39] <mhaberler> It is a superset, if you will
[15:12:41] <mhaberler> ConfigObj can handle .INI, create a valid default, range check and auto-type-convert on input together with the Validate module
[15:12:43] <mhaberler> its much better than ConfigParser - as good as it gets within .INI file limitations
[15:13:36] <SWPadnos> does it handle comments? (something like # or ; delimiting the start of a comment, regardless of whether it's at the beginning of the line)
[15:13:43] <mhaberler> Yes
[15:13:57] <SWPadnos> cool. that's something that the emc library doesn't do, AFAIK
[15:14:23] <mhaberler> # to end of lines
[15:14:25] <mhaberler> I dumped ConfigParser and switched, it was a big boost
[15:14:44] <SWPadnos> but as cradek said, the parts of EMC2 that deal with the ini are C, not python
[15:14:56] <SWPadnos> err, the tool table anyway
[15:15:22] <SWPadnos> the ini code (other than python code for some GUIs) is C/C++
[15:15:29] <mhaberler> http://www.voidspace.org.uk/python/configobj.html, well supported by author
[15:15:30] <mhaberler> oh, C - I see
[15:16:50] <jepler> and I don't think we want ini for tool tables; at least, nobody has yet suggested we should have multiple lines per tool
[15:17:04] <SWPadnos> yeah, that's a big change
[15:17:15] <SWPadnos> though XML would likely be multiple lines
[15:17:34] <jepler> in xml lines is the wrong question
[15:17:57] <cradek> it would accomplish the goals at hand (you can add a new field/line/feature without invalidating old tool tables)
[15:17:57] <jepler> pretty-printed it'd clearly be many lines per tool, I agree
[15:18:24] <cradek> and all fields/properties are optional
[15:19:30] <cradek> other than discarding any proposals that don't meet these goals, I don't know how to choose
[15:19:37] <cradek> seems like it's just personal preference
[15:20:01] <cradek> "easy to read with C" and "doesn't need additional libraries or build deps" may be relevant
[15:20:05] <SWPadnos> we can do a little bit of thinking about the future, and how maintenance and extension would go
[15:20:18] <SWPadnos> but yeah, there's no silver bullet for making the choice
[15:20:20] <cradek> yes
[15:21:07] <jepler> the alternate point of view is that we already have structured access to tool information and APIs to set tool information; no program that wants to manipulate the tool table need worry about the on-disk format
[15:21:12] <mhaberler> I only care about 'self-describing', 'no breakage on extension', and import from EMC
[15:21:14] <mhaberler> http://ndevilla.free.fr/iniparser/html/index.html could fill the C void
[15:21:46] <SWPadnos> is the API for setting tool information NML?
[15:21:54] <jepler> SWPadnos: MDI over NML
[15:22:24] <SWPadnos> that assumes that the tool table manipulation program will always be on a system with a runnable EMC
[15:22:30] <cradek> if MDI could set EVERY property, then the tool table could be the exact gcode and we could read it with the interpreter
[15:22:45] <SWPadnos> and that's not a good assumption when you consider the CAD/CAM programs that people will run
[15:23:06] <cradek> it does bother me that we're rewriting a sort-of gcode parser
[15:23:10] <SWPadnos> (on Windows ...)
[15:23:28] <SWPadnos> yeah, I don't think that's the way to go
[15:23:59] <SWPadnos> unless we make it so that the parser can be called from other places than the interp/task/whatever it is that actually runs the G-code in emc
[15:24:38] <cradek> if we'd get rid of iotask that would be very natural
[15:24:51] <cradek> er wait, I don't follow what you said
[15:25:00] <SWPadnos> heh
[15:25:17] <SWPadnos> I basically said we should re-use the existing tokenizer, rather than writing another one
[15:25:18] <cradek> I thought you said what I was thinking, but when I read the words, I saw that you didn't
[15:25:23] <cradek> ok sure
[15:25:36] <jepler> whatever we do, we won't be able to seriously influence the format that CAM software experiences
[15:26:05] <jepler> in my model ("use nml in running emc system") you have two choices: write an exporter from emc's tool API to the file format your cam needs; or write an importer from the cam format to MDI commands to set the tool table
[15:26:23] <SWPadnos> I gather that some people have the aim of having shop-wide tool databases
[15:26:45] <cradek> that's fine considering we now have arbitrary tool numbers
[15:26:46] <SWPadnos> they will probably have to write some software, and that software will need to be able to read and/or write EMC-compatible tool tables
[15:27:19] <mhaberler> that I had in mind with XML - doing XML-to-XML transformation is fairly easy
[15:27:28] <SWPadnos> that code is not guaranteed to run on an EMC-capable machine
[15:27:49] <SWPadnos> for that reason, the on-disk format has to be specified, and the NML access method can't be the only way to access tool information
[15:27:52] <jepler> bbl, I don't really have a horse in this race and so I'm not sure I'm being constructive.
[15:27:58] <SWPadnos> heh - see you
[15:28:12] <SWPadnos> I should be building PC boards, so I'll bbl as well
[15:32:02] <cradek> I'm pretty sure XML is right out. it's hard for a human to read, it's hard for a human to write, it's hard for a human to edit, it's probably (?) hard to manipulate from tcl (tooledit program), and it causes new library dependencies
[15:32:26] <cradek> frankly I don't see any good reason to use it
[15:36:13] <SWPadnos> the only benefit that I see to something like XML is that the entire tool table schema can be embedded inside a bigger file with other information
[15:36:35] <SWPadnos> so someone can have CAD models, materials descriptions, multiple G-code files, and the tool table(s) in one file if they want
[15:36:42] <SWPadnos> (not that I see that happening any time soon)
[15:38:46] <cradek> if the proposed benefit is that nebulous, I'm sticking with "don't see any good reason" so far
[15:39:03] <SWPadnos> heh
[15:39:20] <cradek> (I have pretty much no idea what you're talking about)
[15:39:50] <SWPadnos> XML makes it relatively easy for a tool table to be like a subroutine in a bigger file
[15:39:55] <SWPadnos> (does that help? :) )
[15:40:41] <mhaberler> my use case is moderate:
[15:40:42] <mhaberler> I export DXF for some target ( a machine with a tooltable). Each shape is exported with an a parameter set, which includes tool, feeds etc.
[15:40:44] <mhaberler> It would be useful to have the program read the tooltable for that machine, and in the exporter have a dropdown 'use tool x", which sets tool geometry and changer position for G-code generation.
[15:41:26] <cradek> interesting - you consider the machine the "source" of the tool table. I notice others consider the cam to be the "source".
[15:43:11] <mhaberler> ideally I'd choose a symbolic name for the tool and leave position selection to the machine
[15:43:26] <cradek> yeah that would be nice.
[15:44:00] <cradek> I've pondered using descriptive tool numbers to solve that problem
[15:44:38] <cradek> something like (half-baked) T1xxx = drill of 0.xxx" diameter, T2xxx = 2fl end mill 0.xxx dia, etc
[15:44:44] <mhaberler> I havent looked into your toolchanger code, do you use a separation tool-posiiton table?
[15:45:06] <cradek> I don't understand the question
[15:45:50] <mhaberler> sorry.. currently there is a mapping betwewen tooltable entry ID and toolchanger position, right?
[15:46:01] <cradek> right, tool vs pocket
[15:46:40] <cradek> they are both in the tool table
[15:48:03] <mhaberler> ah, I see, so the tool table holds the pocket info as well and may differ from tool id
[15:48:04] <mhaberler> what's in there for an empty pocket?
[15:49:15] <cradek> you do not need a line for an unused pocket
[15:49:32] <cradek> or you can put an invisible tool in it if you want
[15:49:37] <cradek> there is no special handling of empty pockets
[15:49:51] <cradek> I keep T0 (which is invisible) in my changer so I can empty the spindle
[15:51:01] <mhaberler> ok, well thats good enough then, I dont see what a separate pocket/tool mapping table would bring
[15:51:03] <mhaberler> so its one table
[15:51:04] <mhaberler> well look, if there are fixed column tags in line 1 which describe the column, that gets us 95% of the way at low cost fare
[15:51:38] <mhaberler> by fixed I mean 'not subject to translation because it might be displayed in the UI'
[15:54:13] <cradek> that's an interesting idea too, but I don't think it's clearer than the letter-number scheme Michael G currently has
[15:56:17] <cradek> imagine a tool table with two tools, one along W, one along Z. Your scheme is three lines: T W Z / 1 1 0 / 2 0 1 vs micges's scheme: T1 W1 / T2 Z1
[15:56:30] <cradek> I think his is easier to understand and edit
[15:57:29] <mhaberler> is that structure read/written in C only or is there some Python code which reads this?
[15:58:14] <cradek> currently I think only iotask (C) and tooledit (tcl) read/write the table
[15:59:32] <mhaberler> ok, that doesnt look to complex.
[15:59:34] <mhaberler> I give and use that.
[16:56:22] <cradek> "Too bad they didn't invite a site where you can just search for things.
[16:56:23] <cradek> Oh wait, they did.."
[17:03:08] <alex_joni> maybe I should take that out :/
[17:03:32] <cradek> personally I like the new snippier alex
[17:03:48] <alex_joni> been a long day and a short night
[17:04:06] <cradek> it goes with "your idea is daft" and "you have to keep reading past the first line"
[17:04:06] <jepler> I know the feeling. two nights in a row I've gotten way under 9 hours
[17:04:20] <jepler> * jepler sticks his tongue out at alex_joni
[17:04:29] <alex_joni> ha, I've been getting 4-5h/night lately
[17:04:37] <jepler> I think that might actually kill me
[17:04:59] <alex_joni> I'm sure you're way more robust than you look
[17:05:02] <alex_joni> err.. think
[17:05:03] <alex_joni> :P
[17:05:06] <cradek> hahaha
[17:05:51] <jepler> har har
[17:06:27] <jepler> (I'm very jealous of people who can engage in this kind of banter in a language that is not their first..)
[17:06:46] <alex_joni> oh, we can always switch the language if you prefer
[17:06:48] <cradek> yeah
[17:07:30] <cradek> bleh... too many donuts
[17:07:35] <jepler> keep eating!
[17:07:40] <cradek> noooo
[17:08:07] <alex_joni> sounds like a lost bet
[17:09:13] <jepler> nah, I just brought in donuts for my coworkers today
[17:09:36] <jepler> cradek apparently doesn't know when to stop
[17:09:40] <jepler> when it comes to donuts, of course
[17:09:41] <alex_joni> ah, sounds good ..
[17:09:48] <alex_joni> I was kinda alone at work today
[17:10:17] <alex_joni> most of my co-workers are still on vacation till next week
[18:45:10] <jepler> alex_joni: aww so sad
[19:05:49] <alex_joni> jepler: actually it's quite nice for a change
[19:06:07] <alex_joni> (I'm on vacation myself, but couldn't stay home..)
[19:15:08] <jepler> I see.
[19:25:09] <alex_joni> started working on my radio ;)
[19:28:05] <jepler> what are you doing with radio?
[21:40:26] <alex_joni> jepler: building a wifi radio
[21:40:43] <alex_joni> something like this:
http://mightyohm.com/blog/2008/10/building-a-wifi-radio-part-1-introduction/
[21:41:39] <jepler> alex_joni: I've considered trying to do something like this with the beagleboard, except the audio had terrible pops for me on open/close
[21:43:30] <cradek> heh, "working on a radio" for me means replacing 50 year old electrolytics
[21:44:54] <alex_joni> jepler: I bought some of those crappy usb soundcards a while ago (1 year or so)
[21:45:21] <alex_joni> I tested one of them recently and they are a match for some pc speakers
[21:45:29] <alex_joni> just as good/bad
[21:45:42] <alex_joni> I'd say enough for a kitchen radio
[23:00:44] <micges> alex_joni: side effect of new teleop jogging code is that many axis related pins are now in motion