today i encounter this restriction (interp_convert.cc): (_("Cannot call user-defined M code with cutter radius compensation on"))); // XXX
and wonder if it is necessary?
dgarr: haven't seen that one
do you think it is necessary? what does the XXX comment mean?
no idea what XXX stands for
* alex_joni misses lxr
i see this in gcodemodule.cc: XXX: This needs to be re-thought.
so maybe the restriction on user-defined M codes and radius compensation could be reconsidered?
I think it's on purpose
it wasn't there a year ago
sha1 --> e0c96fbe
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
you'd have to bug cradek about this one
I'm sure he had a reason, but I don't see what it could be ..
* alex_joni is off to bed
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-01-06.txt
dgarr: XXX only means this spot might merit attention/reexamination later
thanks -- what necessitates the restriction for user m-codes and radius compensation?
it's more a matter of that not being handled yet, since it requires extra code to be written, and I figured nobody cared
I think you'd just have to add the enqueue/dequeue code
... and test
my example isn't very important ==> using mcode files to do things like reset axis info notifications. surprised when errors occurred with cutter compensation.
I can't think of any particular problem with it
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)
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 :-)
I never for a second thought of 'can excel import it' as a requirement for a tool table format
if you say "excel" you've automatically lost
what did I lose?
any inclination I might have had to listen to your nutty ideas
and roland j's idea is exactly the opposite of what we were trying to accomplish...
yeah it's a different direction entirely
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
but you can have spaces in his fields ...
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
touchy and AXIS use ConfigParser
.. and they use emc's own ini parsing routines when actually parsing emc .ini files
(btw, all parts of EMC involving the tool table are C, not Python)
It is a superset, if you will
ConfigObj can handle .INI, create a valid default, range check and auto-type-convert on input together with the Validate module
its much better than ConfigParser - as good as it gets within .INI file limitations
does it handle comments? (something like # or ; delimiting the start of a comment, regardless of whether it's at the beginning of the line)
cool. that's something that the emc library doesn't do, AFAIK
# to end of lines
I dumped ConfigParser and switched, it was a big boost
but as cradek said, the parts of EMC2 that deal with the ini are C, not python
err, the tool table anyway
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
oh, C - I see
and I don't think we want ini for tool tables; at least, nobody has yet suggested we should have multiple lines per tool
yeah, that's a big change
though XML would likely be multiple lines
in xml lines is the wrong question
it would accomplish the goals at hand (you can add a new field/line/feature without invalidating old tool tables)
pretty-printed it'd clearly be many lines per tool, I agree
and all fields/properties are optional
other than discarding any proposals that don't meet these goals, I don't know how to choose
seems like it's just personal preference
"easy to read with C" and "doesn't need additional libraries or build deps" may be relevant
we can do a little bit of thinking about the future, and how maintenance and extension would go
but yeah, there's no silver bullet for making the choice
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
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
is the API for setting tool information NML?
SWPadnos: MDI over NML
that assumes that the tool table manipulation program will always be on a system with a runnable EMC
if MDI could set EVERY property, then the tool table could be the exact gcode and we could read it with the interpreter
and that's not a good assumption when you consider the CAD/CAM programs that people will run
it does bother me that we're rewriting a sort-of gcode parser
(on Windows ...)
yeah, I don't think that's the way to go
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
if we'd get rid of iotask that would be very natural
er wait, I don't follow what you said
I basically said we should re-use the existing tokenizer, rather than writing another one
I thought you said what I was thinking, but when I read the words, I saw that you didn't
whatever we do, we won't be able to seriously influence the format that CAM software experiences
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
I gather that some people have the aim of having shop-wide tool databases
that's fine considering we now have arbitrary tool numbers
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
that I had in mind with XML - doing XML-to-XML transformation is fairly easy
that code is not guaranteed to run on an EMC-capable machine
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
bbl, I don't really have a horse in this race and so I'm not sure I'm being constructive.
heh - see you
I should be building PC boards, so I'll bbl as well
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
frankly I don't see any good reason to use it
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
so someone can have CAD models, materials descriptions, multiple G-code files, and the tool table(s) in one file if they want
(not that I see that happening any time soon)
if the proposed benefit is that nebulous, I'm sticking with "don't see any good reason" so far
(I have pretty much no idea what you're talking about)
XML makes it relatively easy for a tool table to be like a subroutine in a bigger file
(does that help? :) )
my use case is moderate:
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.
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.
interesting - you consider the machine the "source" of the tool table. I notice others consider the cam to be the "source".
ideally I'd choose a symbolic name for the tool and leave position selection to the machine
yeah that would be nice.
I've pondered using descriptive tool numbers to solve that problem
something like (half-baked) T1xxx = drill of 0.xxx" diameter, T2xxx = 2fl end mill 0.xxx dia, etc
I havent looked into your toolchanger code, do you use a separation tool-posiiton table?
I don't understand the question
sorry.. currently there is a mapping betwewen tooltable entry ID and toolchanger position, right?
right, tool vs pocket
they are both in the tool table
ah, I see, so the tool table holds the pocket info as well and may differ from tool id
what's in there for an empty pocket?
you do not need a line for an unused pocket
or you can put an invisible tool in it if you want
there is no special handling of empty pockets
I keep T0 (which is invisible) in my changer so I can empty the spindle
ok, well thats good enough then, I dont see what a separate pocket/tool mapping table would bring
so its one table
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
by fixed I mean 'not subject to translation because it might be displayed in the UI'
that's an interesting idea too, but I don't think it's clearer than the letter-number scheme Michael G currently has
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
I think his is easier to understand and edit
is that structure read/written in C only or is there some Python code which reads this?
currently I think only iotask (C) and tooledit (tcl) read/write the table
ok, that doesnt look to complex.
I give and use that.
"Too bad they didn't invite a site where you can just search for things.
Oh wait, they did.."
maybe I should take that out :/
personally I like the new snippier alex
been a long day and a short night
it goes with "your idea is daft" and "you have to keep reading past the first line"
I know the feeling. two nights in a row I've gotten way under 9 hours
* jepler sticks his tongue out at alex_joni
ha, I've been getting 4-5h/night lately
I think that might actually kill me
I'm sure you're way more robust than you look
(I'm very jealous of people who can engage in this kind of banter in a language that is not their first..)
oh, we can always switch the language if you prefer
bleh... too many donuts
sounds like a lost bet
nah, I just brought in donuts for my coworkers today
cradek apparently doesn't know when to stop
when it comes to donuts, of course
ah, sounds good ..
I was kinda alone at work today
most of my co-workers are still on vacation till next week
alex_joni: aww so sad
jepler: actually it's quite nice for a change
(I'm on vacation myself, but couldn't stay home..)
started working on my radio ;)
what are you doing with radio?
jepler: building a wifi radio
something like this: http://mightyohm.com/blog/2008/10/building-a-wifi-radio-part-1-introduction/
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
heh, "working on a radio" for me means replacing 50 year old electrolytics
jepler: I bought some of those crappy usb soundcards a while ago (1 year or so)
I tested one of them recently and they are a match for some pc speakers
just as good/bad
I'd say enough for a kitchen radio
alex_joni: side effect of new teleop jogging code is that many axis related pins are now in motion