Back
[07:40:42] <jepler> huh. (A) I didn't know about linuxcnc -k, which apparently continues even if halcmd fails in whatever way (B) there is no convenient way to test "two pass tcl" outside of the linuxcnc run script and so of course (C) there are no such tests
[10:51:17] <skunkworks> zlog
[11:46:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 843ae2d 06linuxcnc 10docs/html/gcode.html docs: fix a typo * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=843ae2d
[12:30:40] <seb_kuzminsky> jepler, cradek: i fixed the linux-image and rtai-modules jessie debs on highlab
[12:30:59] <seb_kuzminsky> i'll try not to break them again...
[12:31:03] <seb_kuzminsky> at least not today
[14:06:40] <jepler> seb_kuzminsky: thank you
[14:47:32] <seb_kuzminsky> remove any old rtai-modules-3.18 debs you have installed and install the latest one, rtai-modules-3.18.0-1_5.0~test2.2016.05.12.31.gbf15f9b
[14:49:42] <skunkworks> right now?
[14:49:52] <skunkworks> ;)
[14:50:22] <seb_kuzminsky> http://i.imgur.com/MOjHgoA.gif
[14:50:45] <seb_kuzminsky> to get a consistent kernel + rtai-modules for the uspace+plus testing
[16:00:45] <seb_kuzminsky> interesting, TI has a C compiler for the Beaglebone PRU now:
http://processors.wiki.ti.com/index.php/PRU-ICSS_Getting_Started_Guide
[16:01:02] <jepler> I saw that somewhere recently too
[16:01:10] <seb_kuzminsky> someone... should implement the hm2 stepgen, pwmgen, and quadrature counter modules for it
[16:01:14] <jepler> hah ugh no
[16:01:49] <jepler> though it would be neat if it turned out you could avoid writing a whole new hardware driver that way
[16:02:30] <seb_kuzminsky> hm2_pru would just mmap the part of /dev/mem that has the PRU in it, i think
[16:02:36] <jepler> right
[16:03:12] <seb_kuzminsky> i wonder if my bbb still works, i'm pretty sure i still have it somewhere
[16:03:32] <jepler> I think I know where mine is. but it's way too slow to be a pleasant dev environment..
[16:03:36] <seb_kuzminsky> there's a semi-official 3.8-rt kernel for it
[16:03:50] <seb_kuzminsky> yeah
[16:04:09] <seb_kuzminsky> i think last time i tried, i had to add a bunch of swap (on an SD card) for it to build linuxcnc at all....
[16:04:38] <jepler> I haven't tried lately to figure out what the license is for the PRU development stuff coming out of ti, but the fact that it is not in debian makes me worry
[16:04:50] <jepler> (maybe we had figured that out back in the day but now I'm blocking it out?)
[16:05:47] <seb_kuzminsky> i bet the answer is not good
[16:06:05] <jepler> http://elinux.org/Ti_AM33XX_PRUSSv2#GCC
[16:06:05] <seb_kuzminsky> they ship these self-extracting ".bin" files, not sure what's in them
[16:06:09] <jepler> I wonder how the state of the gcc compiler is
[16:09:05] <jepler> the assembler may just be 3-clause BSD style
https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/utils/pasm_source/pasm.c
[16:09:52] <seb_kuzminsky> heh yeah i just found that one too
[16:10:16] <jepler> but just below there's a paragraph claiming it's also subject to some terms and conditions not shown there..
[16:13:05] <seb_kuzminsky> is the TI PRU C compiler based on gcc?
[16:13:11] <seb_kuzminsky> i dont see it say that anywhere
[16:13:16] <seb_kuzminsky> but it would make sense
[16:32:50] <seb_kuzminsky> i downloaded and installed the ti pru c compiler and it included this:
http://highlab.com/~seb/ti-license.txt
[16:34:03] <seb_kuzminsky> so, no
[16:34:20] <seb_kuzminsky> i think
[16:34:24] <seb_kuzminsky> i am no lawyer
[16:37:27] <seb_kuzminsky> the compiler and other tools, and the example source code they ship with it, are all closed-source and non-redistributable
[17:00:30] <JT-Shop> is there anything that can check for some condition on start up of Axis?
[17:03:45] <seb_kuzminsky> JT-Shop: [DISPLAY]POSTGUI_HALFILE ?
[17:03:58] <seb_kuzminsky> or is it [HAL]?
[17:04:07] <seb_kuzminsky> what condition do you want to check for?
[17:04:43] <JT-Shop> https://forum.linuxcnc.org/forum/21-axis/31246-changing-max-velocity-on-startup#77458
[17:04:53] <JT-Shop> trying to solve his mystery
[17:06:59] <JT-Shop> long sweaty day here shower time :)
[17:07:23] <seb_kuzminsky> your F2 suggestion is good i think
[17:09:46] <seb_kuzminsky> hm, halui's interface for setting max velocity is a little awkward to use for this use case
[17:12:51] <seb_kuzminsky> if .max-velocity.count-enable is True and .counts changes, then the machine's max velocity is updated as follows:
[17:13:21] <seb_kuzminsky> if .direct-value is True, then Max Vel is set to (counts * scale)
[17:14:23] <seb_kuzminsky> if .direct-value is False, then Max Vel is changed by (change in counts * scale), from whatever it was before
[17:14:49] <seb_kuzminsky> so there's no way for halui to be told by F2 to update the maxvel
[17:15:26] <seb_kuzminsky> maybe instead... OP's switch could connect to the select input of a mux, which select 100, 50, or 25 as the mux output
[17:15:47] <seb_kuzminsky> that goes into halui's .count
[17:16:17] <seb_kuzminsky> halui's direct-value is True, and .scale is such that 100 counts is full max vel
[17:16:47] <seb_kuzminsky> hm, then it only changes when you move the switch (which changes the count), which is the problem OP is having
[17:16:50] <seb_kuzminsky> so i didnt help at all
[17:18:14] <seb_kuzminsky> it would be easy to add a "set max vel to this number" input pin to halui, but doing what OP wants with the existing halui pins doesnt look easy :-(
[17:21:11] <JT-Shop> I could not even get max velocity to change in a sim yesterday but I didn't try hard
[17:21:19] * JT-Shop feels much better now
[17:21:54] <JT-Shop> I wonder if you could use a rising edge in classicladder somehow
[17:22:15] <seb_kuzminsky> i don't see how
[17:22:34] <seb_kuzminsky> there are three inputs to halui that cause it to send Set Max Vel commands:
[17:22:41] <JT-Shop> on rising edge of F2 change the max feed number then change it back
[17:22:56] <JT-Shop> just thinking out loud
[17:23:04] <seb_kuzminsky> a change in .count (only if .counts-enable is True)
[17:23:19] <seb_kuzminsky> .increase and .decrease
[17:24:22] <PCW_> change the mux to a channel set to 0 at startup and then restore to user setting
[17:24:55] <seb_kuzminsky> that might work
[17:25:19] <seb_kuzminsky> halui is non-realtime, so depending on the startup delay it might not notice the initial 0
[17:25:49] <PCW_> use a one second one shot
[17:26:17] <seb_kuzminsky> that'll probably work the vast majority of the time
[17:27:45] <PCW_> two seconds for a vaster majority :-)
[17:28:49] <seb_kuzminsky> i mistrust timers like that, but mostly because of timing-related problems in the buildbot's virtual machines
[17:28:55] <seb_kuzminsky> real hardware does much better
[18:00:14] <KGB-linuxcnc> 03Dewey Garrett 05master d118ec4 06linuxcnc 10src/emc/motion/control.c 10src/emc/nml_intf/emc_nml.hh 10src/emc/task/emctaskmain.cc 10src/emc/task/taskintf.cc emctaskmain.cc handle on_soft_limit #96 JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d118ec4
[20:08:59] <skunkworks> heh - 32 bit os won't mount an 18tb volume
[20:58:42] <KGB-linuxcnc> 03Jeff Epler 05master ed79921 06linuxcnc 03scripts/halcmd_twopass.in 10src/Makefile 10src/configure.in halcmd: add "twopass" version as executable script * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ed79921
[20:58:42] <KGB-linuxcnc> 03Jeff Epler 05master 29d5c45 06linuxcnc 10scripts/halrun.in halrun: If an inifile is specified, run it as twopass * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=29d5c45
[20:58:42] <KGB-linuxcnc> 03Jeff Epler 05master 37e6fc4 06linuxcnc 10(5 files) testsuite: basic test of twopass * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=37e6fc4
[21:11:30] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/ickalb-tp-personalities 6f15b79 06linuxcnc 10tcl/twopass.tcl Merge remote-tracking branch 'gh-ickalb/2.6-tp_personalities' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6f15b79
[21:11:31] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/ickalb-tp-personalities 8047337 06linuxcnc 10(5 files) halcmd_twopass: add a basic test of the functionality * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8047337
[21:14:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #91: @ikcalB I have pushed a branch to git.linuxcnc.org that merges this commit to master and then adds a small test of the new functionality. this is branch LinuxCNC:jepler/master/ickalb-tp-personalities which should appear here on github shortly.... 02
https://github.com/LinuxCNC/linuxcnc/pull/91#issuecomment-232840171
[21:15:27] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #108: See #110 for news about this work. 02
https://github.com/LinuxCNC/linuxcnc/pull/108#issuecomment-232840269
[21:17:10] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #93: @ikcalB when I run halshow, what should I look for to see how this patch changes things? do I need to create particular signal names to see a difference? 02
https://github.com/LinuxCNC/linuxcnc/pull/93#issuecomment-232840451
[21:18:20] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler closed issue #96: Task Abort loop on joint soft limit 02
https://github.com/LinuxCNC/linuxcnc/issues/96
[21:19:10] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #76: @SebKuzminsky is your work on this in master branch enough to make you feel this issue can be closed? 02
https://github.com/LinuxCNC/linuxcnc/issues/76#issuecomment-232840679
[21:50:06] <jepler> hey this sounds like it could be the pthread_cancel problem!
http://article.gmane.org/gmane.linux.rt.user/15564 and renewed thread at
http://article.gmane.org/gmane.linux.kernel/2234779
[21:50:55] <jepler> reportedly, a pinned RT process introduces a large latency when it exits
[21:51:23] <jepler> .. large enough to cause a rcu error or a complete hang? ... maybe ?
[21:52:06] <jepler> not sure why it would be different when the whole process is exiting together, instead of just one one thread, though..
[22:38:10] <seb_kuzminsky> jepler: that seems an unbelievably long time for thread exit
[22:54:01] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky reopened issue #96: Task Abort loop on joint soft limit 02
https://github.com/LinuxCNC/linuxcnc/issues/96
[22:55:48] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #96: I dont think d118ec4 is right. Motion *should* abort on soft limit violation, but it no longer does:... 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-232851440
[23:31:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 05issue-96 e2f1c46 06linuxcnc 10src/emc/motion/control.c 10src/emc/nml_intf/emc_nml.hh 10src/emc/task/emctaskmain.cc 10src/emc/task/taskintf.cc Revert "emctaskmain.cc handle on_soft_limit #96 JA" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e2f1c46
[23:31:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 05issue-96 e714101 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis gui: don't set teleop mode in ensure_mdi() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e714101
[23:56:59] <linuxcnc-build> build #497 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/497 blamelist: Florian Kerle <flo.kerle@gmx.at>, Jeff Epler <jepler@unpythonic.net>
