#linuxcnc-devel | Logs for 2016-11-02

[07:56:08] <KGB-linuxcnc> 03Jeff Epler 05master e9c5b22 06linuxcnc 10debian/configure packaging: fail gracefully if apt showsrc info missing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e9c5b22
[09:17:02] <skunkworks> zlog
[10:04:12] <cradek> that andy could write that gcode and not encounter an interpreter bug makes me happy
[10:13:26] <skunkworks> I have not seen any mention of any sort of odd interpreter bugs.. Which is really amazing.
[10:18:45] <cradek> #54 = [52**2 * 53**2 - 2*52*53*COS[51]]
[10:18:56] <cradek> I didn't even know we had exponentiation
[10:19:30] <cradek> no that can't be right
[10:19:58] <cradek> he must have html problems or something
[10:21:07] <cradek> ok I see we do have **
[10:21:43] <cradek> but this makes #54 a constant and I'm sure he didn't mean it to be
[10:25:31] <jepler> you think there are some missing #s ?
[10:25:37] <cradek> yeah
[10:26:06] <cradek> especially since he calculated #52 and #53 on the previous lines
[10:26:19] <cradek> #55 = [90 - ASIN[#53 * SIN[51] / #54]
[10:26:34] <cradek> this also seems to be missing the # before #51
[10:27:10] <cradek> I bet he was using a terrible blogspot-imposed editor
[10:27:45] <jepler> oh -- the part program might be right, but the blog software ate it?
[10:27:51] <jepler> that seems most likely, if there are errors everywhere
[10:27:52] <cradek> surely
[10:28:08] <jepler> sigh
[10:28:15] <cradek> the web is terrible
[10:28:17] <cradek> it's made of software
[12:34:31] <cradek> "the easiest way to mesaflash is using super-common hardware you probably already have" is a weird thing to be het up about
[12:39:54] <pcw_home> If SPI was more likely to work, I could have a EPP/SPI combo as the default, (the 7I90 has 2 EEPROMs with a jumper select)
[12:39:56] <pcw_home> But SPI seems pretty iffy on most hosts
[12:40:07] <kwallace_ofcb> Just trying to clear up some persistent myths, and we happened to be at a keyboard at the same time.
[12:40:20] <cradek> I don't think I have any SPI hardware
[12:41:05] <cradek> but what's rare and common in my house may be different from others
[12:41:16] <pcw_home> I suppose it could be bit banged over a (terribly obsolete) parallel port
[12:41:35] <pcw_home> (might take a while)
[12:42:06] <cradek> haha
[12:45:10] <pcw_home> I've never tried the serial option (you can set it for 115200 baud so a USB/422 adapter might work)
[13:00:15] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 28bb2a5 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc 10src/emc/rs274ngc/rs274ngc_interp.hh 10src/emc/rs274ngc/rs274ngc_pre.cc Revert "interp: move end-of-program cleanup code to its own function" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=28bb2a5
[13:15:03] <tinkerer> pcw_home: but bit banging would be easy with gpio. I did it with the fabulous P.... board. :). programming with gpio bit banging and working with spi.
[13:23:10] <tinkerer> hey, All Saints' was yesterday. what a silence.
[13:25:06] <pcw_home> Yeah bit banging should always work
[13:25:07] <pcw_home> I should probably change the default (timeout)
[13:25:09] <pcw_home> return data from 0xAAAAAAAA to 0x12345678
[13:25:10] <pcw_home> to flag data ordering issues when testing
[13:26:46] <pcw_home> since you wont get sensible data if the xmit data ordering is wrong
[13:33:33] <seb_kuzminsky> ooh, the stmbl servo drive looks interesting: https://github.com/rene-dev/stmbl
[13:44:18] <cradek> heh I recognize that disclaimer
[13:45:07] <cradek> can take a command of quadrature, that's nice(r than step/dir)
[13:50:59] <cradek> very exciting!
[13:56:15] <jepler> that nice big isolation gap between the HV and LV sections is pleasing to see
[13:56:36] <cradek> yeah, looks like a sign of good design
[13:57:05] <jepler> interesting, it's got something hal-inspired inside too https://github.com/rene-dev/stmbl/wiki/Servoterm
[13:57:12] <jepler> entering 'list' prints a list of hal pins. The current default config is for a 4 pole AC permanent magnet motor with resolver feedback, using an encoder for command.
[13:57:16] <jepler> net0.fb <= res0.pos = 0.000000
[14:14:28] <linuxcnc-build_> build #641 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/641 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[15:04:57] <seb_kuzminsky> i'm planning 2.6.13 in the next day or two (or three)
[15:05:23] <seb_kuzminsky> i'm hoping this will be the final 2.6 release, and i'm planning to encourage everyone who wants future updates to move to 2.7
[15:05:37] <seb_kuzminsky> speak now or forever hold your peace
[15:05:42] <jepler> thumbs up from me
[15:06:29] <seb_kuzminsky> cool
[17:44:32] <tinkerer> seb_kuzminsky: for your arm buildbot: http://hackaday.com/2016/10/28/odroid-xu4-runs-cool-as-water/
[18:31:27] <seb_kuzminsky> neat!
[18:32:23] <seb_kuzminsky> i don't think it's an overheating problem - it's correctly throttling back when it gets hot, and crashes aren't correlated with heat (that was the first thing i suspected, and started paying attention to)
[18:32:41] <seb_kuzminsky> and i don't like you folks *so* much that i care how quick the buildbot is ;-)
[19:11:35] <cradek> let's not talk about our feelings too much
[19:59:47] <tinkerer> jepler around?
[22:07:40] <cradek> seb_kuzminsky: I'm curious - does that reversion fix something? I don't remember there currently being a problem in 2.6