Back
[04:36:43] <archivist> I like meld
http://www.collection.archivist.info/archive/grabs/streamer.c.orig:streamer.c.slv.djc:streamer.c.png
[07:42:06] <archivist> should he explain his code comment to a rubber duck
http://en.wikipedia.org/wiki/Rubber_duck_debugging
[13:04:01] <pcw_home> Has something changed recently with the TP in master? It no longer seems to maintain the same velocity
[13:04:03] <pcw_home> (looks like exact stop mode)
[13:05:00] <seb_kuzminsky> no, tp in master should be identical to 2.7
[13:11:09] <pcw_home> same thing in 2.7
[13:24:42] <micges> pcw_home: pastebin your test gocde
[13:25:13] <pcw_home> its the torus.png code I have been using all along
[13:25:19] <micges> ok
[13:26:26] <archivist> some new flags/settings in the ini for the new tp ?
[13:26:34] <pcw_home> http://ibin.co/1u8m2YlUxX3h
[13:27:36] <pcw_home> (skimming the top of the toroid g64 P0.001 used to run at at least 500 IPM)
[13:53:51] <micges> same here
[13:54:00] <skunkworks> what program?
[13:54:47] <micges> sim axis mm and torus.png from nc_files
[13:55:08] <micges> even with g64P0.1 currvel goes to 0
[13:56:03] <skunkworks> can somone post the gcode? my png import doesn't work
[14:05:52] <pcw_home> http://ibin.co/1u8xoWdzbIfP
[14:09:12] <pcw_home> thats with pretty fine stepover settings so will take a while to mill the imaginary material down to the top of the toroid...
[14:10:31] <pcw_home> ( my machine settings are 1200 IPM, 1200 IPS/S ( ~3G ))
[14:26:06] <micges> pcw_home: do you have firmware around with encoder dpll?
[14:26:41] <pcw_home> yes, if I can find it...
[14:30:39] <pcw_home> freeby.mesanet.com/7i76e_7i76x1d.bit
[14:30:40] <pcw_home> freeby.mesanet.com/7i76e_7i76x1_7i77x1d.bit
[14:30:42] <pcw_home> _might_ have the encoder DPLL option
[14:30:52] <micges> thanks
[14:35:23] <adam3999> hey pcw, micges -- thanks for spending some time to help my resolve my lpt input problem
[14:35:43] <skunkworks> pcw_home: You think it ran faster before?
[14:36:02] <pcw_home> Yes it drops to 0 velocity now
[14:38:10] <pcw_home> Now it may be that I didn't look carefully with this exact setup
[14:38:20] <pcw_home> but it still seems wrong
[15:11:29] <micges> adam3999: I just confirmed that the problem exists ;)
[15:14:04] <adam3999> what motherboard did you test?
[15:14:58] <micges> I mean I didn't help much, just confirmed that the problem exists when you asked few days ago :)
[15:15:57] <adam3999> gotcha
[15:16:13] <micges> friend is too busy to check solution for this but he promised he will asap
[15:16:21] <adam3999> thanks
[15:16:30] <adam3999> i was able to work around it with 2.2K pullup resistors
[15:18:13] <micges> yeah that's great
[15:18:54] <adam3999> yeah was pretty excited to see that ptest app finally show a green light
[15:19:12] <micges> pcw_home: does this pullup problem allow to use 7i90 and 7i43 with that mb?
[15:19:13] <adam3999> i think if i was billing myself at $10/hr i could have bought a nice mesa setup lol
[15:19:43] <pcw_home> yeah no issue with 7I43 or 7I90
[15:19:58] <micges> uff
[15:20:15] <pcw_home> (nothing depends on pullups)
[16:16:46] <skunkworks> I just pulled 2.7 and it seems to have issues. Master from v2.8.0-pre1-326-gc3ec78e doesn't
[16:16:59] <skunkworks> I don't know how far back that is.. last week mabye
[16:17:11] <skunkworks> issues as in slow
[16:19:19] <cradek> unfortunately c3ec78e is from mid january
[16:19:32] <skunkworks> couple weeks then..
[16:19:34] <skunkworks> :)
[16:20:36] <skunkworks> how hard is it to walk back commits?
[16:20:56] <skunkworks> I wonder if it was part of the rigid tapping fixes
[16:20:56] <cradek> if you have a good test, you could definitely use bisect to find the problem
[16:21:28] <cradek> want me to help you do it?
[16:21:33] <skunkworks> sure
[16:21:58] <cradek> so you currently have the bad version, and you know c3ec78e is good?
[16:22:33] <skunkworks> yes - I just pulled 2.7 pre - c3ec78 is master - does that matter?
[16:22:57] <skunkworks> I could pull master in a fresh directory.."
[16:26:35] <cradek> hm yeah, c3ec78 is not in the history of 2.7 so that will be trouble
[16:26:51] <cradek> can you checkout master and build that, and see if it's broken too? it probably is.
[16:26:54] <skunkworks> well - let me pull master and see
[16:27:03] <cradek> you don't need a new clone, just git checkout master; git pull
[16:29:18] <cradek> looks like you will be able to find it with only 5 steps (there are 55 commits)
[16:29:30] <skunkworks> cool
[16:29:40] <skunkworks> building now to make sure it has the issue
[16:29:44] <cradek> great
[16:33:51] <skunkworks> ok - when I do a git checkout master , git pull - I end up with v2.7.0-pre4-136-g9c409f3
[16:34:31] <cradek> ok did you confirm that one's broken?
[16:35:53] <skunkworks> yes - but why is it saying I am on master - yet v2.7?
[16:37:00] <cradek> umm
[16:37:58] <skunkworks> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-2.7$ git branch
[16:38:00] <skunkworks> 2.7
[16:38:01] <skunkworks> * master
[16:38:02] <skunkworks> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-2.7$ git describe
[16:38:04] <skunkworks> v2.7.0-pre4-136-g9c409f3
[16:38:05] <skunkworks> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-2.7$
[16:38:13] <skunkworks> I did a make clean - then make
[16:38:26] <cradek> yeah I'm seeing it here too. I haven't figured out why yet
[16:38:30] <skunkworks> oh
[16:38:32] <skunkworks> ok
[16:38:40] <cradek> a variant of "it's not you, it's me"
[16:38:49] <cradek> it's not you, it's probably not me either
[16:39:08] <skunkworks> heh
[16:43:58] <cradek> well I think it's ok
[16:44:10] <skunkworks> you think I am master?
[16:44:18] <cradek> I think it's just that those 2.7 tags have been made since the 2.8 tag was
[16:44:26] <cradek> yes you're on master
[16:44:36] <cradek> just ignore the tag name
[16:44:56] <skunkworks> ok
[16:44:58] <cradek> so you tested 9c409f3 and it's bad and that's what you've currently got checked out, right?
[16:45:35] <skunkworks> yes
[16:45:37] <cradek> and you're sure c3ec78e is good?
[16:45:52] <skunkworks> yes - If the tag can ge relied on.. ;)
[16:46:04] <cradek> yeah the part after the g you can trust
[16:46:15] <cradek> ok! let's do it
[16:46:22] <skunkworks> I am game!
[16:46:23] <cradek> git bisect start
[16:46:43] <cradek> git bisect bad (tell it you know this version is bad)
[16:47:03] <cradek> oops
[16:47:21] <skunkworks> well - I was just about to start - so I have not done anything..
[16:47:24] <cradek> let's save work by making an assumption: that a change in src/emc/tp is what broke it
[16:47:35] <skunkworks> ok
[16:47:45] <cradek> git bisect start -- src/emc/tp
[16:48:23] <cradek> you with me?
[16:49:00] <skunkworks> got it
[16:49:09] <cradek> ok
[16:49:12] <cradek> git bisect bad
[16:49:19] <cradek> (tell it this version is known to be bad)
[16:49:21] <skunkworks> ok
[16:49:29] <cradek> git bisect good c3ec78e
[16:49:59] <skunkworks> Bisecting: 26 revisions left to test after this (roughly 5 steps)
[16:50:01] <skunkworks> [507b3147d379fa77e9ef4527cbf677ee65885233] tp: Overhaul of tangency check before creating blend arc.
[16:50:52] <cradek> ok it's picked a revision for you to build and test
[16:51:10] <cradek> it's in the middle so you're going to eliminate half of the changes with this test
[16:51:17] <cradek> go ahead and build and test it
[16:51:26] <skunkworks> Bisecting: 26 revisions left to test after this (roughly 5 steps)[507b3147d379fa77e9ef4527cbf677ee65885233] tp: Overhaul of tangency check before creating blend arc.
[16:51:29] <skunkworks> hsh
[16:51:35] <skunkworks> should I make clean/make
[16:51:38] <cradek> yes
[16:54:01] <skunkworks> that is neet - so it does it for you? you keep telling it what is bad and it keeps bisecting?
[16:54:36] <cradek> yep you just tell it bad/good and it gives you the next step
[16:54:51] <cradek> when it knows for sure which commit introduced the problem, it tells you and you're done
[16:54:52] <skunkworks> heh - now it says 2.8pre
[16:55:21] <skunkworks> ok that one is good.
[16:55:43] <cradek> cool, so git bisect good
[16:56:24] <skunkworks> Bisecting: 13 revisions left to test after this (roughly 4 steps)
[16:56:26] <skunkworks> [7b9fb2b0877907aab2318b69644978d2048c4e3e] tp: fix for velocity overrun bug due to conflict between blending and feed override.
[16:56:42] <cradek> repeat as necessary!
[16:56:48] <skunkworks> :)
[16:56:51] <skunkworks> -j6 helps
[17:00:13] <skunkworks> Bisecting: 6 revisions left to test after this (roughly 3 steps)
[17:00:14] <skunkworks> [22ac5d97eedb72434983eb117f1d4055f74545ae] tp: Added optimizations to increase arc tangential acceleration
[17:04:36] <skunkworks> Bisecting: 3 revisions left to test after this (roughly 2 steps)
[17:04:38] <skunkworks> [14e9153c7d0c6d1086c9582a1ab97287401bebf7] tp: polish and tweaks for low queue fix
[17:04:45] <cradek> woo
[17:05:37] <skunkworks> ^ rob mentioned in the email - that might have been where it broke..
[17:08:10] <cradek> I can tell you for sure that it's awesome when a bug report comes with the results of a bisect...
[17:08:17] <skunkworks> so when the issue shows up - I do a git bisect bad?
[17:08:20] <skunkworks> I assume
[17:08:36] <cradek> yes just report good or bad at each step
[17:12:25] <skunkworks> Bisecting: 0 revisions left to test after this (roughly 0 steps)
[17:12:26] <skunkworks> [95e21dbe25281e40aaf97ecd5495c31aa508277e] tp: Improved handling of low-queue state
[17:12:41] <cradek> whee
[17:13:09] <pcw_home> maybe it thinks the queue is always low
[17:13:36] <pcw_home> ( a good reason to switch to exact stop mode)
[17:13:51] <cradek> we'll know soon...
[17:16:24] <skunkworks> 14e9153c7d0c6d1086c9582a1ab97287401bebf7 is the first bad commit
[17:16:25] <skunkworks> commit 14e9153c7d0c6d1086c9582a1ab97287401bebf7
[17:16:27] <skunkworks> Author: Robert W. Ellenberg <rwe24g@gmail.com>
[17:16:28] <skunkworks> Date: Mon Mar 2 22:17:50 2015 -0500
[17:17:16] <cradek> aha!
[17:18:33] <cradek> I think only the last blob really changes something
[17:22:59] <cradek> oh duh
[17:23:00] <cradek> I see it
[17:23:03] <cradek> int progress_ratio = prev1_tc->progress / prev1_tc->target;
[17:23:16] <cradek> clearly that shouldn't be an int, and neither should cutoff_ratio
[17:23:34] <cradek> skunkworks: git bisect reset
[17:24:10] <cradek> skunkworks: then be bold and change those two ints to doubles and see if it fixes it
[17:25:06] <skunkworks> where is that?
[17:25:14] <cradek> around line 1498 of src/emc/tp/tp.c
[17:29:18] <micges> cradek: it fixes it here
[17:29:32] <skunkworks> awww - I am still building!
[17:30:02] <cradek> :-)
[17:30:12] <cradek> micges wins with the slightly faster computer
[17:30:29] <cradek> after skunkworks does all the hard work!
[17:30:48] <micges> noooo, I had master built ;)
[17:31:42] <micges> so this fixes latest master to be precise
[17:33:22] <cradek> I'll push the fix to 2.7
[17:33:33] <seb_kuzminsky> nice work guys
[17:33:49] <seb_kuzminsky> the verion resported by 'git describe' is unreliable because it uses the most recent tag
[17:34:08] <seb_kuzminsky> use scripts/get-version-from-git instead, it knows what tags to look at based on branch name (for a small set of common branches)
[17:40:07] <KGB-linuxcnc> 03Chris Radek 052.7 8dca131 06linuxcnc 10src/emc/tp/tp.c Fix blending regression * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8dca131
[17:40:07] <KGB-linuxcnc> 03Chris Radek 05master 20f52dd 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=20f52dd
[17:40:36] <pcw_home> Yay!
[17:40:37] <cradek> skunkworks: thanks! :-)
[17:40:51] <skunkworks> no - thank you! git is cool
[17:43:45] <cradek> isn't it though
[17:45:01] <cradek> we knew nothing about the changes, but it pointed us at just a handful of lines of diff to scrutinize
[17:45:43] <ve7it> cradek, thanks for the lesson on git bisect.... one of these days I will have to wade in and learn git... this was a very good incentive!
[17:46:31] <cradek> I have to look at man git-bisect each time
[17:46:42] <cradek> just knowing it's there is 90% of the battle
[17:47:31] <seb_kuzminsky> and memorizing all these manpages is the other 90%:
http://git-man-page-generator.lokaltog.net/
[17:47:41] <ve7it> it might be worth cutting the log and putting it on the wiki as an example... extremely useful for debugging
[17:48:58] <cradek> git-dunk-ref [ --synergize-berate-branch | --record-search-file ] [ --dispatch-fondle-log ]
[17:49:36] <seb_kuzminsky> it's funny because it's just barely plausible
[17:49:37] <cradek> seb_kuzminsky: I love those. they are indistinguishable from real life.
[17:49:45] <seb_kuzminsky> it's the uncanny valley of manpages
[17:49:58] <cradek> git is the uncanny valley of UI
[17:52:34] <seb_kuzminsky> yea, it's somewhere between "dead body" and "zombie",
http://en.wikipedia.org/wiki/Uncanny_valley#mediaviewer/File:Mori_Uncanny_Valley.svg
[17:59:04] <skunkworks> this must be the thread
http://translate.google.com/translate?hl=en&sl=ru&u=http://www.cnc-club.ru/forum/viewtopic.php%3Ft%3D2558&prev=search
[18:05:34] <seb_kuzminsky> that's a couple of important TP fixes since 2.7.0~pre4, i should make a pre5 soon
[18:13:38] <pcw_home> wonder if theres any testing method that can catch performance regressions (and not require real time)
[18:14:06] <seb_kuzminsky> the standalone-motion tester will be able to catch stuff like that
[18:14:47] <pcw_home> I guess a simulated thread time is fine
[18:15:08] <seb_kuzminsky> it emits the once-per-servo-cycle waypoints, and a checkresults script can verify that they reach the expected velocity
[18:15:36] <pcw_home> or thread times to completion
[18:15:44] <seb_kuzminsky> yeah
[18:18:22] <pcw_home> first people that noticed this timed sample code or in my case
[18:18:23] <pcw_home> Just got used to what the velocity plot looked like and noticed a difference
[18:19:14] <seb_kuzminsky> knowing what it "should" look like and paying attention to unexpected stuff is a great debugging technique :-)
[18:19:46] <seb_kuzminsky> here's the checkresult script in the SAM branch that verifies that jogs reach the commanded velocity:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=b323f2310bd7084cb3b9a1a85a3fdefe266807ec
[18:20:23] <seb_kuzminsky> err, i guess it currently just verifies that the max velocity isn't exceeded
[18:20:58] <pcw_home> absolutely great to have those kinds of tests
[18:21:19] <seb_kuzminsky> oh right, it's the verify_velocity_trapeziod function later that verifies that we reach cruise velocity (or hit decel phase before then)
[18:35:17] <pcw_home> Hmm I see the velocity bug Andrew mentions but only from the time
[18:35:18] <pcw_home> you press the begin button, till motion starts
[19:06:07] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master c780045 06linuxcnc 10docs/src/Submakefile docs: teach buildsystem to generate manpages from asciidoc source * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c780045
[19:06:07] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master eaff4f0 06linuxcnc 10(5 files in 5 dirs) docs: convert streamer manpages to asciidoc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eaff4f0
[19:06:12] <seb_kuzminsky> for slavko
[19:10:42] <seb_kuzminsky> bbl sushi
