Back
[01:14:58] <seb_kuzminsky> jepler: the tests/t0 runtime went from ~158 seconds in 2.6 to ~167 seconds in mdi-drop
[05:47:02] <KGB-linuxcnc> 03John Thornton 052.7 bdc4271 06linuxcnc 10(6 files in 2 dirs) Docs: fix some anchor locations * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bdc4271
[05:47:02] <KGB-linuxcnc> 03John Thornton 052.7 299eacb 06linuxcnc 10docs/src/gui/gmoccapy.txt Docs: clean up and fix anchors and markup * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=299eacb
[07:37:53] <KGB-linuxcnc> 03John Thornton 052.7 34d66bc 06linuxcnc 10docs/src/getting-started/about-linuxcnc.txt 10docs/src/getting-started/getting-linuxcnc.txt Docs: markup fixes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=34d66bc
[08:22:29] <jepler> seb_kuzminsky: thanks for timing it.
[08:22:36] <jepler> that seems acceptable in the context, if it fixes the reliability problem there
[08:23:32] <jepler> 2.7 must be just about ready .. for the next prerelease
[08:28:00] <arrowbook> hi, can also the servo motors be drived by the stepgen.c?
[08:29:25] <Tom_itx> as cradek mentioned yesterday, it would depend on the servo driver
[08:31:29] <archivist> some servo drives have step dir inputs
[08:32:49] <skunkworks> but that is a yecky way of doing it...
[08:33:05] <archivist> I think it is silly too
[09:18:36] <skunkworks> pcw_home, your info on intel nics should go into the hm2_eth docs
[09:58:04] <seb_kuzminsky> jepler: mdi-drop only wrecks pipelining on about 1/8 of the mdi commands
[09:59:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 6385409 06linuxcnc 10src/emc/task/emctaskmain.cc task: warn when dropping queued mdi commands * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6385409
[09:59:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 4f1dd3e 06linuxcnc 10tests/t0/nonrandom/expected-gcode-output 10tests/t0/random-with-t0/expected-gcode-output 10tests/t0/random-without-t0/expected-gcode-output 10tests/t0/shared-test.sh tests: avoid mdi queueing after gcodes that can fail * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4f1dd3e
[10:03:05] <KGB-linuxcnc> 05seb/2.6/mdi-drop 305cd3d 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=305cd3d
[10:07:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 831be6b 06linuxcnc 10src/emc/task/emctaskmain.cc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=831be6b
[10:58:49] <skunkworks> so there. I don't have to play telephone!
[10:58:54] <skunkworks> :)
[11:10:56] <pcw_home> dgarr: is it ok if I post you GUI watchdog demo to the forum for emcPT?
[11:10:57] <pcw_home> (might help determine if its a GUI or USB hang)
[11:11:17] <cradek> any sign that he has looked in dmesg?
[11:14:05] <pcw_home> no :-(
[11:17:51] <seb_kuzminsky> next time i tune a pid loop i want to wear this shirt:
https://fabrily.com/negativefeedback
[11:20:01] <jepler> tee hee
[11:20:09] <jepler> you can wear it next time you review my changes too
[11:20:21] <seb_kuzminsky> haha
[11:20:43] <seb_kuzminsky> jepler: do you agree with andypugh that the carousel demo has no known bugs at this time?
[11:21:33] <jepler> seb_kuzminsky: I can't say that I've used the carousel demo enough to be able to answer that.
[11:21:48] <jepler> seb_kuzminsky: I've resolved both preexisting problems that were exposed by carousel
[11:30:47] <seb_kuzminsky> right
[11:30:48] <seb_kuzminsky> cool
[11:31:20] <seb_kuzminsky> i want to release 2.6.9 and 2.7.0~pre7 this week, does anyone know of anything else that needs to be fixed first?
[11:31:46] <seb_kuzminsky> i feel like we should do one of those nasa misson control style go/no-go roll calls
[11:31:51] <cradek> do it!
[11:35:04] <fenn> peanut gallery GO
[11:36:20] <seb_kuzminsky> heh
[11:36:26] <jepler> so cradek and I speculated about the duplicate label reporting and yes, a very obvious sequence of things to do can trigger it falsely after my fix.
http://paste.ubuntu.com/12049002/
[11:36:56] <jepler> basically, during the write/test cycle you will trigger it over and over again when you move the line where an O-label is
[11:37:31] <seb_kuzminsky> i have ceased to be surprised by interp's wonky behaviors
[11:38:13] <jepler> hitting reload seems to be the easy workaround for this
[11:38:41] <seb_kuzminsky> reload? of the splash screen?
[11:38:52] <jepler> right
[11:39:08] <seb_kuzminsky> wow
[11:42:12] <jepler> argh help I'm binge-reading Existential Comics
[15:57:29] <jepler> >
[15:57:29] <jepler> G92 - This command, when used with axis names, sets values to offset variables.
[15:57:34] <jepler> I'm a native english reader and I can't even
[15:57:54] <cradek> that's bad. baaaaad.
[16:28:40] <seb_kuzminsky> cool, the debian kernel folks are switching from svn to git
[16:28:50] <seb_kuzminsky> this will make it easier for us to make rtai kernels in the future
[19:09:55] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 0ee3624 06linuxcnc Merge remote-tracking branch 'origin/andypugh/carousel_demo' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0ee3624
[19:10:48] <andypugh> <awaits build failures>
[19:12:15] <seb_kuzminsky> it looks good to me andypugh
[19:12:37] <seb_kuzminsky> i just noticed the vismach model shows the spindle spinning
[19:12:38] <seb_kuzminsky> :-)
[19:13:13] <andypugh> seb_kuzminsky: Yes, I needed to show the spindle rotating to show the orient working.
[19:13:24] <andypugh> (Try MDI an M19 command :-)
[19:15:26] * seb_kuzminsky mdis
[19:16:41] <seb_kuzminsky> neat!
[19:17:00] <andypugh> (Spindle orient is part of the tool change procedure)
[19:17:09] <seb_kuzminsky> right
[19:17:16] <seb_kuzminsky> very cool, thanks for that work!
[19:17:17] <seb_kuzminsky> bbl
[19:17:33] <Tom_itx> andypugh does that cause it to stop on the spindle index?
[19:17:43] <andypugh> When 2.7 merges up to Master I need to remember to change the config to use the new “is oriented” output from “orient”
[19:18:31] <andypugh> Tom_itx: Not in this case, as the Vismach model doesn’t have an index. It’s an absolute position thing.
[19:18:54] <Tom_itx> if it had an index would M19 stop on the index pulse?
[19:19:30] <andypugh> Yes, if the spindle encoder has been reset to index
[19:19:30] <cradek> andypugh: that demo is very neat. also, it helped us notice bugs. yay!
[19:19:58] <Tom_itx> or is the R word an angle from the pulse to stop on if specified...
[19:20:02] <andypugh> I am not sure what the best way is to home a spindle.
[19:20:21] <Tom_itx> it will likely vary from one machine to the next
[19:20:24] <andypugh> It almost looks like a job for a dedicated component.
[19:20:43] <Tom_itx> some may require the R word some may just use the index pulse
[19:21:18] <andypugh> (when home goes high, set index-enable, turn on the spindle at a low speed, turn off the spindle when index-enable goes low)
[19:21:34] <Tom_itx> also the spindle will need to raise and lower to pick up the next tool
[19:21:54] <Tom_itx> on some carousels
[19:22:04] <andypugh> Have you looked at he demo?
[19:22:36] <Tom_itx> no i haven't yet
[19:22:36] <andypugh> The spindle does go up and down.
[19:22:37] <Tom_itx> ahh cool
[19:22:38] <Tom_itx> can you specify the distance?
[19:23:23] <Tom_itx> i'm debugging my control atm then i plan to look at it even though i don't have a tool changer
[19:23:24] <andypugh> The sample config uses a G-code sub. I wrote the “hardware” so that it looks like a real machine, so in theory a Classic Ladder toolchanger could be added to the same config as a separate demo.
[19:29:50] <Tom_itx> andypugh, on a RS422 board ie 7i47 do you know if i need the terminator resistors enabled or disabled... i'm using them as IO with a resistor divider on the - side
[19:30:14] <Tom_itx> single ended
[19:31:12] <andypugh> Tom_itx: I am afraid I don’t know, I haven’t used one. PCW should be able to be definitive.
[19:31:35] <Tom_itx> yeah, he's kinda busy..
[19:32:21] <Tom_itx> i'm thinking one of the txrx chips may be bad. i'm getting 1.8v on the - side and 1.73v on the + side with nothing connected
[19:32:39] <Tom_itx> and erratic behavior on the io
[19:32:50] <andypugh> I would try it both ways. If neither work, or both work, then it’s inconclusive, otherwise you have an answer.
[19:33:06] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/cnc/configs/sherline/bitfiles/Screenshot-HAL%20Oscilloscope.png
[19:33:11] <Tom_itx> lotsa noise
[19:34:12] <Tom_itx> i was thinking if you wanted to use them as IO you disabled the terminating resistor
[19:34:17] <Tom_itx> which is what i did
[19:34:46] <Tom_itx> the other io work, just these: 5 7 9 11 are acting strange
[19:39:00] <Tom_itx> this is a new 7i47
[19:39:08] <Tom_itx> s
[20:37:06] <skunkworks> I found a few more violations. (varying the axis accelerations.) I sent them to rob.
[22:35:30] <seb_kuzminsky> i think the tp in 2.7 is much better than the one in 2.6: better performance, but also better correctness. do you agree, skunkworks?
[22:38:09] <seb_kuzminsky> mozmck: wanna talk about release procedures?
[22:38:43] <seb_kuzminsky> i've tried to capture some of it here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ReleaseCheckList
[22:38:57] <seb_kuzminsky> a few days ago i created a local branch called 2.6.9-pre, from origin/2.6
[22:39:08] <seb_kuzminsky> i updated debian/changelog and the VERSION file
[22:39:36] <seb_kuzminsky> in the changelog i ran "git log --oneline v2.6.8..", to get the list of commits (just the first line of the commit message) since 2.6.8
[22:39:56] <seb_kuzminsky> i went down the list while looking at the full log using "gitk v2.6.8.." in another window
[22:40:32] <seb_kuzminsky> i removed the stuff that users don't care about (test improvements and other commits that don't impact anyone)
[22:41:18] <seb_kuzminsky> i sorted the remained with "more user-visible" stuff at the top and "less user-visible" stuff at the bottom
[22:41:23] <mozmck> Hi seb_kuzminsky, I can just a little here, I'm about to retire for the night.
[22:41:31] <seb_kuzminsky> yeah me too
[22:41:47] <seb_kuzminsky> i committed that change on the 2.6.9-pre branch and left it
[22:42:19] <mozmck> Ok, that makes sense
[22:42:32] <seb_kuzminsky> now i can rebase it onto 2.6 and then update the changelog with something like "git log --oneline 2.6.9-pre@{1}.." to pick up the new commits
[22:42:49] <seb_kuzminsky> this is just how i do it, there's lots of possibilities
[22:43:11] <seb_kuzminsky> when it's time for the real release, do a final update, tag (as per the RelaseCheckList wiki page), and push
[22:43:28] <mozmck> so what are you rebasing onto 2.6?
[22:43:36] <seb_kuzminsky> the buildbot will build & test & make debs, and put them im the special release deb archive
[22:43:41] <seb_kuzminsky> i rebase the 2.6.9-pre branch
[22:44:10] <mozmck> and that just has the changelog changes? or everything since 2.6.8?
[22:44:12] <seb_kuzminsky> the local one i created up at the top of my monologue
[22:44:22] <seb_kuzminsky> yeap:
[22:45:37] <seb_kuzminsky> this is the only commit in 2.6.9-pre:
[22:45:38] <seb_kuzminsky> http://paste.ubuntu.com/12053186/
[22:46:13] <seb_kuzminsky> and i'm careful not to push it, so as not to confuse the buildbot
[22:46:46] <mozmck> ok. so do you have to do something to the buildbot when you do push it?
[22:47:04] <seb_kuzminsky> nothing to the buildbot, but you have to massage the branch a bit
[22:47:42] <seb_kuzminsky> so when the "2.6" branch is actually ready to release, i'll rebase the branch called 2.6.9-pre onto origin/2.6, then update the changelog one final time (and "commit --amend")
[22:47:57] <seb_kuzminsky> now 2.6.9-pre has one commit more than origin/2.6, which makes the changelog and VERSION just the way they should be
[22:48:18] <seb_kuzminsky> then i check out 2.6 and "git merge --ff-only 2.6.9-pre" to move my local 2.6 up to that point
[22:48:27] <seb_kuzminsky> tag it as described in ReleaseCheckLis
[22:48:31] <mozmck> I see.
[22:48:40] <seb_kuzminsky> then "git push 2.6 v2.6.9"
[22:48:46] <seb_kuzminsky> and the buildbot will do its thing
[22:48:54] <mozmck> that pushes the tag?
[22:49:01] <seb_kuzminsky> yeah, the tag and the branch
[22:49:05] <mozmck> ok
[22:49:06] <seb_kuzminsky> (the 2.6 branch)
[22:49:16] <seb_kuzminsky> then you watch the buildbot to make sure all's well
[22:49:30] <mozmck> yeah
[22:49:36] <seb_kuzminsky> then it's moving debian packages around, which is another bit of work with special tools & stuff
[22:49:42] <seb_kuzminsky> i'll show you that another night :-)
[22:50:21] <mozmck> ok :) I better head to bed now - I'll look at that stuff maybe tomorrow and ask if I have questions.
[22:50:30] <seb_kuzminsky> cool
[22:50:33] <seb_kuzminsky> good night
[22:50:39] <mozmck> Sounds pretty straightforward though so far.
[22:50:50] <seb_kuzminsky> yeah, just a bunch of git jiu jitsu
[22:51:20] <seb_kuzminsky> if you look at the commit tagged "v2.6.8" you'll see what you're trying to create here
[22:51:24] <mozmck> I'm larnin' git a lot better these days
[22:51:34] <mozmck> ok
[22:51:42] <seb_kuzminsky> awesome :-)
[22:51:54] <mozmck> well, I better git!
[22:51:55] <seb_kuzminsky> ok, time for me to go tuck in my kids :-)
[22:51:57] <seb_kuzminsky> seeya
[23:32:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 4b6faea 06linuxcnc 10VERSION 10debian/changelog LinuxCNC 2.6.9 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4b6faea
[23:32:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 1216914 06linuxcnc 03v2.6.9 LinuxCNC v2.6.9 (tagged commit: 4b6faea) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1216914
[23:37:24] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 1af4ade 06linuxcnc 10debian/changelog Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1af4ade
[23:38:40] <seb_kuzminsky> argh, 2.7 doesnt merge into master because of conflicts in the gmoccapy docs
