Back
[02:13:35] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 1824ef0 06linuxcnc 10src/emc/motion/motion_debug.h motion: motion_debug.h needs to include motion.h * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1824ef0
[05:20:51] <arrowbook> hi, how to print the value of a variable which is double type in the kernel layer?
[06:03:04] <arrowbook> or there's a special way in LinuxCNC?
[06:47:10] <jthornton> better to ask on #linuxcnc
[06:47:35] <KGB-linuxcnc> 03John Thornton 052.7 a891c83 06linuxcnc 10docs/src/getting-started/getting-linuxcnc.txt Docs: fix display of terminal commands in pdf viewers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a891c83
[06:53:02] <linuxcnc-build> build #125 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/125 blamelist: John Thornton <bjt128@gmail.com>
[06:53:52] <jthornton> crumb
[07:16:37] <jepler> arrowbook: iirc we guarantee that rtapi_snprintf (which is used by rtapi_print_msg) can format double-precision values in hex representation like printf %A. This is mentioned briefly in the stub manpage rtapi_snprintf.
[07:16:53] <jepler> for example, I added this in the EXTRA_SETUP of an existing comp:
[07:16:53] <jepler> +rtapi_print_msg(RTAPI_MSG_ERR, "pi is close to %A\n", 3.14159);
[07:17:00] <jepler> and I got this in dmesg:
[07:17:00] <jepler> [169911.572702] pi is close to 0x1.921F9F01B866EP+1
[07:17:36] <jepler> you can convert this back to decimal floating point in multiple ways, such as using the commandline printf program
[07:17:39] <jepler> $ printf '%f\n' 0x1.921F9F01B866EP+1
[07:17:41] <jepler> 3.141590
[07:20:11] <jepler> printing floating point numbers in decimal has traditionally not been supported because doing so accurately for all input values means using an algorithm that can be very slow.
http://dl.acm.org/citation.cfm?id=93559
[07:22:01] <jepler> .. but formatting IEEE flotaing-point numbers as hex is fast and accurate, just difficult to read
[07:25:24] <jepler> this could all be better documented. I will be happy to review any patches to improve documentation. However, unless an algorithm for printing FP numbers is both correct and has a consistent runtime for all inputs, I would be very reluctant to add decimal printing of FP numbers in realtime code.
[07:26:13] <linuxcnc-build> build #3511 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3511 blamelist: John Thornton <bjt128@gmail.com>
[07:26:28] <jepler> .. for instance this 2004 paper describes an algorithm that is fast and right for 99.5% of numbers, but for 0.5% of numbers the printing is either wrong or must be done by a much slower algorithm
https://333341ac-a-698ebdfa-s-sites.googlegroups.com/a/loitsch.com/florian/publications/dtoa-pldi2010.pdf?attachauth=ANoY7cqgHqy5FTu1xtrC6juqExN6XwwgirfQ8WE5Dvkec_uhXCo-zf-F10wjvn209YorUbOx0LZxr4Zdr8jnKFTo_
[07:26:35] <jepler> 4_cX1GaVS1IpTHmPk00GWHOHJQjnZV1G_8w84GulZDYX7n6g64M1GUM1rF8eu-DW5ZK2Rtkyi0acE5W7KGiRUKOvDousnFmLfpxbutwtIvioahMcwS2uQ0TobgFbH3QoDxTpDxtgvsjQpvhpES96-THGSQIy74%3D&attredirects=0
[07:29:43] <arrowbook> thank you, jepler, the usual 'printk' is also not useful？
[07:38:19] <arrowbook> then how do you check the FP numbers when debuging?
[07:41:21] <jepler> I have not developed FP-using code on RTAI realtime in a very long time
[07:42:04] <jepler> for things that are not hardware drivers, I develop using uspace realtime. there, I can attach a debugger or use traditional libc printf but of course I lose realtime performance when I do either of those
[07:42:45] <jepler> otherwise, I will create a diagnostic HAL pin and put the relevant FP number on it. then I can capture the values with halscope or another tool that runs in userspcae
[07:43:08] <jepler> debugging realtime code via dmesg prints is a last resort, and there I can use %A if I have to
[07:43:20] <jepler> afk
[08:03:22] <arrowbook> i can also get the hex numbers, but do you know that is there any tool to convert it to decimal？
[08:05:29] <jepler> yup I said that earlier
[08:05:33] <jepler> 06:53:44 <jepler> you can convert this back to decimal floating point in multiple ways, such as using the commandline printf program
[08:05:37] <jepler> 06:53:45 <jepler> $ printf '%f\n' 0x1.921F9F01B866EP+1
[08:05:39] <jepler> 06:53:45 <jepler> 3.141590
[08:07:09] <arrowbook> o
[08:18:39] <arrowbook> thank you
[08:19:16] <jepler> you're welcome
[08:28:43] <jepler> cradek: is this supposed to be accepted? G3X0Y2R1P100 (R and P together)
[08:31:42] <jepler> .. I read the docs as implying otherwise
[08:37:15] <cradek> sure, it should be
[08:37:26] <cradek> docs link?
[09:28:14] <cradek> I scanned through
http://www.linuxcnc.org/docs/html/gcode/g-code.html#_g2_g3_arc_move and don't see where it implies it's not allowed
[09:42:00] <JT-Shop> I looked as well, it might not be super clear that you can use both R and P ie. no example using R and P
[09:53:08] <jepler> cradek: because the line specifying P says "offsets"
[09:53:45] <JT-Shop> I looked at that line with some question to the exact meaning
[09:53:49] <JT-Shop> I'll clear that up
[09:55:09] <jepler> I was wondering because specifying normal with pqr is one possibility that came to mind.
[09:55:50] <jepler> for fully general arcs
[09:56:00] <cradek> oh! you mean the summary part in gray
[09:56:06] <cradek> I only read the text part
[09:56:33] <jepler> hah
[09:58:20] <jepler> hmm actually specifying all of ijk works, start center and end define a unique plane. you lose helical though.
[10:03:09] <seb_kuzminsky> :q
[10:03:10] <seb_kuzminsky> oops
[10:13:05] <cradek> jepler: it's an interesting problem and tempting to hack in because we know the lower layers can do it. but I know I should resist making features that will rarely be used, and are intricate and hard to test
[10:14:12] <cradek> (I think coordinate system rotation is an example of this)
[10:14:33] <cradek> does someone need it for something, or is it just a geektrap?
[10:18:12] <skunkworks> I would use it! (once)..
[10:27:27] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_5_axis 01f0408 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_XYZAB.ini 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py gmoccapy_5_axis -changed design * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=01f0408
[10:27:27] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_5_axis 9eee733 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_XYZCW.ini 10src/emc/usr_intf/gmoccapy/gmoccapy.py gmoccapy_5_axis - bug in lathe mode solved * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9eee733
[10:34:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/motion-logger c9d8aec 06linuxcnc 10src/Makefile 03src/emc/motion-logger/README 03src/emc/motion-logger/Submakefile 03src/emc/motion-logger/motion-logger.c add motion-logger, a debugging tool * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c9d8aec
[10:34:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/motion-logger 1b8655a 06linuxcnc 10(5 files) add a motion-logger test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1b8655a
[10:35:54] <seb_kuzminsky> there's a branch that implements the emcmot_command_t logging we talked about, it shows that 2.6 does ARC_FEED right, 2.7.0 gets it wrong, and the tip of 2.7 gets it more right (correct end point, but non-unit normal)
[10:36:33] <seb_kuzminsky> and happily it does not perturb any existing code, it only adds new code, so it's a reasonable candidate for the stable branches
[10:39:00] <cradek> awesome!
[10:40:26] <cradek> I see some of the messages don't print their parameters
[10:40:39] <cradek> we can fill those out later
[10:41:11] <seb_kuzminsky> exactly
[10:41:21] <seb_kuzminsky> i was bee-lining it for the known ARC_FEED issue
[10:41:58] <seb_kuzminsky> there's probably a better way to do the test too
[10:42:31] <seb_kuzminsky> it'd be nice if it ate a directory full of g-codes, each with its own expected emcmot_command list, and fed each in turn to Task
[10:43:06] <seb_kuzminsky> maybe poke motion-logger (with SIGUSR or through HAL) to have it pinch off the log file
[10:44:17] <cradek> I like that this makes the canon level testable
[10:44:28] <cradek> that's a really big empty spot right now
[11:19:08] <jepler> cradek: the person who brought up the arc normal question said something about spherical arcs which I assume means general arcs
[11:21:17] <ssi> spherical arcs, maybe that's an arc in a plane that's not orthogonal to the axes?
[11:21:41] <jepler> ssi: right, I think we are all talking about the same concept
[11:22:33] <ssi> I never thought about how you'd program an arc like that... I've only worked with arcs on one of the orthogonal planes
[11:23:53] <jepler> in linuxcnc, you can't.
[11:24:03] <ssi> yeah that's what I figured
[11:25:51] <jepler> looks like some controls use "spherical interpolation" to refer to this, but I haven't found any sample of gcode
[11:26:25] <jepler> e.g., "Complete motion capabilities include: point-to-point; linear, circular, helical and spherical interpolation"
http://www.aerotech.com/product-catalog/motion-controllers/a3200.aspx
[11:27:46] <cradek> I'd be a little sad if we bothered to do it and didn't allow helixes
[11:28:25] <ssi> cradek: helixes along an arbitrary axis?
[11:28:51] <cradek> yeah
[11:29:31] <cradek> in our implementation so far, arcs are just a helix that happens to be flat
[11:29:38] <ssi> ah right
[11:30:14] <archivist> I would just use a rotary or two to make a sphere on a mill
[11:35:57] <linuxcnc-build> build #654 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/654 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:36:50] <jepler> yeah, if you have 5 axis, you can put the work in the right orientation and use UVW arcs
[11:37:05] <jepler> or put the tool in the right place and move the work using rotary moves
[11:38:07] <cradek> don't overestimate the availability of UVW arcs
[11:38:43] <jepler> you mean because of the kinematics complications?
[11:41:45] <cradek> I mean we don't have them
[11:42:09] <cradek> currently g17.1 etc planes let you do canned cycles but not arcs
[11:42:11] <jepler> oh darn
[11:44:09] <jepler> I think that old-XYZ IJK new-XYZ are enough constraints to describe general helical arcs with any normal, but I doubt there's a way a human would understand to write such an arc
[11:44:58] <jepler> if you have a center and one point on a circle in 3D, then you're left with a sphere on which the other endpoint of the arc can lie
[11:45:24] <jepler> so you only need to use up two coordinates of information from new-XYZ to determine the plane
[11:45:37] <jepler> so you're left with another unit of information to determine the helicity
[11:45:51] <archivist> can you even reach the under a hemisphere on a 3 axis mill
[11:46:03] <archivist> underside
[11:46:39] <cradek> jepler: I can't picture it
[11:46:39] <jepler> doesn't seem like
[11:46:48] <archivist> here you need xz and a rotary, a lathe
[11:47:25] <archivist> then it is trivial to reach most of a sphere
[11:54:49] <jepler> hmm, zero gee milling of unsupported material
[11:57:41] <archivist> magnetic holder ?
[12:03:31] <jepler> cradek: since you were asking, here's how the typical velocity profile looks with my laser gcode:
http://emergent.unpythonic.net/files/sandbox/laser-scanning.png
[12:03:37] <jepler> scans are taking place in "Y"
[12:03:54] <jepler> here's the first 1000 lines of gcode:
http://emergent.unpythonic.net/files/sandbox/cat-first1klines.ngc
[12:04:38] <linuxcnc-build> build #2707 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2707 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[12:04:49] <seb_kuzminsky> wow
[12:05:12] <jepler> what looks like a Y glitch in the first third is not. it optimizes each scan by only going to the last burned pixel. in this case the next scan starts at a higher Y than the last one ended, so it stepped over in Z and then went further in Y before reversing to do the next scan in descending Y
[12:05:53] <jepler> in this machine the accel is high enough that I don't notice any difference in burn in the first/last pixel in a scan (that graph is with sim/axis's default acceleration)
[12:06:09] <cradek> I sorta can't believe that all works
[12:06:19] <ssi> jepler: is it a laser scanner for measurement/volume scanning?
[12:06:24] <cradek> the result is really very good
[12:06:41] <jepler> ssi: no, it's a very cheap laser "engraver"
[12:06:47] <ssi> ah ok, raster engraving
[12:06:53] <jepler> right
[12:06:56] <jepler> http://www.dxsoul.com/product/neje-300mw-mini-diy-laser-engraving-machine-picture-logo-cnc-laser-printer-transparent-901379598
[12:07:01] <ssi> I had that setup on mine but I cultid it
[12:07:02] <ssi> culted
[12:07:13] <ssi> whoa
[12:07:16] <jepler> not sure what you mean by "culted"
[12:07:21] <ssi> cargo-culted
[12:07:23] <jepler> ah
[12:07:25] <ssi> ie cut and pasted from someone else :)
[12:07:26] <jepler> well this is not a great device
[12:07:41] <jepler> its linear motion parts including stepper motors are from disassembled floppy drives
[12:07:42] <cradek> haha ROSH
[12:07:57] <jepler> the laser and table are each attached to their slides with hot glue
[12:08:01] <ssi> hah
[12:08:14] <jepler> and the travel is 36x36mm
[12:08:31] <ssi> http://www.dxsoul.com/product/neje-500mw-desktop-violet-laser-engraving-machine-printer-diy-kit-silver-transparent-901380428#.Vhfu9LQrr8s
[12:08:34] <ssi> wonder if that's much better
[12:09:20] <jepler> I talked to someone at the local hackspace who was happy with his ~$400 laser cutter which seems to be in a whole different class than these devices
[12:09:49] <cradek> same ROSH label on that one
[12:09:54] <ssi> as soon as I get the money I'm waiting on I'm going to start working on another laser
[12:09:55] <jepler> www.amazon.com/CNCShop-Engraving-Machine-Engraver-Woodworking/dp/B012F0LKHE
[12:10:03] <ssi> cradek: hilarious
[12:10:22] <jepler> apparently pretty easy to retrofit, though there is one odd ribbon connector
[12:10:26] <ssi> jepler: wow that's really pretty cheap
[12:15:02] <linuxcnc-build> build #3504 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3504 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[12:22:30] <jepler> this is the best info I found related to retrofitting the chinese 40W laser cutter, it includes a board design to convert from screw terminals to the connectors used by the original usb-interfaced control
http://forum.planet-cnc.com/viewtopic.php?f=11&t=127
[12:23:47] <jepler> .. add a 7i92 and two axes worth of stepper drivers and you should have a nice linuxcnc compatible laser over ethernet
[12:50:59] <linuxcnc-build> build #1323 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1323 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[13:06:38] <linuxcnc-build> build #3513 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3513 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:46:38] <jepler> interesting, I just noticed that laser engraver that ssi linked to is a gantry. they solve the gantry problem by hooking both motors up to a single stepper driver.
[14:56:49] <jepler> they seem to have a boost voltage regulator for the laser, so it can be run at 12V instead of 5V. One source I've read says that operating the laser diode at a higher voltage but at a lower duty cycle is preferable in terms of heat dissipation
[15:17:30] <KimK_laptop> jepler: Hi, I looked at your laser photos of last night, interesting. I'm guessing all the samples were wood or masonite? (All materials that darken with heat?) If so, have you tried any samples that lighten with heat, maybe black anodized aluminum? I wonder if that would lend itself to artwork in your machine?
[15:18:48] <KimK_laptop> Not sure if your machine can get black anodized aluminum "started", but interesting if it could.
[15:33:16] <jepler> KimK_laptop: no, I haven't. I've tried wood, cardboard, and paper
[15:36:43] <skunksleep> Would it be faster to engrave at a 45deg angle? (Feed would be sqr(x^2+y^2) or does it work out the same
[15:37:32] <skunksleep> If the machine was maxed out..
[15:39:27] <jepler> skunksleep: in this image, the bottom middle swatch is a gradient produced by varying speed, I think from 800mm/s at left to 300mm/s at right
[15:39:41] <jepler> so I can go fast enough on one axis that the laser doesn't succeed in burning the wood reliably
[15:40:22] <jepler> https://goo.gl/photos/dFH4AYBZTJkwAXw9A
[15:54:49] <KGB-linuxcnc> 03John Thornton 052.7 43751b4 06linuxcnc 10docs/src/gcode/g-code.txt Docs: clear up g2/3 with r/p. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=43751b4
[15:57:18] <skunksleep> jepler: neat
[19:04:00] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/motion-logger b8c2534 06linuxcnc 10src/emc/motion-logger/motion-logger.c motion-logger: lots of dead code removed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8c2534
[19:04:00] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/motion-logger b1d3071 06linuxcnc 10src/emc/motion-logger/motion-logger.c motion-logger: add copyright * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b1d3071
[19:04:00] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/motion-logger b815516 06linuxcnc 10src/emc/motion-logger/motion-logger.c motion-logger: continue on unknown emcmot commands instead of exiting * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b815516
[19:29:53] <linuxcnc-build> build #1325 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1325 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:31:15] <seb_kuzminsky> i bet that's a race between motion-logger starting up and linuxcncsvr starting up
[19:31:21] * seb_kuzminsky fires up a crappy rtai vm
[19:31:52] <seb_kuzminsky> oh yeah, libvirt doesnt run on this machine since my partial upgrade from backports
[19:32:12] <linuxcnc-build> build #2709 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2709 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:32:24] <seb_kuzminsky> crap
[19:35:03] <seb_kuzminsky> Oct 9 18:10:36 steel kernel: [1326065.764304] traps: libvirtd[3129] general protection ip:7fb6fa7f7939 sp:7fff57909310 error:0 in libc-2.13.so[7fb6fa77d000+181000]
[19:37:43] <seb_kuzminsky> people hate the yaks, but i think they're a necessary emergent feature of the kind of awesome open systems we play with, and so i try to embrace them
[19:45:11] <linuxcnc-build> build #3506 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3506 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:45:11] <linuxcnc-build> build #3515 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3515 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:59:33] <cmorley> I just rebuilt master after Jeff's change to stepconf's make file to look for Id conflics. I think it's too much. It's complaining of a ton of conflicts that don't matter. Asking devs to have a unique name for every object is un necessary and it creates a lot of noise when making. Opinions?
[21:02:06] <jepler> cmorley: If you prefer the checks are just not done, that's fine. There's also a commented-out block in scripts/checkglade that proposes a whitelist by widget class.
[21:04:10] <jepler> I agree that 1000 warnings that leave you unsure whether there are any real problems is essentially as bad a situation as 0 warnings that leave you unsure whether there are any real problems
[21:04:33] <jepler> what you want is 1 message which tells you that there is a real problem, but I did not achieve that ideal
[21:04:40] <cmorley> Yes your change before to use multifilebuilder reports duplicate ids and I think that was sufficient
[21:05:09] <jepler> would you like me to just remove checkglade then?
[21:05:24] <cmorley> I agree GLADE made it a bit of a pain!
[21:05:47] <cmorley> I think that would be better yes
[21:05:49] <jepler> alright
[21:06:22] <jepler> sorry for the trouble. In retrospect I shouldn't have pushed it without asking you.
[21:07:06] <cmorley> Oh I agree with what you were trying to do... just it didn't work out... just freaked me out when I first saw it :)
[21:08:25] <jepler> I forgot that the multifilebuilder would signal an error at runtime about this instead of invisibly doing a wrong thing
[21:08:40] <cmorley> Yes that was a great improvement
[21:08:43] <jepler> the branch was on a computer I was about to reinstall and when I saw it I thought: oh my gosh, I did this a year ago for chris and I never pushed it!
[21:08:47] <jepler> without investigating too much
[21:08:56] <cmorley> lol all good
[21:09:20] <cmorley> thanks Jeff
[21:09:23] <jepler> sure thing
[21:10:09] <KGB-linuxcnc> 03Jeff Epler 05master 6cd3173 06linuxcnc 10src/emc/usr_intf/stepconf/Submakefile Revert "stepconf: non-fatal check for duplicate IDs" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6cd3173
[21:10:09] <KGB-linuxcnc> 03Jeff Epler 05master e205f64 06linuxcnc 04scripts/checkglade Revert "checkglade: a new script to check glade files" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e205f64
[21:19:07] <KGB-linuxcnc> 03Jeff Epler 052.7 554fa0f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: don't just crash when packets get lost * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=554fa0f
[21:22:22] <jepler> oh of course it was just drawing big circles when I tried to "G0" in a square
[21:22:29] <jepler> I didn't set my tolerance
[23:58:12] <KGB-linuxcnc> 03Chris Morley 05master 6299160 06linuxcnc 10src/emc/usr_intf/stepconf/build_INI.py 10src/emc/usr_intf/stepconf/options.glade 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/stepconf.py stepconf -add basic Gmoccapy screen option * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6299160
