EMC: 03cmorley 07TRUNK * 10emc2/configs/common/configurable_options/pyvcp/spindle.xml: Add tool number display
EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.glade: Change wording for latency test button and text entry box to clear up what numbers are wanted. As suggested by John T
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-01-12.txt
[Global Notice] Hi all, we appear to have lost our Moscow based client server, and with it approximately 1600 users. We're looking into the issue now and should hopefully have both the server and the users back shortly. Apologies for the inconvenience. Thank you for using freenode and have a nice day.
jepler_ is now known as jepler
EMC: 03cradek 07TRUNK * 10emc2/src/emc/task/emccanon.cc: act better if we get unexpected nonzero values for uninitialized axes
cradek: do I need to add anything to the manual on the cutter comp?
or does it just work better
BigJohnT: wow, good question. more likely, you need to take a bunch of junk out
BigJohnT: there's a bunch of outdated stuff now
steves_logging is now known as steve_stallings
the lead in stuff?
is there mode selection to still get the old rigid gouge detection?
steve_stallings: (it wasn't gouge detection)
it was refusal to cut any path where the cutter couldn't touch all parts of every segment
well gouge prevention
the new code does detect gouging now
it wasn't even that
it was just what I said
it was "I don't know what to do, so I'll refuse to do anything"
how does the new code alert the user to gouges that are being modified?
hold on a sec. what do you mean by gouges?
I think we're talking past each other
OK, how does the new code alert the user that the path has been trimmed to accomodate the cutter radius
it doesn't do anything special to warn you that there were inside corners
i.e. - if the use assumes that the cut will be accomplishing the impossible, but it really is not
"You asked me to cut an inside corner with a round tool. This is impossible but I'll leave a fillet there for you which is probably what you wanted anyway. [OK]"
"You asked me to cut an inside corner with a round tool. This is impossible but I'll leave a fillet there for you which is probably what you wanted anyway. [OK]"
through the speakers on the PC, right?
then it calls your mother with the modem and cusses at her
you'd be surprised at what customers think you put in the speech ROMs
steve_stallings: to answer your question seriously: it doesn't warn, it just cuts the corner leaving the fillet
OK here is summary of other implementations that I have information about
old Fanuc - like old style EMC, generates error that stops machine
Yasnac - ditto
steve_stallings: define when
new Fanuc - compensates move like cradek's new code
Haas - paramater to select either behavior
alex_joni - please rephase question about "when"
what cases are you talking about for the a.m. controls
steve_stallings: interesting, thanks
sharp inside corner cut with a round tool?
ok.. just wanted to make sure
even my BOSS8 handles it without error (I think - I've never used it)
the manual says it works anyway (with a list of restrictions)
steve_stallings: looks like noise was getting into the opto side of the circuit.
check this, my memory is that I had problems with Boss 8, perhaps it was entry moves
which side of the opto?
that helps me continue to not use it :-)
my favorite Boss quirk is the missing decimal point in F words, feed rate equals zero, move continues forever, no warning
I found another: F8.0 -> 8 ipm; F8.00 -> rapid
I think the led side - turning them on harder and putting a 300pf cap across the osolator output 'seems' to have fixed it. Nominal for these optos are 16ma. Yikes
OK, that would lower the effective output impednance on the phototransistor side
Ouch! Not nice to rapid just because you added a zero
also if you MDI a canned cycle and don't specify X and Y, it just crashes
is kimk the same person as Kim Lux on the list? I have contact info for him regarding the Panasonic servos
don't know how many times I've tried that ("drill a hole right here")
our 60's vintage controller used leading zeros.. So f6 was 60 in/min.
are you saying F6 and F60 were the same?
steve_stallings: KimK is the guy who was at cnc workshop who was running the motor mounts for us
and F06 being 1/10 that fast?
skunkworks_: haha, that takes all
my friend with the Boss 8 just uses dial jog to drill, cost him some excitement once, using wiggler and had increment set much higher than he thought, punched thru 0.125" alum plate
on the old HNC control, you had to program G01X00000Y00000F8000 to get a rapid
f98 was 98 ipm and 99 was 200 ipm. (only 2 digit for feedrate)
lacking an email address, if you catch KimK back on line, let him know that I have the contact info that he wanted
later, gotta run...
take it easy :)
steve_stallings is now known as steves_logging
not to mention - you had to calculate the feedrate differently for g1/g2/g3. (it was 3 digits)
[Global Notice] Hi all, In about 5 minutes time we'll be taking down one of our client servers for maintenance. The downtime window is one hour but it should take considerably less time. Affected users ~1k. Thank you for flying freenode and have a nice evening!
EMC: 03cradek 07TRUNK * 10emc2/src/emc/task/emccanon.cc: fix another possible cause of arc-skipping
[Global Notice] Hi again. We've moved leguin to new hardware, it's up and running and linked to the network again. That concludes today's scheduled maintenance and with some luck it's plain sailing from here, until Friday when we move hubbard to a new switch! Big thanks to the University of Umeå. Sorry for the downtime and have a continued nice evening.
cradek: how you figure it out about this case?
this is slighly quieter, and less off-topic
things are harder to miss in here..
ok. I'll keep that in mind for the future.
and it's always best ot just start typing, and people will read back when they return to their consoles
By the way, does anyone know if my emcrsh patch was accepted? I posted it on the emc-developers mailing list a while back.
I don't think it's been rejected :)
(but it may be that nobody has tested and applied it
hmm.. you did?
I probably missed it.. can you pastebin it?
title "patch: emcrsh shutdown"
That's the one. I'll upload it somewhere as well
is that the one?
[19:16:34] <SWPadnos> http://pastebin.ca/1306698
Beat me to it :-)
does commandShutdown() return 0 when it can't shut down?
cradek_ is now known as cradek
alex_joni: I can't remember now. It is a while since I did it
ok, n/m then.. I'll look at the file :)
Here's another. It fixes a buffer overrun issue www.sheetcam.com/emc/emcrsh-overrun.patch
LesNewell: what's left to do on diameter?
Revision 1.14: Applying patch from Les for shutdown commad
LesNewell: HTTP 404 - File not found. on the overrun patch
cradek: At the moment only X is affected
One day I'll learn to type www.sheetcam.com/emc/emcrsh_overrun.patch
The question is, should anything else be affected, such as threading?
oh right, I remember that
My personal feeling is that it shouldn't.
I think the three g76 i,j,k should be diameters
LesNewell, buf can still overflow, though str can't
I think this because the numbers you use to decide i,j,k when threading are always shown as diameters (like pitch diameter) in tables, and the tool you use to measure them (thread wires) gives you diameter
Hang on, let me have another look..
can you explain why you think they should not be diameter?
SWPadnos: You're right. I suppose the only safe thing to do is make sure buf is twice the size of str.
no, that's a while loop
it could go more than twice through
I think the only way to do it is to keep track of the length of buf and use strncpy or similar
That won't work. If buf is already full, someone is playing silly buggers.
err - cat, not cpy
right - keeping track is better ;)
The only way to do that is to keep sending data with no line ends.
I don't know if any reasonable command could be >1600 chars
if not, then keeping track and then ignoring anything read beyond 1600 would make sense
Exactly. I think the only safe thing to do is discard some data.
that's a C++ file; maybe you should fix the bug forever by using std::string
sure, or change the constant if necessary
I think it makes sense to limit the total size of the string in any case
cradek: Sorry, I am now looking at G76. Not very good at multitasking :-)
you need to go dual-core :)
Well I have been called a big head before - does that count?
we'll accept that
cradek: I see where you are coming from. I have to say I find the emc G76 a little confusing.
Not as bad as Fanuc though
if I can help, ask away
I just find making X the clearance or drive line rather counter intuitive
X is normally the finished diameter, not the start
Sorry, that didn't really come out right. I meant to say not using X for the finish diameter
Program received signal SIGFPE, Arithmetic exception.
0xb7f3fc64 in _ (inst=0xb7cf0dec, period=1000000) at zd.comp:7
cradek: add these lines in sim_rtapi_app.cc:
fpu_control_t __fpu_control = _FPU_IEEE
& ~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM);
then, do you know how to start rtapi_app under the debugger?
well, I just attach to it
milltask and/or rtapi_app
that's work in milltask too
it looks like the instruction pointer is the instruction *after* the one that caused it -- it's pointing at the fstpl after the fdivrp that was actually 0/0.
alex_joni: a little component that divides by zero
alex_joni: I'm trying to help cradek find whether there are other places that are (unintentionally) forming infs or nans
cradek: Well it doesn't look too bad to tweak convert_threading_cycle() to handle diameter
Should I go ahead?
I'll probably need someone else more familiar with G76 than I am to check it works as expected though.
sure, I think so, do you think so too?
I'd be happy to help test it
OK. I'll go ahead.
jepler: any chance to make motion controller translatable ?
micges: you mean dmesg messages?
I mean like "joint following error"
motion.c and freinds
the problem is that those are kernel modules, and there are no i18n tools in kernelspace that I know of
alex_joni is correct
micges: you can, if you are persuasive enough, try to catch the error message as motion sends it to task, and try to translate it on the fly
no idea how to do that though.. but if you manage to do it, we'll surely consider it ;)
no, I don't want to do that
you could do it in the UI though.
you'll get the message after it's been printf-formatted (e.g., "joint 0 on limit switch"), so there are not just a fixed number of messages
I am not sure what the right approach is, but this is the wrong one
Yes. You're right.
I suppose the only other way is to have the messages as a file rather than hard-coded
You can update the file in user space
you also have to have some way to deal with the fact that any component can print additional messages
LesNewell: you mean actually report error numbers
that's .. even worse imo
well.. maybe not worse, but still bad
Instead of hard coding the error messages, just look in an 'errors.txt' file
Line 1 is 'joint %i on limit switch' and so on
Read the line, printf as needed then send it out.
here's how I'd approach it (I think): in kernel space, rtapi_print_msg saves its arguments; then something in userspace pulls off the arguments, performs the gettext() lookup on the appropriate arguments, and then performs the printf operation
so it'd still look like gettext to the programmer; no fiddling around with "error numbers"
but that still doesn't solve the problem of errors printed by components not shipped with the core emc2, which wouldn't be in the .pot/.po/.mo file
so .. basically it sucks
and as an american, I think everyone should just speak american.
The tower of babel has a lot to answer for :-)
jepler: It was English befor you lot go hold of it ;-)
and it was anglo-frisian before that
Updated lathe diameter mode patch www.sheetcam.com/emc/lathe-diameter.patch
Note I couldn't test G76 'cos I haven't got a working spindle sensor at the moment.
LesNewell: sim/lathe has a simulated spindle
Can you give me an example G76 to try.
whee.. bug change of error messages
Near line 27 of g76.ngc: Tool radius not less than arc radius with comp
that means your tool table doesn't match what the program expects - just delete everything but the threading section
jepler: the lathe-diameter.patch from les changes almost all rs274ngc error numbers
bottom of the patch
additional error messages should be done with the new string error macros, not the old number-based macros
I didn't know that. Foolishly I tried to keep the 'bug' error messages together.
I can change it if you want.
LesNewell: the preferred way is use the new string error macros (no numbers)
worse yet, I (?) recently changed some of the old error messages in that file, so the patch won't apply
the second way is to add error numbers at the end.. although the other way is better
other than that, it applies
patch looks good to me - I can't think of any problems with it
* jepler finally finds the patch everyone is talking about
my terminal's too dumb to highlight it when it doesn't start 'http'
LesNewell: is this the only new error?
Just checked - yes.
wow that must have been one pain in the *** to do
I'm fixing it, and I will commit
Amazing what you can do with regular expressions and a bit of ingenuity
unless you have any other changes?
LesNewell: oh in that case I don't feel quite so bad about it
No other changes that I know of from that file.
a lot of people wouldn't have been capable of that
Took me a few tries :-)
what am I missing here? when I MDI G7 I don't see G7 in Active G-Codes, and when I load a program, it still works as radius
if I put G7 in the program itself, it does what I expect
or is that normal that they don't affect each other?
you'd think I'd know this
I had that once. Axis seems to sometimes use the wrong rs274ngc.so
It is using an unmodified version of the lib so G7/G8 don't work.
but it does work
the preview is correct when I load the g7 program
Strange. I tested it mainly from MDI.
Just now I set G7 in MDI the re-ran the G76.ngc and it ran half scale in X as expected.
does the preview show the half scale too?
Not in my case because the code has no G7 in it. Hang on, I'll check with G7 in the code.
maybe this is normal...
The backplot and emc don't seem to talk to each other. Backplot doesn't know emc's state.
emctop shows g7/g8 properly
I think it's just an AXIS problem - what you did is right
AXIS needs update too
it replicates interp/canon.. so probably that part
should I commit what we have so far?
if it looks ok.. why not?
The backplot shows similar behaviour with G20.G21.
cradek: I'm happy with it if you are.
EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (8 files): Lathe diameter mode, thanks to Les Newell
cradek, LesNewell: looks good judging by the commit
[21:11:49] <cradek> http://timeguy.com/cradek-files/emc/ugly-rad.png
this needs some work...
either move the numbers right, or the home icon to the right end
Oops, was the me?
no, I just did it
showing "X" and "Dia" is now wrong, so I'm trying to make it do something sane
Oh that's all right then. I did the same a little while back.
But I was too lazy to fix it properly
By the way, when I build I get this warning:
WARNING: "fabs" [/home/les/Documents/src/emc2-trunk/src/steptest.ko] undefined!
if i < len(homed) and limit[i]:
what a strange condition
I wonder if someone meant len(limit)
LesNewell: don't sweat it. the kernel build loves to print those messages, but often they don't actually indicate a problem.
I think the fix for it is one of those things paul_c says he has but would rather make a fuss about than share with us ;-)
* jepler tries to remember
he's complained about so many things and fixed none of them, it's hard to keep them all straight
well - all you have to do is reactivate his cvs access. Jeeze.
jeez, let's not start
EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: show Rad/Dia, not X/Dia, now that X is sometimes Dia
Looks good to me.
darn, BigJohnT left, let's not forget to ask him to fix the docs
well - that is pretty cool.
Yes, good point.
By the way, a good tool for browsing sources is Code::Blocks http://www.codeblocks.org/
lol. It parses the sources so you can instantly find where anything is defined.
LesNewell: etags/emacs and ctags/vi do that too. I use one or the other, I won't say which in public :-)
that's just asking for trouble
wonder if I could sneak g7/g8 into "Distance Mode" without it being too obvious that I was not finding a good place to put them: http://www.linuxcnc.org/docs/devel/html/gcode.html
I suppose it is as good a place as any
EMC: 03cradek 07TRUNK * 10emc2/docs/html/gcode.html: diameter mode
wonder what other fiddly stuff we have to fix
cradek: a test of diameter mode wouldn't hurt
LesNewell: I think I thought of a bug: g8 / ... / g7 g76 i... j... k...
you scale X in the convert_diameter_mode but I think that's not good enough for this case
(uh, no, I didn't test it)
Aw hell. Yes that would break.
Of course in practise no-one in their right mind would do that...
it could get rather messy fixing it.
nah, you've got the block right there, just see if it's a g76
maybe it's if (block->motion_to_be == G_76)
trying that fix...
Thanks. I was just about to look into it mayself.
EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix g8 / ... / g7 g76 i... j... k...
ok, so the discussion about M19 makes me think we should have a spec, maybe on that wiki page with "things to do
a spec for what?
in the interp/motion controller
not the HAL to get it done (which will be the hard part in most cases)
void ORIENT_SPINDLE(double orientation, CANON_DIRECTION direction)
/*! odo FIXME-- unimplemented */
add M19 (or some other code) to set orientation mode
there's a bunch of canons
calling one from the interp is easy
add pins for spindle-angle and spindle-mode
and that's about it, isn't it
handling changes between spindle-run/orient/C-axis is hard
(yes I think C-axis might be part of the same project)
oh right - also add SPINDLE_ORIENT_AXIS to ini file and any structs it needs to be in
unless you use S for orient (which can also eliminate the orient pin)
err, angle pin