Back
[00:59:01] <linuxcnc-build> build #42 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/42 blamelist: John Morris <john@zultron.com>
[00:59:18] <linuxcnc-build> build #42 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/42 blamelist: John Morris <john@zultron.com>
[01:21:01] <linuxcnc-build> build #43 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/43 blamelist: John Morris <john@zultron.com>
[01:52:54] <linuxcnc-build> build #1372 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1372 blamelist: John Morris <john@zultron.com>
[01:54:08] <zultron> (question about package-sim-hardy-source builder answered)
[02:42:40] <KGB-linuxcnc> 03Chris Morley 05master 086e37c 06linuxcnc 10lib/python/gladevcp/hal_python.xml gladevcp -rename action widgets from EMC to VCP * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=086e37c
[02:42:40] <KGB-linuxcnc> 03Chris Morley 05master 5cf0f9e 06linuxcnc 10lib/python/gladevcp/hal_python.xml 03lib/python/gladevcp/widget-gladevcp-combi_dro.png 03lib/python/gladevcp/widget-gladevcp-icon_filechooser.png 03lib/python/gladevcp/widget-gladevcp-jogwheel.png gladevcp -add icons, adjust xml file to suit * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5cf0f9e
[04:15:10] <linuxcnc-build> build #1395 of docs is complete: Failure [4failed compile rsync-docs-to-www.linuxcnc.org] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/docs/builds/1395 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[04:15:12] <linuxcnc-build> build #1771 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1771 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[08:38:57] <memleak> when you install linuxcnc to /usr there isn't a sudo make uninstall option right?
[08:39:42] <memleak> let's say if you built master from source and watch to switch to v2.5_branch but you installed to /usr what do you think is the best way to do this?
[08:40:10] <memleak> s/watch/want/
[09:13:32] <cradek> memleak: get a time machine, and use the package manager instead
[09:14:12] <cradek> memleak: it is a sorry mistake for every program to make its own terrible package management with make install/uninstall, and we don't do it
[09:16:47] <cradek> but to answer your question: go around and carefully clean it up manually, and then never do that again
[09:23:28] <KGB-linuxcnc> 03Michael Haberler 05unified-build-candidate-3 3555609 06linuxcnc 10src/rtapi/rtapi_msgd.c msgd: use synchronous signal delivery with signalfd() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3555609
[09:29:13] <memleak> why is it a mistake? it's actually really handy for times like these cradek :P
[09:30:20] <zultron> 'make uninstall', never heard of that before. I like it.
[09:30:57] <cradek> noooo
[09:31:18] <cradek> package management! every system has it already!
[09:31:53] <zultron> I suppose since you're not using a package manager, that an automated system reinstall is also out of the question? That would get things squeaky clean.
[09:32:44] <zultron> I'd love to hear an example of a project that has an 'uninstall' target.
[09:33:20] <zultron> How about 'unmake install'?
[09:34:01] <memleak> a lot of things have a make uninstall ...
[09:34:23] <zultron> Tease.
[09:34:28] <cradek> haha
[09:34:55] <memleak> RTAI uses it actually
[09:35:15] <memleak> not everyone wants to use a package manager though
[09:35:16] <zultron> Ooh! I'll check that out.
[09:37:49] <cradek> rtai is an unusual project, where the authors still expect everyone to run fairly custom builds they build themselves, and it's pretty hard to build and package in a way that's useful for everyone
[09:38:41] <cradek> we've worked hard to make linuxcnc not that way [hal, and later, remap]
[09:39:11] <mozmck> I've seen 'make uninstall' so often that I thought it was near universal.
[09:39:53] <mozmck> I always use a package though if I can find one.
[09:40:46] <zultron> Wow, it really does!
[09:44:39] <linuxcnc-build> build #1771 of lucid-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1771 blamelist: Michael Haberler <git@mah.priv.at>
[09:45:11] <skunkworks__> I think rtnet also has make install / make uninstall
[09:46:14] <zultron> I don't think I've done a 'make install' outside of a package build or test directory in 20 years (except when I worked at AMD, where they do things like that).
[09:46:16] <skunkworks__> mozmck, did you see
http://imagebin.org/293135
[09:47:15] <cradek> zultron: I did spend an afternoon reading those docs and trying to get rsyslog to give only our one log file world-readable permissions and no rate limiting - specifically by adding a file in /etc/rsyslog.d - and I concluded it is not possible. If you can make it work, I'd love to hear it.
[09:47:53] <mozmck> skunkworks__: no, I'm not quite sure what it means either though.
[09:48:08] <skunkworks__> http://imagebin.org/293134
[09:48:10] <cradek> zultron: I certainly intended to finish it by making syslog-or-file configurable
[09:48:19] <skunkworks__> can you guess which one is linuxcnc?
[09:48:20] <mozmck> did you see Art's email a few minutes ago?
[09:48:25] <skunkworks__> (came hardare)
[09:48:27] <skunkworks__> same
[09:48:34] <skunkworks__> mozmck, no -
[09:48:42] * skunkworks__ runs of to look
[09:48:47] <skunkworks__> jeeze
[09:48:48] <skunkworks__> off
[09:50:51] <cradek> zultron: those files in the .d directory are included in alphabetic order, and settings you make in them apply to later includes. The reset does not undo just the changes you made your file - it resets everything. The directory.d is not really usable unless you control all the files [same effect as if you had just the one traditional config file].
[09:53:17] <mozmck> FLTK (
http://www.fltk.org) has a 'make uninstall'
[10:11:09] <skunkworks__> Art is quite a nice guy.
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/143276
[10:12:42] <mozmck> Seems like - it's also interesting what he says about pulse timing stability.
[10:13:14] <skunkworks__> right - timing blips that small must not effect the motion most of the time.
[10:23:22] <linuxcnc-build> build #1772 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1772 blamelist: Michael Haberler <git@mah.priv.at>
[10:30:27] <KGB-linuxcnc> 03Dewey Garrett 05xhc-hb04 9fc5d1c 06linuxcnc 10(11 files in 2 dirs) xhc-hb04: support different stepsize_sequences * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9fc5d1c
[10:43:55] <skunkworks__> This is interesting...
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/143274
[10:44:21] <zultron> Hey cradek, That second directive referenced in the ticket would almost help, but not quite.
[10:45:49] <zultron> My snarky comment about reading the manuals was because that directive wasn't addressed in the discussion, and I was getting the feeling that the problem was as much about the battle as the presenting issue.
[10:46:10] <cradek> yeah, that reset doesn't help, unfortunately
[10:46:33] <cradek> they didn't implement the .d directory very well.
[10:46:48] <zultron> Anyway, you did say you'd finish it with the configuration directive, and I think the change is quite useful.
[10:47:04] <zultron> No, they didn't.
[10:47:45] <zultron> However, for now I do think that it's simple enough and good enough to pick a reasonable default.
[10:48:32] <cradek> mah's point about there being many syslog daemons to choose from is a good one, but on setups where everything runs on one machine (and they come with rsyslog by default) I think the whole set of syslog issues is unnecessary complication
[10:48:46] <zultron> The rsyslog linuxcnc.conf file we have could be improved by setting whatever we need, specifying the logfile, and then setting it back to the distro's default.
[10:48:51] <cradek> I don't understand what you mean in the last sentence about reasonable default
[10:49:11] <zultron> (Did that explain?)
[10:49:13] <cradek> oh I see
[10:49:17] <cradek> one minute
[10:50:15] <zultron> Yes, I agree with that.
[10:50:17] <zultron> brb
[10:50:51] <cradek> unfortunately the Reset resets to the rsyslog defaults, not the defaults set above in the rsyslog.conf file
[10:51:58] <cradek> in my wheezy machine, the include of the .d files is between setting permissions and their system rules like /var/log/messages
[10:52:31] <cradek> so I'm pretty sure there's no fixing it without rewriting rsyslog.conf and abandoning the .d
[10:52:32] <zultron> Right.
[10:53:06] <cradek> I'm shocked by how broken it is :-(
[10:53:42] <zultron> Well, hold on a sec. We're talking about a single config directive, $FileCreateMode or something (you have the ticket url in front of you?).
[10:54:21] <zultron> Is there anything stopping us from setting it, configuring the linuxcnc.log file, and then setting it back to a default?
[10:54:21] <cradek> $FileCreateMode affects all files from here on
[10:54:23] <cradek> http://sourceforge.net/p/emc/bugs/355/
[10:55:08] <cradek> oh set it back to what we know through external channels (our eyes) was the default in the rsyslog.conf file?
[10:55:19] <zultron> Right.
[10:56:23] <zultron> http://www.rsyslog.com/doc/omfile.html
[10:56:23] <cradek> maybe that would only break what people changed manually
[10:56:47] <zultron> Right. And those who change stuff manually can change stuff back manually.
[10:56:55] <cradek> our versions don't have that omfile ability - I tried it
[10:57:24] <zultron> Oh, isn't that the documentation for the $FileCreateMode directive?
[10:57:45] <cradek> no, omfile is different
[10:57:52] <cradek> the global one with $ is the only thing we have in our versions
[10:58:37] <zultron> http://www.rsyslog.com/doc/rsyslog_conf_global.html
[10:59:03] <zultron> The link for the directive with the $ points to that link
[10:59:31] <zultron> I don't see any other documentation about that directive....
[10:59:33] <cradek> I agree but I think that's a mistake, or otherwise these docs are just newer than our versions
[11:00:40] <cradek> http://rsyslog-5-8-6-doc.neocities.org/rsconf1_filecreatemode.html
[11:00:55] <zultron> Ok. But do you think the semantics of the param have changed significantly from the older version?
[11:01:06] <zultron> Oh, good, thanks.
[11:02:19] <zultron> Aha, so yes, it's ugly but possible to set it for the linuxcnc.log file, then set it to the distro's default after that (which may be clobbering someone's manual configuration).
[11:02:23] <cradek> yes they created a totally new incompatible syntax, action(type="..." File="..." ...), probably because the old one is so broken
[11:04:12] <zultron> So how about we go with that "solution" (disgusting as it is) until you've finished out your new feature?
[11:04:26] <cradek> now trying to find whether rate limiting affects all files or only the later-specified ones
[11:04:38] <cradek> I mean, the rate limiting $directives
[11:05:06] <zultron> Oh yeah, that was the original issue. That's why $FileCreateMode didn't seem to ring a bell...
[11:07:07] <zultron> So this leads to another issue: since rsyslogd configuration can be quite different between versions, and there's no guarantee that 'make install' is even being run on a system with rsyslogd, is it even the job of 'make install' to install that file?
[11:07:33] <zultron> That seems more like the duty of the package to me.
[11:08:51] <cradek> if we use must use a syslog setup that depends on special syslog configuration, typically our package would provide the .d file and require the syslog choice/version we know how to configure with our .d
[11:09:30] <cradek> not sure if that answers your question
[11:09:42] <zultron> Yes, the package should include the .d file.
[11:10:01] <zultron> But is it the duty of 'make install' to install the .d file?
[11:10:06] <cradek> but only if it depends on the syslog that the .d file makes sense for
[11:10:29] <zultron> Say someone is running 'make install' with $prefix = /usr on some random distro.
[11:10:52] <cradek> in my mind, make install is only a step in building a package. that person is making a mistake and they get to keep both broken pieces if they do that.
[11:11:13] <cradek> we obviously can't get "make install" right for some random distro
[11:11:24] <zultron> I do too, mostly.
[11:12:00] <zultron> But it's still something people do sometimes, and anyway, it's something that the package build system does.
[11:12:53] <zultron> Most packages I've worked with, the package itself installs things like init scripts or other special files like this.
[11:13:04] <cradek> I don't know what make install should do when not building a package, and I mostly don't care, because I really think it's a mistake and I know we can't get it right
[11:13:29] <cradek> yes I absolutely agree that it's proper to have the .d/ file in the package
[11:13:49] <cradek> (if the package depends on the package that consumes the .d/ file)
[11:14:03] <zultron> Yes. Unless the package is for a system where rsyslogd is not the default.
[11:14:08] <cradek> I think we are saying the same things
[11:14:16] <cradek> yep
[11:14:19] <zultron> Not exactly.
[11:14:30] <zultron> On a system where rsyslogd is not the default, the package shouldn't include that file.
[11:14:42] <cradek> I agree with you
[11:14:59] <cradek> the packages might make different smart/default choices for logging
[11:15:02] <zultron> The question I'm asking is, maybe that file should not be installed by src/Makefile at all.
[11:15:17] <zultron> It should be installed by the package instead.
[11:15:22] <zultron> (Am I making sense?)
[11:15:47] <cradek> oh I understand what you're saying
[11:16:36] <cradek> (1) "make install" won't do anything loggingwise; (2) the package will do it, and because of (1) the .d/ file has to get "installed" into the package using some method that's not make-install
[11:16:52] <zultron> Yeah. The config file should still be in the distribution as an example, sometimes in a 'contrib' directory.
[11:17:11] <zultron> Yes, that's it, exactly.
[11:17:40] <cradek> yep I think that's all perfectly sane
[11:17:52] <cradek> we have debian/extras for some other stuff like this
[11:18:14] <zultron> Ok.
[11:18:57] <zultron> Many projects I work with put this kind of stuff into a '/contrib' directory. Init files, RPM specfiles, sample crontabs, etc.
[11:19:24] <cradek> package builders will have to choose and make a logging set up work -- using knowledge about what's sane for the system the package will be used on
[11:19:25] <zultron> Then the package materials install it from the package scripts.
[11:19:32] <zultron> Right.
[11:19:57] <zultron> Packaging systems know a lot more about the distro than the usual Makefile.
[11:20:22] <cradek> for ubuntu that'll probably be a file (if I get my patch done) - for beagle that'll probably be syslog to another host over udp or whatever it is nowadays
[11:20:41] <zultron> Could be.
[11:21:23] <zultron> Because of the rsyslogd ugliness, I'd lean toward logging to a file by default in the package.
[11:21:30] <cradek> thanks for chatting about it, I think the way forward is clear
[11:21:42] <cradek> yeah I am definitely on that side of the fence too
[11:22:26] <zultron> Yeah, thank you. Seems a bit close to the Realm of Pedantic, but I find that's what packaging is all about. :P
[11:22:44] <cradek> likewise, for these embedded-like systems syslog is probably the clear winner - who knows if they even have much writable local filesystem
[11:22:55] <cradek> a remote syslog setup, I mean
[11:23:32] <zultron> Yep. That's what we already do for appliances in enterprise environments.
[11:23:53] <cradek> nah it's not pedantry at all
[11:24:09] <zultron> logger[mah], a bookmark for the ticket?
[11:24:09] <logger[mah]> zultron: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-02-14.html
[11:27:47] <zultron> cradek, did you get an answer about whether rate limiting can be set/reset in the same way as $FileCreateMode?
[11:30:59] <cradek> no I haven't found that
[11:31:27] <zultron> np, I'll take a look later
[11:31:40] <cradek> http://www.l3jane.net/doc/server/rsyslog/manual.html
[11:31:49] <cradek> this is docs for 5.8.11 which is the version I get on wheezy
[11:32:04] <cradek> it doesn't show those $SystemLogRate directives at all
[11:38:20] <zultron> Thanks, noted in the ticket
[11:39:00] <zultron> Agh, I wasn't logged in, and it erased everything I typed. Thanks, sf. :P
[11:40:52] <cradek> their tracker is really poor
[12:39:55] <micges> cradek: hi
[12:40:28] <micges> cradek: will there be 2.5.4 release?
[12:53:26] <cradek> micges: yes definitely. are you waiting on something important in v2.5_branch?
[12:55:28] <micges> I need to fix hm2 encoder error reporting I've introduced
[12:56:28] <micges> and I'm wondering if it will go in 2.5 or master
[12:56:33] <cradek> is the error in 2.5.3?
[12:57:14] <micges> yes
[12:58:07] <cradek> do you have a patch already?
[12:58:16] <cradek> if it's broken in 2.5.3 you should fix it on v2.5_branch
[12:59:52] <micges> cradek: working on patch atm, thanks for info
[13:00:02] <cradek> ok, welcome
[13:10:18] <cradek> 64571 git_daemon 3 103 0 211M 134M CPU0 0 7:07 200.00% git
[13:10:26] <cradek> wonder what git keeps doing that takes many minutes of cpu time
[13:19:57] <skunkworks__> about 30 minutes ago - I pulled master and it tool a long time to remotely compress...
[13:23:02] <cradek> done now, whatever it was. maybe it was the repack that happens once in a while.
[13:36:34] <skunkworks__> odd question...
[13:36:36] <skunkworks__> http://pastebin.ca/2640571
[13:37:38] <skunkworks__> if I run that - increasing the tollerance - the path doesn't change.. (notice it is at 50mm...)
[13:37:50] <skunkworks__> http://pastebin.ca/2640571
[13:38:30] <skunkworks__> not matter what I do - the path doesn't get roundier...
[13:45:21] <cradek> http://timeguy.com/cradek-files/emc/wfm.png
[13:46:45] <cradek> 5, .5, .05 all give me what I expect
[13:48:43] <micges> skunkworks__: are you on master?
[13:48:45] <skunkworks__> wtf.
[13:49:03] <skunkworks__> yes - but it did the same for me in 2.5.3
[13:50:22] <micges> turn on all debuging and see if there is correct path setting logged into terminal when you run it
[13:50:48] <cradek> skunkworks__: I ran sim/axis/axis on v2.5_branch
[13:51:36] <skunkworks__> heh - you know what I bet it is... I had edited it on a windows machine...
[13:59:53] <skunkworks__> well - that is funky.. I pasteded it out of pastebin and it did the same thing.. (followed the path)
[14:00:11] <skunkworks__> my laptop running just master does what yours did..
[14:00:54] <cradek> I agree with turning on debug (TASK ISSUE) and seeing what it's doing differently
[14:02:50] <skunkworks__> how do you turn on debugging?
[14:02:51] <cradek> I put dos line endings in mine and the behavior didn't change
[14:03:09] <cradek> machine/set debug level, click task issue
[14:03:19] <cradek> then watch on stdout
[14:08:28] <skunkworks__> http://pastebin.ca/2640581
[14:13:43] <skunkworks__> my laptop - which seems correct
[14:13:44] <skunkworks__> http://pastebin.ca/2640583
[14:17:04] <skunkworks__> what is weird is all 3 do it (installed, master and the cricular blend)
[14:25:06] <skunkworks__> There is something funky with that file on that machine... I can run 3dchips with a high tollerance and it acts as expected.. This program - the path sometimes doesn't line up with programmed path.
[14:27:13] <cradek> how about you gzip the gcode and put it on the web, not using pastebin
[14:27:30] <cradek> I don't trust pastebin to transmit ascii weirdnesses
[14:33:15] <skunkworks__> cradek,
http://electronicsam.com/images/KandT/testing/kafa4.ngc.tar.gz
[14:34:18] <cradek> hm nope, still works for me, I get a triangle to the tip of the nipple
[14:34:59] <skunkworks__> well odd. Like I say - I can run 3dchips with a huge P and it acts as expected..
[14:35:51] <cradek> are you using a mill config or lathe config?
[14:40:25] <skunkworks__> mill
[14:40:38] <skunkworks__> sim axis
[14:40:48] <cradek> huh
[14:41:16] <cradek> anything weird in your offsets?
[14:41:37] <cradek> pastebin your var file?
[14:54:03] <skunkworks__> ah - the reason why it was off sometimes - no Y movement.
[14:54:16] <skunkworks__> but it still follows the path as if it is just G64
[14:54:45] <cradek> yeah, that's why I thought it might be lathe code
[14:58:59] <skunkworks__> I am still baffled as to why P doesn't work (for this program - it works for 3dchips)
[15:01:15] <skunkworks__> I even lowerd the number of N characters. (grasping at straws)
[15:02:05] <skunkworks__> it has to be something stupid.. I just don't know what. I am running master with a master sim axis config (unmolested) same deal
[15:06:52] <CaptHindsight> where should .bit, .pin and .xml files be in /lib/firmware v2.5.3? hostmot2 or hm2?
[15:11:26] <skunkworks__> anyone else running 10.04 that could try this file for grins?
[15:11:39] <skunkworks__> http://electronicsam.com/images/KandT/testing/kafa4.ngc.tar.gz
[15:15:12] <skunkworks__> bbl
[15:17:15] <micges> cradek: compressing object in git repo still takes abnormally long time
[15:25:04] <cradek> thanks
[15:25:17] <cradek> something is definitely being weird
[15:51:19] <KGB-linuxcnc> 03Dewey Garrett 05xhc-hb04 a829ef6 06linuxcnc 10src/hal/user_comps/xhc-hb04.cc xhc-hb04: ctx for libusb_handle_events_timeout() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a829ef6
[16:38:59] <memleak> which compression algorithm does git use?
[16:39:06] <memleak> lz4 would be awesome..
[16:39:23] * memleak keeps up to date with the latest of compression technologies
[17:58:26] <skunkworks> logger[mah]:
[17:58:26] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-02-14.html
[18:23:27] <micges> skunkworks: does your gcode works any better?
[18:30:30] <skunkworks> well - it works on my laptop
[18:30:35] <skunkworks> 12.04
[18:50:11] <skunkworks> I have no clue
[18:58:25] <micges> skunkworks: turn on all debuging (machine->debug) and pastebin output from terminal
[19:13:36] <skunkworks> I just ran that program on a 10.04 vm I have here 2.5.1 - it does the same thing
[19:13:44] <skunkworks> http://electronicsam.com/images/KandT/testing/kafa4.ngc.tar.gz
[19:14:19] <skunkworks> I probably wont be able to do debugging until later..
[19:14:53] <skunkworks> so - it seems to be either a 2.5.1,2.5.3 thing - or a 10.04 thing
[19:16:12] <skunkworks> that program should look something like this
http://timeguy.com/cradek-files/emc/wfm.png
[19:16:23] <skunkworks> but it is following the path as if it is running strait G64
[19:21:35] <micges> emm, here it's also following path like when g64
[19:22:35] <micges> but how it's possible that that program will run like cradek's if now there is only two vector lookahead?
[19:23:04] <micges> skunkworks: are you using inch or mm sim?
[19:39:07] <skunkworks> inch
[19:39:58] <skunkworks> cradeks is how my sim build on the laptop runs.. (which is the way it should)
[19:40:26] <skunkworks> if I take 3dchips on the 10.04 machine and set the tollerance high - it acts as expected..
[19:40:39] <skunkworks> so it is like there is something odd with that file.
[19:42:04] <skunkworks> the naive cam detector should just pretty much combine all of the lines together if the tollerance is set too high (like cradeks picture)
[19:47:42] <micges> this is my 3dchips:
http://imagebin.org/293445
[19:52:21] <skunkworks> yep - that is when you have the P tollerance set too high
[19:52:57] <skunkworks> the kafa4.ngc file doesn't act like that. It seems to always run like strait G64
[19:54:36] <micges> maybe becouse dimention is much smaller
[19:58:48] <skunkworks> no - I kept increasing the tollerance from .1mm nothing changes
[19:59:45] <micges> same behaviour here
[20:01:27] <skunkworks> odd
[20:56:07] <skunkworks> metric config does the same thing
[21:08:02] <skunkworks> http://pastebin.ca/2640651
[21:08:40] <skunkworks> 10.04 2.5.1 (acts the same on 2.5.3)
[21:13:47] <skunkworks> this is from some version of master on my machine 12.04 that works as expected
[21:13:49] <skunkworks> http://pastebin.ca/2640652
[21:14:57] <skunkworks> now - on the 10.04 hardware I was testing earlier - it did not matter if I was running 2.4.3 or master or the circular blending branch. They all didn't seem to apply the P tollerance.
[21:33:05] <skunkworks> and the kicker is - 3dchips.ngc runs as expected with a large P
[21:33:16] <skunkworks> on all systems
[21:49:01] <skunkworks> Heh - so. It is because it has a feedrate on every line.
[21:52:47] <skunkworks> I wonder what the deal is between 10.04 and 12.04... because - I ran installed and master on 10.04 and they all acted the same.
[21:53:12] <skunkworks> (so it isn't like it is fixed in master...)
