Back
[07:27:42] <KGB-linuxcnc> 03John Thornton 05v2.5_branch 09ed751 06linuxcnc 10src/hal/components/thc.comp Component: fix incorrect calculation of velocity tolerance percent * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=09ed751
[08:58:28] <linuxcnc-build> build #149 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/149 blamelist: John Thornton <jthornton@gnipsel.com>
[09:54:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 7795d33 06linuxcnc Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7795d33
[10:29:09] <KGB-linuxcnc> 03Frank Tkalcevic 05v2.5_branch ed3ed34 06linuxcnc 10src/hal/components/edge.comp edge.comp: eliminate false trigger upon startup * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ed3ed34
[10:42:43] <seb_kuzminsky> yay!
[10:48:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 f74c5d3 06linuxcnc 10src/po/it.po docs: update Italian gettext translation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f74c5d3
[10:49:37] <cradek> woo
[11:13:56] <linuxcnc-build> build #150 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/150 blamelist: Sebastian Kuzminsky <seb@highlab.com>, John Thornton <jthornton@gnipsel.com>
[12:32:20] <kwallace1> Hello, I'm dusting off my Beagle Bone Black with Charles' LinuxCNC and forgot the default username and password to login. Does anyone know, off hand, what to try?
[12:38:15] <kwallace1> Aha, I think "linuxcnc" for both ...
[12:39:01] <kwallace1> Bingo.
[13:09:30] <linuxcnc-build> build #151 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/151 blamelist: Frank Tkalcevic <ftkalcevic@users.sf.net>
[13:25:44] <cradek> I don't understand what gene is saying about units
[13:32:23] <skunkworks> I don't either.. He doesn't have g20/21 in the gcode it sounds like
[13:33:33] <seb_kuzminsky> or he expects F to always be in imperial, even when he puts the controller in metric mode?
[13:38:53] <cradek> that would be an incorrect expectation
[13:39:18] <cradek> he hints it has changed between 2.5 and 2.6 though ...
[13:44:14] <seb_kuzminsky> yeah, that part's a bit worrying
[13:46:04] <skunkworks> I know I have had issues where I ran a program in metric - then went to mdi to do something and wonder why the feed is so much slower than expeceted..
[13:52:15] <cradek> I've done that too -- but that's not a bug, right? the feed and measurements are all metric in that case
[14:02:05] <seb_kuzminsky> that particular bug is in your head, not in linuxcnc
[14:02:18] <seb_kuzminsky> *in our heads
[14:06:37] <skunkworks> not a bug
[14:06:39] <skunkworks> :)
[14:20:33] <cradek> well sounds like someone (ahem) should figure out whether 2.6 moves a related bug from our heads to the software
[14:30:15] <seb_kuzminsky> yeah, i'll check that one out
[14:35:50] <skunkworks> does anyone know what rob is talking about? ;)
[14:37:12] <cradek> yes but I don't know the answer to his question (whether it's a good idea)
[14:37:22] <skunkworks> heh
[14:38:42] <cradek> there are two sane approaches: keep track of units with all the numbers, or convert to a standard internal representation early on input, and then back to what the user wants late at output time
[14:38:58] <cradek> what we do is more like the second one
[14:39:02] <skunkworks> how is it now?
[14:39:07] <skunkworks> ah
[14:39:24] <cradek> not really early and late enough for my liking
[14:40:01] <skunkworks> iirc - internal units are sort of metric? (I remeber jmk being annoyed by that)
[14:40:12] <cradek> for instance: we don't convert before the whole interpreter
[14:40:25] <cradek> then we convert back to user before any of hal sees the values
[14:41:05] <cradek> internal units at the canon level are mm and degrees
[14:41:17] <cradek> internal units in AXIS are inexplicably inches and degrees
[14:41:47] <cradek> so it's afu
[14:43:06] <cradek> I don't know how to fix it
[14:43:54] <seb_kuzminsky> Axis has internal units? doesn't it just use whatever the user said they want to think about?
[14:43:58] <cradek> I have not yet seen a program manage to use C++ to track (and eliminate bugs regarding) units in the way he suggests trying
[14:44:23] <cradek> seb_kuzminsky: at least the opengl parts are scaled in inches
[14:44:33] <seb_kuzminsky> ooh
[14:44:45] <cradek> I think boost has unitsy stuff but I don't know anything about it
[14:45:01] <seb_kuzminsky> i wonder if that's related to that metric/imperial display bug i ran into a while back (and that i never debugged/fixed)
[14:45:11] <cradek> iirc, I never reproduced that
[14:45:32] <cradek> is there a bug for that?
[14:45:35] <seb_kuzminsky> the bottom half of canon runs in the kernel, right? so at that level it has to be C-y, not C++-y
[14:46:00] <seb_kuzminsky> i have the bug in my notes but it's not in the bugtracker
[14:46:11] <seb_kuzminsky> i should write a proper repro recipe first :-/
[14:46:41] <cradek> yes you'd have to be back in Cish land before you got to the motion interface
[14:47:04] <cradek> I wish robert were here
[14:48:01] <seb_kuzminsky> so mcuh of the code that would do arithmetic on CANON_POSITIONs could not rely on C++ operator overloading, i think that means it'd be a bad idea
[14:49:13] <cradek> I guess I'm not sure what problem we're solving, and I'd like to start by knowing that
[14:49:33] <seb_kuzminsky> good point
[14:49:35] <cradek> we have always had a class of bugs related to units
[14:50:10] <cradek> (and they are currently all fixed...)
[14:52:06] <cradek> moving units conversion to early in the interpreter (near read_real_value or whatever it's called) would pretty up canon at least as much as re's proposal
[14:52:25] <cradek> it'd pretty up the interpreter too
[14:52:42] <cradek> then you'd have to convert back before outputting anything to hal
[14:53:06] <cradek> it wouldn't rely on C++ magic
[14:53:32] <cradek> we already do a units conversion in that very early spot: diameters
[14:53:55] <seb_kuzminsky> src/emc/motion/* does not create any CANON_POSITION variables, so i think my C++ complaint is invalid
[15:01:43] <cradek> I can't think of a single reason why the interp couldn't convert to standard units early. it knows the active gcode units perfectly well
[15:02:37] <cradek> var file and tool table would still need (er, may need) conversion on input, and it would become simpler than the conversion that's needed now
[15:02:38] <seb_kuzminsky> you'd have to be careful to convert back to user units in all the error messages coming out of interp, but that's merely work
[15:02:50] <cradek> yes
[15:03:06] <cradek> I wonder if the i18n layer could be expanded to handle that
[15:03:11] <cradek> it's a very similar problem
[15:03:25] <seb_kuzminsky> mind = blown
[15:03:34] <cradek> ?
[15:03:49] <seb_kuzminsky> that suggestion blew my mind
[15:04:43] <cradek> haha, and sam's
[15:04:55] <seb_kuzminsky> dsl modem = blown
[15:05:58] <linuxcnc-build> build #152 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/152 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[15:05:58] <cradek> logger[psha]: can we give RE a link?
[15:05:59] <logger[psha]> cradek: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-04-10.html
[21:41:15] <skunkworks> logger[psha]:
[21:41:15] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-04-11.html
[23:35:59] <KGB-linuxcnc> 03elson 05v2.5_branch dfb061f 06linuxcnc 10(7 files) added new configs for ppmc with encoder velocity estimation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dfb061f