SWPadnos_ is now known as SWPadnos
alex, are you around?
do you know what permissions are necessary for the wiki?
yes, write permissions :)
I'd think cncman/pg167418 (or group linuxcnc)
but I think the files shouldbe owned by cncman
ok, so you think a chown -r cncman * would be the right thing to do?
except capital R
strange - it appears I'm not allowed to do that ...
users can't chown ;)
but you can mv wiki wiki.old
cp wiki.old wiki
-r or something
I should be root-like for my sites, but I guess not
ok - I'll try that then :)
can you check it now?
SWPadnos: seems ok
SWPadnos: many thanks
btw, I mirrored the LiveCD
but it is also on linuxcnc
[12:07:55] <alex_joni> http://www.linuxcnc.org/index.php?option=com_content&task=view&id=21&Itemid=4
cool. there's effectively unlimited space and bandwidth there, might as well use it
I thought chris asked you about that :)
I think I suggested it anyway
I remember so too :P
then there are the email archives ... ;)
the nice thing is that I've gotten two referrals so far. two more, and the hosting costs will be paid for another two years
one more after that, and I can add a static IP, and CVS could be moved as well (we can do SVN now anyway)
two referrals ?
a couple of friends have signed up. I get a $97 credit for each (after a waiting period)
oh cool ;)
indeed it is
sjml is now known as sjml_
sjml_ is now known as sjml
hi alex, quiet here!
sjml: it's sometimes quiet
but we usually are in both channels
#emc and #emc-devel
in #emc there's a bot called CIA-*
which reports commit messages
btw, you might want/ should sign up to the emc-commit list
you'll get email about all commits
yep, i'm already subscribed
sjml: it might be a good idea to let everyone know who you are :)
including me :)
even if they don't seem to be around.. they are lurking around here
ah, thought it made no sense talking to nobody ;-)
* alex_joni peeks out of the silence
anyone else around to greet sjml aboard?
hi chris (?), have you already put me up for cvs access?
hello, I got your mail but have not acted yet
ok, just wanted to know
sjml: now that there's an audience :) tell us a bit about yourself
sjml: do you have a sourceforge account yet?
yes, baslaarhoven. Alex has registered me already as emc developer
ok I will make your cvs account with the same name
fine, that's what i expected
ok, a bit about myself:
I'm a hardware and software developer with more mileage than i dare to admit
I've built a 3-axis servo controller for my mini-mill.
sjml: your account is ready
I didn't really have anything to say - just thought I'd chime in another hello :)
cvs sshd: Accepted publickey for baslaarhoven
sjml: you'll get used to him :)
cradek: you won't
oh, btw.. my coworker blew a 298 today :)
went up in nice smoke
cradek: seems to be working indeed
I think cradek may have let the smoke out of one too
now I can start submitting ;-)
yes but just one I think
who is maintaining axis ?
we all use irc to work together, it works nicely
jeff and I mostly (jeff mostly), but now anybody can work on it
I'm using metric settings and found the tool displayed 25.4 times too large. Is this a wrong setting or ?
Of course I fixed it, but now it won't work for you imperial guys :-(
but I have a metric configuration on my lathe and I don't have that problem
this is recent cvs?
checkout of pre-2.1 about two weeks ago
(I bet I haven't updated that machine for a while)
sjml: you are using a tool file with metric tool sizes? do your files contain G20 or G21 to set the units?
ok, mine is probably a bit older
all milling is ok, just the tool displayed being displayed is to large
jepler's questions are the important ones
and do you mean the cone is too large, or the shaped tool?
the shaped tool i think, it often covers the entire display area ...
sjml: do you have a proper tool file?
answer jepler's questions about this first please
jelper: is there a special metric tool file format ? wasn't aware of that. radius compensation is working fine though
so the tool diameters are specified in mm in your tool file right?
sjml: there is only one tool file, but you enter the values in metric inside of it
do you have g21 in your gcode?
that's what i've done, and as I said the radius compensation is working fine
g21 is very important at the beginning of a program file
[20:10:46] <jepler> http://emergent.unpy.net/files/sandbox/tooltoobig.png
cradek: don't know, either G20 or G21 to select metric
it helps a lot on some rather cumbersome decisions about inch/metric
jepler: now that you're around.. I can't run sim-axis anymore
alex_joni: you can't?
alex_joni: what broke?
I don't have yapps & co
too bad, get 'em
I know how to make it work thank you :)
the question is.. is that the right answer?
jepler: but isn't that the right behavior for g21 t1m6 ??
jepler: by "right" I mean according to spec, not necessarily sane
cradek: no, with g21 in effect those units should be in mm
how about if you first do T1M6 then G21 ?
oh right, the tool gets smaller
cradek: but AXIS shows the same thing whether I load the tool with g20 or g21
I have a feeling there's a mess here
I mean, I *know* there is
that's because the spec is insane
for starters, there's the spec itself .. yeah
are tool table values always mm?
SWPadnos: they're whichever units you are in at the time (G20 or G21)
and the decision is based on ... ?
are you serious?
holy crap. that's a spec in need of change
the var file was that way too, according to spec, but I "fixed" it a while back
and it looks like those values are just copied into the emc stat buffer, but you have no idea which of g20 or g21 was in effect so you can't properly interpret the values
it looks like I assumed they were in inches
cradek would get the "right" behavior if he always uses G20 programs on his metric lathe
* cradek coughs
hmmm. I had suggested a while back that having a value/units system might be a good thing ...
it's a royal PITA to change all the length references in the code, but it may end up being worth it
I suggest we interpret the tool table in ini units, just like the var file
what about length offsets? it's just broken otherwise
is it legal to specify different units per axis?
(other than angular/linear)
perhaps the ini lets you do it, but it surely doesn't work
and it's a crazyass thing to do IMO
that was my thought
SWPadnos: per axis?
it would make sense if you cobble together a machine using metric and imperial ballscrews
SWPadnos: are you building Ariadne rockets?
I was just wondering where in the ini the units would be taken from (which axis, or if there's one in TRAJ ...)
wherever everything else gets the units
ok. that's a good spot :)
am i missing something, or shouldn't the tool just be displayed in 'units' ?
just like everything else
the question is "how big is the tool"?
we're debating what the numbers in the tool table represent
if your tool table says diameter "10" and you run a g20 program, that's currently pretty darn big
I think that's broken behavior even though the ngc spec says it's so
sometimes AXIS has a way of showing these underlying problems and we have to work out the bigger issue to solve them
it would be better to add a column to the tool table that specifies the units for that tool
then you could have metric and imperial tools, without any math
yes, but somehow this is a deviation from how everything else is done (units only)
yes and it probably breaks all tool tables.
yeah - I guess it would be nice to have a sane default, instead of the spec-compliant one
cradek: otoh we already have differenet tool tables from 2.0.x
so it might be wise to incorporate this now if we ever do
no, 2.0.x tool tables are compatible
no need to break tables: only use the dimension if it's specified (backwards compatible)
I didn't say they are not compatible
I see what you mean, it's true there is a new format in addition to the backward compatibility
so if there's a new format, make it hold this small addition too
can we change the way units are defined for lathe-format lines only? (so that they are ini-units not g2x units)
and deprecate the old format and its behavior
I think units make sense for mills as well
yes but the lathe-format could be used for both I think
that's true but it's a bit obtuse
ok. as long as it's usable for mills as well, that would be finwe
cradek: you had an idea about addign another dimension compensation?
or do I remember it wrong?
there will be columns of useless zeroes
we should use xml, then
adding Y tool offset is a bit tempting
good night all
cradek: I'm not sure I understand when a Y offet is useful
only for multiple tools on one head I suppose
imagine a probe that mounts behind or in front of the tool
it's not going to be used very often, or ... ever
someone asked for it, something about a laser I think
I don't remember the details
oh I have a vague memory of that