Back
[05:41:47] <jthornton> seb_kuzminsky, fixed
[05:41:58] <jthornton> for news items don't check front page
[08:14:47] <skunkworks> So - how could I create some xyzuvw programs?
[08:14:59] <skunkworks> To test circular arc blending?
[08:22:35] <skunkworks> I guess initally I could just change some programs to from xyz to uvw
[08:31:45] <skunkworks> seb_kuzminsky: rob rebased the reverse run on master..
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/reverse-run-master
[08:47:40] <cradek> oh hey, releases!
[09:19:18] <jepler> seb_kuzminsky: thank you for releases
[09:19:26] <jepler> man(n)a from the man
[09:36:35] <seb_kuzminsky> welcome :-)
[09:47:30] <seb_kuzminsky> skunkworks: neat
[09:47:50] <seb_kuzminsky> i haven't looked at it yet, but it sounds like a useful thing to have
[10:16:36] <skunkworks> cradek: interesting question.. Why would the exact same program take longer running in uvw space vs xyz space in 2.6?
[10:17:02] <skunkworks> it doesn't seem to be in 'exact stop' mode.
[10:18:03] <cradek> no ncd
[10:18:10] <skunkworks> oh...
[10:18:14] <skunkworks> dij
[10:18:17] <skunkworks> duh
[10:18:21] <ssi> ncd?
[10:18:40] <skunkworks> naive cam detector
[10:18:44] <ssi> ah
[10:18:50] <ssi> that's segment blending?
[10:18:52] <skunkworks> (tries to combine lines and such...)
[10:18:59] <ssi> right
[10:19:47] <jepler> blending (overlapping the accel phase of the next planner item with the decel phase of this planner item) works for UVW
[10:20:24] <jepler> the "naive cam detector" is a system that combines multiple nearly colinear G1s into a single G1, much earlier in the whole process
[10:20:24] <skunkworks> yes
[10:20:34] <jepler> and that doesn't work on UVW axis motion
[10:20:36] <skunkworks> this makes total sense now.
[10:21:07] <skunkworks> because robs cab for uvw runs a bit slower.
[10:21:29] <skunkworks> I totally forgot about nad
[10:21:32] <skunkworks> ncd
[10:33:32] <skunkworks> ok - with g64P.1Q0 - the both run the same time.
[11:37:17] <jepler> that essentially confirms NCD as the difference
[11:47:48] <skunkworks> sure
[13:08:40] <skunkworks_> http://imgur.com/a/klATY
[13:09:14] <skunkworks_> a 3d_chips with xyz moves and identical uvw moves
[13:21:38] <skunkworks> 2.6 vs robs branch
[14:13:16] <andypugh> Does anyone here know anything about canterp?
[14:15:42] <andypugh> It seems like a perfect match for a STEP-NC interpreter that exists (by Tom Kramer and Mark Pictor) so it feels like everything is there, except “something” needs to feed the file to canterp.
[14:16:17] <cradek> I think canterp is gone from linuxcnc
[14:16:32] <cradek> I don't think it's ever worked since (maybe) emc1
[14:17:01] <Tom_itx> it showed up in machinekit upon a google search
[14:17:35] <andypugh> The code is still there
[14:18:04] <andypugh> src/emc/canterp
[14:20:19] <cradek> INTERPRETER = libcanterp.so
[14:20:24] <cradek> see 4ea57f9b1 ?
[14:21:09] <cradek> looks like canterp was revived in 2010: afde7679
[14:25:00] <andypugh> Interesting
[14:25:41] <andypugh> With the canterp sim I get “ERROR 5” trying to run the output of a STEP_NC preprocessor.
[14:26:31] <cradek> that sounds like an unhelpful error
[14:28:02] <andypugh> I confess it isn’t helping me very much
[14:33:02] <seb_kuzminsky> is canterp a drop-in for the interpreter, but that reads files of canon commands and passes them through 1-for-1 to canon calls?
[14:33:16] <andypugh> I think that’s the idea
[14:33:53] <andypugh> And
https://code.google.com/p/iso-14649-toolkit/ outputs in that format from STEP-NC
[14:36:51] <andypugh> I am trying to use something other than Axis, but my DISPLAY = is being ignored. Presumably I am editing the wrong INI file
[14:37:31] <andypugh> Ah, yes, that’s better
[14:45:09] <andypugh> tklinuxcnc shows error 5 too, so it isn’t _only_ about the warning in the commit.
[14:45:41] <andypugh> But, someone on the forum has a €10,000 budget to get STEP-NC running on LinuxCNC as a university project.
[14:45:53] <andypugh> And it seems that many of the parts are there.
[14:46:05] <andypugh> Ideally you wouldb’t go via the canterp file step
[14:46:20] <andypugh> (ie, step-NC direct to canon calls would be best)
[14:55:56] <skunkworks> wow - we have a few older dell precision workstations - they are like Chinese puzzle boxes.
[15:00:14] <andypugh> cradek: Ah, ERROR 5 == INTERP_ERROR, which canterp issues at the slightest provocation :-)
[15:23:15] <andypugh> OK, I probably have better things to be doing than writing an interpreter from scratch in Python, especially one that only says “hello world” when used ;-)
[15:53:26] <jepler> is skunkworks's imgur showing that 2.7 is faster than 2.6 even when uvw moves are involved?
[17:34:27] <KGB-linuxcnc> 03Dewey Garrett 052.7 14e669e 06linuxcnc 10scripts/linuxcnc.in 10scripts/rip-environment.in linuxcnc.in: export LINUXCNC_NCFILES_DIR * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=14e669e
[17:50:03] <skunkworks> jepler: rob has a branc where he extended cab to uvw
[17:50:53] <skunkworks> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/uvw-blending-dev
[17:58:36] <skunkworks> cradek: rotating coordinate system only aplies to xyzI assume? rotating a combined uvw program looks interesting :)
[17:58:39] <skunkworks> http://imgur.com/hCLAM5j
[18:11:57] <skunkworks> I assume at some point in the xyz all bit cancels out the uvw moves
[18:24:19] <linuxcnc-build_> build #1733 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/1733 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:30:00] <linuxcnc-build_> build #1473 of 4016.deb-wheezy-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1473 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:30:01] <linuxcnc-build_> build #1475 of 4017.deb-wheezy-amd64 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1475 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:31:05] <linuxcnc-build_> build #122 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/122 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:32:40] <cradek> skunkworks: yeah, that's going to really be weird if you rotate just one of the two coordinate systems
[18:33:55] <linuxcnc-build_> build #152 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/152 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:33:55] <linuxcnc-build_> build #153 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/153 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:55:45] <jepler> skunkworks: aha
[18:55:51] <jepler> skunkworks: trippy
[18:55:55] <andypugh> I wonder what xu blending looks like? Maybe it is one of those things that looks easier in the code than in the imagination. I once wrote some code to do least-squares fit of data to 3D polynomial surfaces, and when I had the code in front of me it was trivial to extend that to 7-dimensional hypersurfaces. I had no idea what they would be, but I did actually have data with 7 degrees of freedom and one output val
[18:55:56] <andypugh> so it was useful to be able to do that.
[18:58:49] <andypugh> Anyway, work tomorrow, and still recovering from Sunday (basically driving a variety of vehicles from 0530 to 2330) so time to sleep
[20:15:43] <skunkworks> http://imgur.com/a/z31sj