Back
[00:03:36] <linuxcnc-build> build #4446 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/4446 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>
[01:04:53] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #145: check_config confused by gantry config 02
https://github.com/LinuxCNC/linuxcnc/issues/145
[01:49:29] <linuxcnc-build> build #4461 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4461 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>
[02:13:30] <linuxcnc-build> build #4445 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4445 blamelist: John Morris <john@zultron.com>, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>, John Kasunich <jmkasunich@fastmail.fm>, Andrew
[02:13:30] <linuxcnc-build> Kyrychenko <amkyrychenko@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[02:17:19] <linuxcnc-build> build #1074 of 1500.rip-jessie-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/1074 blamelist: John Morris <john@zultron.com>, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>, John Kasunich <jmkasunich@fastmail.fm>, Andrew
[02:17:19] <linuxcnc-build> Kyrychenko <amkyrychenko@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[02:18:53] <linuxcnc-build> build #1074 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/1074 blamelist: John Morris <john@zultron.com>, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>, John Kasunich
[02:18:53] <linuxcnc-build> <jmkasunich@fastmail.fm>, Andrew Kyrychenko <amkyrychenko@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[02:18:56] <linuxcnc-build> build #3657 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/3657 blamelist: John Morris <john@zultron.com>, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>, John Kasunich <jmkasunich@fastmail.fm>,
[02:18:56] <linuxcnc-build> Andrew Kyrychenko <amkyrychenko@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[02:20:55] <linuxcnc-build> build #2606 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2606 blamelist: John Morris <john@zultron.com>, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>, John Kasunich <jmkasunich@fastmail.fm>, Andrew
[02:20:55] <linuxcnc-build> Kyrychenko <amkyrychenko@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[02:21:07] <linuxcnc-build> build #2119 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/2119 blamelist: John Morris <john@zultron.com>, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>, John Kasunich
[02:21:07] <linuxcnc-build> <jmkasunich@fastmail.fm>, Andrew Kyrychenko <amkyrychenko@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[02:23:23] <linuxcnc-build> build #2272 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/2272 blamelist: John Morris <john@zultron.com>, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>, John Kasunich <jmkasunich@fastmail.fm>, Andrew
[02:23:23] <linuxcnc-build> Kyrychenko <amkyrychenko@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[02:28:53] <linuxcnc-build> build #4462 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4462 blamelist: John Morris <john@zultron.com>, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>, John Kasunich <jmkasunich@fastmail.fm>, Andrew Kyrychenko <amkyrychenko@gmail.com>,
[02:28:53] <linuxcnc-build> Sebastian Kuzminsky <seb@highlab.com>
[03:35:19] <seb_kuzminsky> that's tests/limit3.1 failing in master
[04:01:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 59bb8d4 06linuxcnc 10src/emc/usr_intf/halui.cc halui: correctly report "mode.is_joint" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=59bb8d4
[04:18:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 60675cf 06linuxcnc 10src/emc/usr_intf/halui.cc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=60675cf
[05:36:03] <linuxcnc-build> build #566 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/566 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[09:11:59] <skunkworks_> mozmck, did you find anything more with the rounding issue?
[09:12:11] <mozmck> No, not yet.
[09:12:47] <skunkworks_> eh - just blame the customer. ;)
[09:12:55] <mozmck> It's pretty odd, but does seem to be a problem. It affected only a couple of corners out of several on a part, and it is quite intermittent.
[09:13:23] <mozmck> Yeah, but it's happened 3 or 4 times now I believe.
[09:14:06] <skunkworks_> the mach people would just tell you to raise the acceleration so you don't get as much rounding
[09:14:32] <skunkworks_> I hope we can find a formula for it.
[09:14:48] <mozmck> Yeah. The bad thing with this is that it didn't affect all of the corners.
[09:15:10] <skunkworks_> and isn't consistent (it sounds like)
[09:15:26] <mozmck> Yes, doesn't happen every time.
[09:16:12] <skunkworks_> could it be something like a realtime error causing a delay in position?
[09:16:47] <mozmck> No, it would get a following error if it was that bad. Let me see if I can post the picture the guy sent me.
[09:18:59] <mozmck> http://pasteboard.co/9KlD2sDWN.jpg
[09:20:14] <mozmck> Notice the torch in the lower corner - that radius it something like 1" or so
[09:20:44] <mozmck> is
[09:21:32] <skunkworks_> that is huge.
[09:22:06] <skunkworks_> is that the radius it would do with no tolerance setting? (on his machine)
[09:22:27] <mozmck> I'm not sure about that.
[09:23:09] <cradek> It seems really unlikely to happen randomly. I think there's probably a pattern of things he's doing, possibly related to aborting and restarting
[09:24:06] <cradek> did you say you have the gcode?
[09:24:30] <skunkworks_> I bet the gcode won't run in sim (lots of rempapping and such?)
[09:26:34] <mozmck> cradek: that was my thought, but from what he says I think it was all in one session (no restarting or anything) The parts are all in one file.
[09:27:34] <mozmck> No remapping, but a couple of custom subroutines. One for touchoff and one to update Z position after a cut from our THC.
[09:29:08] <mozmck> http://pastebin.com/rwNu5bES
[09:32:42] <cradek> do you happen to know which two lines formed that corner?
[09:33:38] <cradek> skunkworks_ is right that simulating this would be hard and maybe an invalid test
[09:36:04] <cradek> seems like the small corner-roundings are actually programmed arcs
[09:37:17] <mozmck> Yes, the small ones are, but the large arc he highlighted is not.
[09:37:18] <cradek> in each piece there are only two line-line corners
[09:38:09] <mozmck> I ran this file on hardware here and it looks fine in preview. The hardware is not actually connected to a machine though.
[09:39:09] <cradek> pretty positive you'd see this happen in backplot
[09:39:40] <mozmck> Yes, I would think so. I ran it three times and did not see anything like that.
[09:42:21] <cradek> it does look like it's one of the line-line corners
[09:42:47] <cradek> in my hacked up code, it's the two lines G1 Y6.515, X30.625
[09:43:14] <cradek> what linuxcnc version is it?
[09:45:01] <mozmck> 2.7.4 + my simple RFL patch (which I still need to merge in master btw!)
[09:45:42] <mozmck> He said it cut the first 2 parts fine and it made the radius on just two corners on the last 3
[09:46:00] <mozmck> So line 133/134
[09:47:07] <cradek> am I correct that doing simple-rfl from line 113 would definitely cause this?
[09:48:15] <mozmck> No, because I use the STARTUP* ini setting to set the tolerance as well.
[09:48:31] <mozmck> I did try that and it did not cause the radius.
[09:48:57] <cradek> are you set up with low accel too, so you would be sure to see it?
[09:49:59] <mozmck> Hmm, I'm not sure. I doubt his accel is low either - that simply doesn't work well for plasma and we have them set it decently high.
[09:50:01] <cradek> (oops I wasn't so my test is invalid)
[09:50:35] <mozmck> It is interesting that it does not happen on the corner just before that has a small radius built in.
[09:51:18] <cradek> sam and I both assumed it was low accel and default blend tolerances causing it
[09:52:17] <cradek> I ran it with accel 3ips2 and it gave the correct corner
[09:52:18] <mozmck> I can ask him his accel, but I'm pretty certain it will be 35 ips^2 or greater
[09:52:47] <skunkworks_> wow - really?
[09:52:49] <mozmck> I set tolerances at the top of the file, and also in the startup code.
[09:53:21] <mozmck> yep, the higher the accel the better for plasma cutting thin material. slow-downs cause dross and poor cuts.
[09:53:38] <mozmck> I think my machine is set to 50 ips2
[09:53:46] <skunkworks_> sure - but it should never have a radius that big then
[09:55:19] <cradek> I can get it to give that path, with low accel, large G64P, small G64Q
[09:55:24] <cradek> which is not surprising
[09:55:46] <cradek> well it's symmetrical - the other matching corner on the left also rounds
[09:56:07] <skunkworks_> that is the only square corner
[09:56:15] <cradek> there are two
[09:56:26] <skunkworks_> right - symetrical
[09:57:04] <cradek> http://timeguy.com/cradek-files/emc/rounds.png
[09:57:05] <mozmck> Yes, he said both of those corners had the radius on 3 parts
[09:57:11] <cradek> oh!
[09:57:15] <cradek> that's new information
[09:57:24] <mozmck> sorry, I thought I mentioned that.
[09:57:32] <cradek> you may have - I came in in the middle
[09:57:39] <mozmck> He didn't show it in the picture though.
[09:57:50] <mozmck> and I may not have mentioned it.
[09:58:09] <cradek> it's slightly less mysterious if it happens at every line-line corner sometimes
[09:58:18] <mozmck> I emailed him a few questions.
[09:58:23] <mozmck> Yes
[09:58:44] <mozmck> why would the other corner with a small radius not do it?
[09:58:46] <skunkworks_> ok - even with high accelleration and no tollerence - it creates the bigest blend circle it can
[09:58:46] <cradek> but during one single program invocation, having it turn on and off is very mysterious
[09:58:57] <skunkworks_> so accelleration is not part of the equation
[09:59:22] <mozmck> interesting. It would seem that the default should be the smallest blend circle it can do.
[09:59:31] <cradek> in that case the blend is between the line and tiny arc, so the blend is tiny
[09:59:51] <skunkworks_> no - G64 is go as fast as you can while touching every line segment
[10:00:14] <mozmck> And that is the startup default?
[10:00:23] <skunkworks_> yes
[10:00:48] <mozmck> so yes, that seems like a not-good default
[10:00:51] <cradek> skunkworks_: are you sure you still get big blends when accel is high? that would surprise me
[10:01:19] <skunkworks_> G64P0
[10:01:27] <mozmck> I can't imagine many people actually wanting to use a setting like that
[10:02:15] <jepler> I thought our docuentation section "g code best practices" said to put an explicit setting in the preamble of a part program, but it's not in the "example preamble"
[10:03:08] <mozmck> I do that for sure, but does anyone want or expect the default behavior?
[10:03:15] <cradek> well that's not the behavior I see
[10:03:30] <cradek> with reasonable accels and NO g64 spec, I get a reasonable path with reasonable blends
[10:03:35] <skunkworks> http://imgur.com/a/YCCT0
[10:03:52] <jepler> mozmck: which specific values of G64 P- Q- would you like to be the default for all users?
[10:03:52] <skunkworks> let me try that
[10:04:28] <jepler> the default is more or less a "they'll start putting an explicit setting after ruining just one^Wa dozen parts on the default"
[10:04:38] <cradek> no no no
[10:04:42] <mozmck> jepler: I don't know - G64 P<smallest radius possible at given accel> ? :-)
[10:04:43] <cradek> I get reasonable corners with no G64
[10:04:59] <cradek> the smallest blend radius possible is always 0
[10:05:40] <skunkworks> Hmm - with no G64 - I get the same large radiuses
[10:05:51] <skunkworks> wonder what my difference is
[10:06:11] <skunkworks> (restarting linuxcnc just to be sure)
[10:06:22] <jepler> are G64, G64P0, and power-on default all supposed to be the same?
[10:06:24] <cradek> hmm I set my accel to 333 and I get blends that look like maybe .05 inch radius
[10:06:37] <cradek> jepler: I don't know
[10:06:38] <skunkworks> I am at 30ipm
[10:06:46] <skunkworks> 30in/s^2
[10:07:01] <skunkworks> my max velocity is 500ipm
[10:07:11] <cradek> oh so your accel is super low
[10:07:23] <cradek> yes you will get huge blends by default
[10:07:27] <skunkworks> ok
[10:07:36] <cradek> that's not a reasonable setup
[10:07:58] <mozmck> 30 in/s^2 is super low?
[10:08:01] <cradek> oh wait, mixed units going on
[10:08:06] <skunkworks> jepler, yes that is how I understand it (g64, G64P0 is sthe same)
[10:08:16] <skunkworks> and is the default
[10:08:17] <cradek> 8ips 30ips^2
[10:08:28] <cradek> 1/4 second to accel, 1/4 second to decel
[10:08:38] <cradek> that's not crazy at all
[10:08:38] <cradek> sorry
[10:10:02] <cradek> argh, I don't know how any of this works anymore
[10:10:09] <skunkworks> heh
[10:10:12] <jepler> isn't 1/4 second to accel to 8ips = 4 inches to accel?
[10:10:38] <cradek> yes
[10:10:58] <cradek> you're thinking you might get 4 inch radius blends then?
[10:12:28] <cradek> my high-accel machines probably cover up any of these misbehaviors
[10:13:18] <skunkworks> ok - so here is part of what is happening I think. The new planner plans to the max feed rate.
[10:13:52] <skunkworks> if I lower the max feedrate for each axis - I get a smaller radius for the corner
[10:14:21] <jepler> .. because at any moment you could turn the FO slider to 999%
[10:14:29] <skunkworks> right
[10:14:49] <skunkworks> that is why it is more important with the new tp to set the tolerance..
[10:15:26] <mozmck> I don't understand that - if the max feedrate is higher, shouldn't the radius get smaller?
[10:16:07] <skunkworks> no - because you want to go as fast as you can = bigger radius with higher feed rate.
[10:16:14] <skunkworks> for a given accellerations
[10:16:39] <mozmck> ok, I think I see.
[10:17:53] <mozmck> So I need to find out for sure if he did a run-from-line or not. I'm not sure though how the tolerance setting could get lost once it was set in the startup code even if he did not run the file first to set it.
[10:18:19] <cradek> I think there are bugs about the startup code not always being run that seb has been working on
[10:18:29] <cradek> I don't know the details except it seems hairy
[10:18:53] <mozmck> Well, that could be - maybe it works randomly
[10:19:16] <cradek> but if it was during one particular gcode run like your guy reports, it can't be that
[10:19:34] <mozmck> It would be a lot better for me if I could set the default to be "follow the path exactly" instead of full speed ahead.
[10:20:08] <mozmck> I would think that most people would rather that for a default as well - and have to explicitly tell it to fudge for speed instead of the way it is currently
[10:22:13] <cradek> on the machines I have, which I guess are all fairly high accel, with correct vel and accel settings, I never mess with g64, I always use the defaults.
[10:22:29] <cradek> a plasma with high feed rates might be a different animal
[10:22:45] <jepler> cradek: have you used 2.7 much though?
[10:22:58] <jepler> as skunkworks was saying, the new TP may have shifted things around to make for bigger blends
[10:23:35] <cradek> ii linuxcnc 1:2.6.12
[10:23:36] <cradek> umm
[10:23:38] <cradek> guilty
[10:23:42] <skunkworks> with the K&T we have to be sure to set the tolerance now. otherwise it really cuts corners on normal cutting (which we really should have been doing)_
[10:23:51] <skunkworks> Yes - you will notice it.
[10:24:30] <mozmck> Yeah, feedrate for something like 14 guage steel is 225 ipm
[10:24:31] <cradek> then I don't like the default either
[10:24:54] <mozmck> My max feedrate on X and Y is set to 1000 ipm
[10:24:58] <skunkworks> tormach sets pathpilot to like P.005 or some such
[10:25:30] <cradek> my vmc gets up to 800ipm I think
[10:25:42] <cradek> but yeah, surely it's running 2.6
[10:26:50] <skunkworks> I think this was talked about before.. I don't know what the solution is
[10:27:02] <cradek> yeah
[10:27:22] <cradek> turning off blending isn't it
[10:27:58] <mozmck> Maybe an INI setting for the default tolerance?
[10:28:19] <skunkworks> you can do that now can't you?
[10:28:26] <seb_kuzminsky> don't we have that already?
[10:28:34] <cradek> if startup codes works we sure do
[10:28:35] <cradek> hi seb
[10:28:36] <mozmck> I don't know about that?
[10:28:50] <mozmck> Startup code if it works ;-)
[10:28:54] <cradek> right
[10:29:04] <seb_kuzminsky> http://linuxcnc.org/docs/2.7/html/config/ini-config.html#_traj_section
[10:29:28] <seb_kuzminsky> or am i misunderstanding which tolerance y'all are talking about?
[10:29:44] <cradek> seb_kuzminsky: g64p
[10:29:47] <seb_kuzminsky> ah
[10:29:59] * seb_kuzminsky sips coffee
[10:32:42] <seb_kuzminsky> i think the startup gcodes dont run, in 2.6 and 2.7
[10:33:05] <seb_kuzminsky> see tests/motion-logger/startup-gcode-abort, which is marked "skip" in our stable branches
[10:33:27] <seb_kuzminsky> it does run in master, but has other problems that i haven't gotten around to fixing yet
[10:33:28] <mozmck> The startup code seems to work at least some of the time
[10:33:37] <seb_kuzminsky> hmm
[10:33:49] <mozmck> I should test that some more though.
[10:37:43] <seb_kuzminsky> i'd love to get more info on that
[10:44:14] <mozmck> The guy reponded and said the first time he had it happen, there were 15 of those pieces in the file. He ran it on one sheet and all was fine. Added 3 rectangle cutouts to the top of the sheet, and cut again without stopping. When it finished, the first part was right, and other 14 had the radius on those two corners. Then he broke the file down to 5 parts, and ran it twice in a row without problems, then on the third run it did 2 parts correctly a
[10:46:18] <seb_kuzminsky> it's maybe possible that *some* startup-gcodes take effect and some dont
[10:46:28] <cradek> blurgh
[10:46:52] <seb_kuzminsky> the startup gcode gets run through interp, but i believe anything that interp puts on the interp_list gets discarded before being processed by task
[10:47:34] <seb_kuzminsky> possibly some startup-gcodes have effects at read-time, rather than interp_list-time? i'm not confident that this is *not* the case, but i also don't know that it *is* the case
[10:48:19] <seb_kuzminsky> (maybe clearer terminology would be "read-time" vs "issue-time", with "issue-time" meaning "when task pulls the NML off interp_list and issues it")
[10:59:43] <mozmck> So what it kinda sound like to me is that it lost the tolerance setting part way through the file and reverted to the default - does this sound right?
[11:02:25] <seb_kuzminsky> mmmaybe
[11:03:23] <mozmck> yeah, should have said "plausible" rather than "right"
[11:04:01] <seb_kuzminsky> it would be kind of cool if task kept a big ring buffer of all nml commands that flow through it in memory, say the past minute's worth, and if something goes wrong the user can tell task to write it to a file, for emailing along with the bug report
[11:04:09] <seb_kuzminsky> sort of a flight recorder
[11:04:22] <seb_kuzminsky> mozmck: yeah, sounds plausible, but hard to say
[11:04:36] <seb_kuzminsky> which version is this user running?
[11:05:01] <mozmck> ooh, yes! If you turn on all debugging doesn't it log all NML commands to the stdout?
[11:05:16] <mozmck> he's running 2.7.4 + my simple RFL patch
[11:05:23] <skunkworks_> I have done a lot of testing and can't say I have ever seen the tolerance get stomped on. yet.. :)
[11:06:04] <skunkworks_> I could see some weird interaction with subs though.
[11:06:14] <seb_kuzminsky> skunkworks_: i've done hardly any testing, and i've never seen it either ;-)
[11:06:29] <skunkworks_> :)
[11:06:57] <seb_kuzminsky> mozmck: yeah, plus a bunch of other stuff
[11:24:56] <CaptHindsight> would anyone get upset if the HAL manuals were to be rewritten?
[11:26:07] <seb_kuzminsky> i think everyone would be happy if the hal docs were better
[11:27:35] <CaptHindsight> I need it for my own reference anyway
[11:27:59] <cradek> absolutely it's great if someone makes pull requests for doc improvements
[11:38:24] <mozmck> pcw_home: pcw_mesa, are you around?
[11:39:54] <pcw_home> yeah
[11:40:36] <mozmck> mind if I pm you for a second?
[11:40:54] <pcw_home> s'ok
[13:34:10] <jepler> master branch totally doesn't build on debian jessie amd64 with just 1GB RAM, :-/
[13:34:25] <jepler> with a 1GB swapfile added, it looks like it will
[13:34:27] <jepler> -j1
[13:34:35] <cradek> wow
[13:37:13] <jepler> though maybe part of the problem's mine, I'm playing with several different things on this system and I may have underestimated how much memory they're using
[13:37:36] <jepler> "docker" running "guacamole" which in turn requires a mysql
[13:38:16] <jepler> I see now that the VIRT of the java process is 1408188(kB), dockerd 511424, guacd 387592 (x2)
[13:40:06] <jepler> oh and mysqld of course
[13:40:48] <jepler> RES = 175348 (mysqld) + 157584 (java) + 19556 + 18636 + 10340 (guacd * 3) + 17332 (dockerd)
[13:41:06] <jepler> that's just 400MB :-P
[13:41:26] <jepler> probably in the same realm as a gnome or mint DE though
[13:55:10] <jepler> this is interesting but it's ultimately frustrating to try to use a desktop through a web browser:
http://guacamole.incubator.apache.org/
[13:55:24] <jepler> due to problems with special keys, etc., which are even worse than in a normal vnc client
[13:56:13] <jepler> on 50% of the two browsers I tested, I couldn't even reliably send the ctrl+shift+alt combination that brings up its internal menu, and forget about alt-f4...
[13:57:01] <mozmck> point and click only :-)
[13:57:12] <jepler> doesn't fit with how I use computers though
[13:57:54] <mozmck> yeah, you should only need ssh
[13:58:35] <mozmck> looks like an interesting project - had not heard of quacamole other than the green goo that people eat.
[14:01:53] <jepler> it feels more responsive than a traditional vnc client, not sure why that should be
[14:02:03] <jepler> maybe they simply have a better protocol than vnc to the browser
[18:54:31] <skunkworks> hmm - I don't know if I like gnome on jessie
[20:32:39] <jepler> http://home.woot.com/?ref=w_gh_hm_2 prime linuxcnc retrofit candidate just $199
[20:36:26] <CaptHindsight> jepler: if you do it, please try to print 3d pancakes not just flat ones :)
[20:46:08] <jepler> not a new invention
http://foodnetwork.sndimg.com/content/dam/images/food/fullset/2007/4/2/0/ip0205_funnelcake.jpg
[20:46:25] <jepler> a state fair staple around here
[21:50:37] <jmkasunich> gents - I just now happened to scroll back and saw mention that tests/limit3.1 was causing problems on the buildbot...
[21:51:21] <jmkasunich> how would I examine those results?
[21:58:35] <jepler> 02:01:35 <linuxcnc-build> build #4462 of 0000.checkin is complete: Failure [failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4462
[21:58:59] <jepler> under step 5 you can follow a link to an individual builder such as
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/1074
[21:59:28] <jepler> and from there to the test result stdio
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/1074/steps/runtests/logs/stdio
[21:59:36] <jmkasunich> am I reading it correctly - it failed on every system?
[21:59:38] <jepler> and then you get to use your browser's search function
[21:59:46] <jepler> it failed on a lot of systems at any rate
[22:00:31] <jepler> if you search for limit3.1/expected
[22:00:44] <jepler> you'll see that one sample (apparently) was different from expected
[22:00:45] <jepler> -199 -1.000000 -1.000000 0
[22:00:45] <jepler> +199 -1.000000 -1.000000 1
[22:01:47] <jmkasunich> floating point aggravations
[22:02:03] <jmkasunich> the last column is the "in-limit" flag
[22:02:40] <jmkasunich> this is the tail end of a period in which the output was in limit, then slews to the proper value and comes out of limit
[22:03:14] <jmkasunich> the difference between in and out at step 199 must be "tiny"
[22:04:14] <jepler> FP results are routinely slightly different on different platforms and that is infuriating.
[22:04:38] <jepler> I don't have an immediate recommendation of a different strategy for testing what you'd like to test
[22:05:53] <jmkasunich> hmm, two platforms failed at "platform-is-supported"
[22:06:00] <jepler> that is a failure you can/should ignore
[22:06:01] <seb_kuzminsky> ilure
[22:06:13] <seb_kuzminsky> err... "that's not quite a failure"
[22:06:22] <jepler> it means buildbot knows that platform is too old (typically; sometimes it might be too new) to build that linuxcnc branch
[22:06:26] <jepler> afk and goodnight
[22:06:32] <jmkasunich> gotcha
[22:06:35] <jmkasunich> goodnight
[22:08:06] <jmkasunich> looks like 8 passed, 7 failed in the limit3.1 test
[22:08:45] <jmkasunich> lacking repeatable FP math, probably should eliminate or disable that test
[22:13:27] <seb_kuzminsky> some FP code does the lame thing of adding a small epsilon/fudge-factor to the tests
[22:14:12] <jmkasunich> doesn't our test do a text-mode compare of result and expected?
[22:14:32] <seb_kuzminsky> at the runtests level, yes
[22:14:48] <seb_kuzminsky> i meant, within the actual C code that does FP tests (like for setting that hal pin)
[22:15:00] <jmkasunich> oh, you mean the if() inside the component that determines in-limit
[22:15:06] <seb_kuzminsky> yeah
[22:15:45] <jmkasunich> I have a hard time with the idea of crufting up the code just to make a test pass
[22:16:01] <seb_kuzminsky> i can understand and relate
[22:16:23] <seb_kuzminsky> but on the other hand, the flag *is* wrong, on those platforms, in those situations
[22:16:46] <jmkasunich> I wouldn't say that
[22:19:27] <jmkasunich> thats like saying 1/3 = 3.333333 is wrong and 3.33333333 is right
[22:19:36] <jmkasunich> oops, both are wrong
[22:19:43] <jmkasunich> 0.3333 vs 0.333333
[22:20:05] <seb_kuzminsky> oh, i see now, it's a rounding error
[22:21:58] <seb_kuzminsky> the limit3.9 manpage does not mention the .in-limit pin
[22:22:43] <jmkasunich> limit3 is a comp, the man page is autogenerated
[22:22:43] <seb_kuzminsky> oh nevermind again, i just need to rebuild it
[22:27:55] <jmkasunich> I'm not going to have the opportunity to remove or revise that test until at least Friday evening... I hate leaving things busted
[22:32:30] <seb_kuzminsky> we could mark that test as "skip" for now - it wont get run, and won't cause build failures
[22:32:56] <jmkasunich> sounds good
[22:33:01] <jmkasunich> can you do that?
[22:33:05] <seb_kuzminsky> sure
[22:33:10] <jmkasunich> thanks
[22:35:08] <jmkasunich> I think the problem is that the limits I use in the test result in the slew taking _exactly_ 200mS, so even a tiny rounding error can make it finish just before or just after that time
[22:35:24] <jmkasunich> maybe I'll tweak a value so it finished in 199.5 or 200.5mS
[22:35:57] <seb_kuzminsky> right, so it doesn't land "right on the edge"
[22:37:15] <seb_kuzminsky> maybe just bumping the maxv or maxa would push it off that edge
[22:37:34] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 663c914 06linuxcnc 03tests/limit3.1/skip tests: skip the limit3.1 test for now * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=663c914
[22:38:05] <jmkasunich> only trick is figuring out how much of a bump - I will have to play with it a bit, can't do that tonight
[22:38:07] <jmkasunich> goodnight
[22:39:33] <seb_kuzminsky> good night
[22:39:39] <seb_kuzminsky> oh, one last thought
[22:40:10] <seb_kuzminsky> you can push temporary, experimental branches to git.linuxcnc.org to have the buildbot test them on all our platforms
[22:40:50] <seb_kuzminsky> then when you get it working, you can use rebase to simplify your experimental branch, removing the commits that didn't help, and merge the final working ones to master (or where ever they belong)
[22:46:03] <seb_kuzminsky> the gnome folks are working on a flow-graph tool, including gui widgets:
https://lwn.net/SubscriberLink/697224/7d8ebc28e5ad4c87/
[22:46:48] <seb_kuzminsky> it's not in jessie yet
[23:09:12] <linuxcnc-build> build #3164 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/3164 blamelist: Sebastian Kuzminsky <seb@highlab.com>
