Back
[07:46:43] <skunkworks> seb_kuzminsky, 2nd day 12598 latency
[09:52:10] <skunkworks> http://forum.linuxcnc.org/forum/49-basic-configuration/30033-w-axis-with-gantry-kins-hal-ini-configuration?start=20#66683
[09:56:00] <cradek> wow!
[10:05:18] <skunkworks> yah - awesome
[10:25:22] <mozmck> So does it do synchronized homing??
[10:26:46] <skunkworks> mozmck, I don't think that is working yet.
[10:27:11] <skunkworks> but it isn't a problem as long as your parked position is where the home switch is.
[10:27:16] <mozmck> he mentions automatic gantry squaring...
[10:27:33] <skunkworks> if you have it go to the center of the table after homing - you have issues
[10:28:05] <skunkworks> if I understand it right..
[10:28:37] <cradek> oh man I wish I could respond to the forum email to allow the message
[10:29:36] <mozmck> can someone point me to the code that does run from line? I followed things down to emctaskmain.cc in the emcTaskIssueCommand() function, but I get lost there.
[10:30:18] <mozmck> I see case EMC_TASK_PLAN_RUN_TYPE: and it sets some variables, but I don't see where anything is executed then.
[10:31:37] <cradek> I think the main guts are emctaskmain.cc near line 624
[10:32:15] <cradek> if (emcStatus->task.readLine < programStartLine && ...
[10:35:03] <mozmck> thanks. things get a bit convoluted in there.
[10:35:27] <cradek> wow is that an understatement
[10:36:00] <mozmck> well... I wouldn't want to exaggerate it ;-)
[11:14:34] <jepler> I feel silly that I didn't know or had forgotten until yesterday that RFL actually does some form of simulation of the skipped-over gcode
[11:15:16] <seb_kuzminsky> it has to, right? to determine the state of the interpreter at that line, variables and modal g-codes and what not
[11:15:25] <mozmck> I'm going to see if I can figure out a way to make an option so it does not do that. Maybe another special line number?
[11:15:38] <jepler> seb_kuzminsky: it depends what you think RFL does
[11:15:52] <seb_kuzminsky> hmm yeah
[11:15:55] <jepler> .. I'm sure that doing just what you said is why RFL does what it does
[11:15:58] <cradek> a different reasonable implementation could just start executing at the given line
[11:16:17] <jepler> I keep being surprised that pre-o-words it wasn't more like carefully advancing the paper tape to the desired spot and pressing run
[11:16:20] <cradek> if your modals are wrong it'll do a wrong thing
[11:17:01] <cradek> I think it has always run through from the beginning, but discarding all the motion
[11:17:06] <mozmck> Yes, you have to make sure and start in a sane place if it doesn't pre-run.
[11:17:38] <cradek> I have argued for the simple algorithm before, and I may or may not have been right to do so
[11:19:32] <mozmck> Well, I think there is a case for both. We have used the simple algorithm in Mach for a long time, partly because the complicated one can be buggy I think :-)
[11:19:49] <jepler> mozmck: Mach exposes two different RFL modes?
[11:20:17] <mozmck> yes
[11:20:44] <jepler> that's an interesting data point
[11:21:04] <cradek> I had never considered having both types
[11:21:25] <jepler> (I don't know if it's common or uncommon among this group, but I've never had mach3 installed on a PC of mine. I have sat at others' machines with it installed for a few minutes at a time)
[11:21:56] <cradek> I think I have never seen it in person
[11:29:05] <skunkworks> I have played with mach a little..
[11:29:38] <jepler> I distinctly remember monkeying with steve stallings's computer with windows and mach
[11:29:43] <jepler> I couldn't figure it out
[11:31:42] <archivist> been to a talk by brian barker, about as near as I have got to mach
[11:33:23] <mozmck> I've had to write plugins for mach, so I know a little bit about it ;-)
[11:33:35] <mozmck> afk
[11:56:42] <cradek> jepler: does it moderate the first 3 messages?
[11:59:34] <jepler> cradek: right
[12:00:22] <cradek> that's 3x the work of moderating the first 1 message, and I bet it's way less than 3x as effective. what do you think about trying 1?
[12:09:26] <jepler> that's fine
[12:10:23] <jepler> .. changed
[12:11:35] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja10 e48f7d7 06linuxcnc 10(9 files in 2 dirs) touchy: update hal example, notes for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e48f7d7
[12:11:35] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja10 400576f 06linuxcnc 10docs/man/man9/kins.9 kins manpage, add info for gentrivkins * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=400576f
[12:11:35] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja10 e4f2f99 06linuxcnc 10src/emc/usr_intf/emcsh.cc emcsh.cc remove debugging print * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e4f2f99
[14:07:35] <cradek> jepler: thanks!
[14:10:22] <KGB-linuxcnc> 03Norbert Schechner 052.6 b4e7be3 06linuxcnc 10docs/src/gui/gladevcp.txt docs - gladevcp - added the description of the new iconview signal "sensitive" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b4e7be3
[14:11:18] <KGB-linuxcnc> 03Norbert Schechner 052.7 e63aa52 06linuxcnc 10docs/src/gui/gladevcp.txt Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e63aa52
[14:12:12] <KGB-linuxcnc> 03Norbert Schechner 05master affcf9a 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=affcf9a
[16:15:20] <mozmck> So, does this look good to go?
https://github.com/mozmck/linuxcnc-mirror/commit/3e98ecb91f1f26ac8c220fe0a87c47e753ec00e4
[16:15:41] <mozmck> I would assume it should go in master if so?
[16:18:07] <andypugh> <pedant> “useful”
[16:20:19] <cradek> yes, master! it looks good to me, thanks for tolerating all our suggestions
[16:20:38] <jepler> I wonder about the case where you're jogging one axis and homing another
[16:20:49] <jepler> but forget I mentioned you might even do such a thing
[16:21:00] <seb_kuzminsky> i dont think that's allowed currently
[16:22:19] <andypugh> I seem to recall that jogging aborts homing.
[16:22:36] <andypugh> But that’s just a vague memory of an error of judgement
[16:23:25] <mozmck> aborts? that would seem strange. I think homing will not start if you are jogging.
[16:23:56] <andypugh> I just noticed that the carousel comp docs have an error in the synopsis. It is still saying “loadrt toolchanger”
[16:24:09] <mozmck> cradek: the suggestions were good! we may actually wind up using only the NO_PROBE_HOME_ERROR
[16:25:40] <andypugh> Hmm, if you were _very_ short of inputs you could probably risk using a shared limit switch for a probe input. But on further reflection, if you were desperate enough to do that, you could configure it that way in HAL.
[16:28:19] <mozmck> yep, homing aborts a jog, and trying to jog while homing will report and error
[16:28:31] <mozmck> an error
[16:38:35] <KGB-linuxcnc> 03Moses McKnight 05master 90b5d85 06linuxcnc 10(6 files in 4 dirs) Added ini settings to disable probe errors while jogging and homing. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=90b5d85
[16:38:42] <cradek> sweet
[17:33:12] <linuxcnc-build> build #1925 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1925 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[17:45:12] <cradek> +ERROR: unknown command 65
[17:45:33] <cradek> hmm, I do think this is actually a real error
[17:47:05] <jepler> I have an armhf handy, I'll see if I reproduce it
[17:47:15] <cradek> nah, I see it already
[17:47:19] <cradek> working on a fix
[17:47:26] <jepler> OK
[17:47:32] <cradek> thanks though
[17:47:44] <jepler> since that was the only error so far I wondered if it was a weird platform-specific thing
[17:48:18] <linuxcnc-build> build #3732 of 1300.rip-precise-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3732 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[17:48:21] <cradek> pretty sure it's just a missing case in motion-logger
[17:48:25] <cradek> haha yep
[17:48:40] <jepler> will you make motion-logger just not print it?
[17:48:48] <jepler> or will you update all the testcases?
[17:48:51] <cradek> I think I'll print it and accept the new results
[17:49:29] <linuxcnc-build> build #3734 of 1306.rip-precise-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3734 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[17:49:48] <jepler> ah there's the next one
[17:49:54] <jepler> thanks cradek
[17:50:02] <cradek> np
[17:50:05] <jepler> I guess we all failed to run the tests before pushing that to master branch :-/
[17:50:18] <cradek> yay buildbot!
[17:50:31] <jepler> (I know I didn't even apply the patch anywhere)
[17:54:32] <KGB-linuxcnc> 03Chris Radek 05master 638aba7 06linuxcnc 10src/emc/motion-logger/motion-logger.c 10tests/motion-logger/basic/expected.builtin-startup 10tests/motion-logger/mountaindew/expected.motion-logger Teach motion-logger about the new message, and fix tests accordingly * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=638aba7
[17:56:02] <linuxcnc-build> build #2942 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2942 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[18:25:12] <linuxcnc-build> build #1403 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1403 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[18:26:35] <linuxcnc-build> build #1892 of 1400.rip-wheezy-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1892 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[18:28:25] <linuxcnc-build> build #1893 of 1403.rip-wheezy-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1893 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[18:29:18] <linuxcnc-build> build #2084 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2084 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[18:40:05] <linuxcnc-build> build #1558 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1558 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[18:42:05] <linuxcnc-build> build #360 of 1502.rip-jessie-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/360 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[18:47:03] <linuxcnc-build> build #360 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/360 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[18:47:24] <linuxcnc-build> build #360 of 1501.rip-jessie-rtpreempt-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1501.rip-jessie-rtpreempt-i386/builds/360 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[18:49:08] <linuxcnc-build> build #360 of 1500.rip-jessie-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/360 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[18:49:08] <linuxcnc-build> build #3746 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3746 blamelist: Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>
[19:00:10] <mozmck> Is that a problem in my commit?
[19:01:47] <jepler> mozmck: yes, but cradek already fixed it with his commit 638aba7
[19:02:12] <jepler> mozmck: several tests failed because they did not know about the new message task sends to motion.
[19:02:26] <mozmck> I see. I have never looked at the tests
[19:02:42] <jepler> If you had ". scripts/rip-environment; runtests" you would have seen these failures
[19:02:52] <mozmck> I didn't know what motion-logger was.
[19:03:22] <mozmck> Ah, I don't know if I've done that - at least not for a long time.
[19:03:36] <mozmck> still a lot to learn...
[19:04:14] <jepler> none of us suggested that you do it
[19:04:31] <jepler> it is a slightly time-consuming process, there are several tests that take minutes each to run
[19:06:30] <jepler> often I push my work in progress branch to git.linuxcnc.org with a branch name like jepler/stuff-that-is-just-broken
[19:06:52] <jepler> any branch that is pushed to glo gets checked by buildbot..
[19:11:05] <mozmck> I'll make a note to do the runtests when I make a change like that. I need to learn about the test system too.
[19:13:23] <skunkworks> zlog
[20:21:22] <jepler> seb_kuzminsky: have you said somewhere what the amd64 rtai 5.0 math problem is?
[20:21:54] <jepler> seb_kuzminsky: I didn't get as far as building linuxcnc, so instead I added a call to cos() to the kernel latency test, and it worked...ish
[20:22:02] <jepler> https://emergent.unpythonic.net/files/sandbox/0001-turn-on-FPU-by-default-and-call-a-math-function.patch
[20:22:05] <jepler> cos(pie) = [xbfeffffffffff87c]
[20:22:08] <jepler> >>> struct.unpack("d", struct.pack('Q', 0xbfeffffffffff87c))
[20:22:08] <jepler> (-0.9999999999997864,)
[20:31:39] <jepler> all this on a vm so I'm not paying attention to latency
[20:32:21] <jepler> /root/linuxcnc/src/rtapi/rtapi_math.h: In function ‘atan’:
[20:32:21] <jepler> /root/linuxcnc/src/rtapi/rtapi_math.h:51:1: error: SSE register return with SSE disabled
[20:32:24] <jepler> I guess this?
[20:36:28] <jepler> seb_kuzminsky:
[20:36:28] <jepler> # used for building
[20:36:28] <jepler> RTDIR = /usr/realtime-3.16.0-9-rtai-amd64
[20:36:28] <jepler> RTARCH = x86
[20:36:49] <jepler> so the check for x86_64 to deploy the -msse flag fails
[20:38:02] <jepler> but just being a rhino leaves it still busted
[20:38:02] <jepler> /root/linuxcnc/src/Makefile:719: adding msse like a pro
[20:38:03] <jepler> /root/linuxcnc/src/emc/kinematics/5axiskins.c:1:0: error: -mpreferred-stack-boundary=3 is not between 4 and 12
[20:38:21] <jepler> bbl
[20:44:47] <jepler> WARNING: "sincos" [/root/linuxcnc/src/siggen.ko] undefined!
[20:46:58] <jepler> seb_kuzminsky: # /usr/realtime-3.16.0-9-rtai-amd64/bin/rtai-config --module-cflags
[20:47:01] <jepler> -I. -I/usr/include/rtai -ffast-math -mhard-float
[20:47:08] <jepler> those are pretty bogus flags
[21:15:02] <jepler> Runtest: 172 tests run, 162 successful, 10 failed + 0 expected
[21:15:09] <jepler> among which /home/jepler/src/linuxcnc/tests/realtime-math
[21:17:40] <jepler> though that seems to just be because I haven't gotten "those flags" to Makefile.modinc yet
[21:28:51] <jepler> seb_kuzminsky: so rtai's configure finds these values on amd64
[21:28:51] <jepler> RTAI_TARGET_ARCH='x86'
[21:28:51] <jepler> RTAI_TARGET_ARCH_OPTS=' -msse -mpreferred-stack-boundary=4'
[21:28:51] <jepler> RTAI_TARGET_SUBARCH='64'
[21:29:25] <jepler> but RTAI_TARGET_ARCH_OPTS don't appear in rtai-config --module-cflags
[21:29:36] <jepler> since we're building a new rtai I'm tempted to view this as a rtai-config bug
[22:15:09] <KGB-linuxcnc> 05dgarr/ja10 e4f2f99 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e4f2f99
[22:17:55] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja10v2 488b530 06linuxcnc New branch with 211 commits pushed, 10384 files changed, 0318300(+), 0410941(-) since master/638aba7