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