Back
[06:57:00] <KGB-linuxcnc> 03John Thornton 052.7 d1b3c98 06linuxcnc 10docs/src/config/ini_config.txt 10docs/src/gui/gladevcp.txt Docs: add info and links on embedding tabs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d1b3c98
[08:38:06] <KGB-linuxcnc> 03Moses McKnight 052.7 49f3107 06linuxcnc 10lib/python/gladevcp/hal_gremlin.py Fix formatting of hal_gremlin property string, remove extra backslashes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=49f3107
[08:38:06] <KGB-linuxcnc> 03Moses McKnight 052.7 6446523 06linuxcnc 10lib/python/gladevcp/hal_gremlin.py 10src/emc/usr_intf/gremlin/gremlin.py Add another mouse mode 6 to gremlin: l-move, m-zoom, r-zoom * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6446523
[09:59:05] <mozmck> seb_kuzminsky: should I just push my HAL_LightButton widget to 2.7 or to a new branch for review first?
[10:19:53] <memleak> Hi all, since hm2_spi.c includes linux/spi/spidev.h (usermode SPI driver) it doesn't depend on any board specific SPI driver, correct?
[10:21:32] <memleak> POSIX threads are half duplex but SPI requires full duplex, which one does hm2_spi use?
[10:36:00] <KGB-linuxcnc> 03Moses McKnight 052.7 4bbdad0 06linuxcnc 10lib/python/gladevcp/hal_python.xml Fix formatting in hal_python.xml glade catalog file. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4bbdad0
[10:56:13] <jepler> memleak: ioctl SPI_IOC_MESSAGE is full-duplex.
[10:57:03] <jepler> memleak: the kernel /dev/spidev API is what hm2_spi uses, but I found that kernel paches are necessary to make SPI run with realtime guarantees.
[10:58:03] <jepler> https://github.com/jepler/u3-7i90
[10:58:48] <jepler> or as patches
https://github.com/jepler/u3-7i90
[10:59:19] <jepler> so you'd need my first two patches + whatever patches are needed for the device-specific part of the spi implementation
[10:59:31] <jepler> er
http://mid.gmane.org/1410705908-20847-1-git-send-email-jepler%40unpythonic.net
[10:59:45] <jepler> and of course that's all hopelessly old now (3.8)
[11:01:04] <CaptHindsight> other peripherals and features are now working on the A20, the SPI stuff is still a mess
[11:01:16] <memleak> i don't see the actual patches, and yeah i had a feeling full duplex wouldn't work without some hacking at it
[11:01:51] <pcw_home> I suspect you are better off to figure out the low level hardware and talk to it directly
[11:01:55] <CaptHindsight> just giving SPI a try, the actual goal is HM2_eth on ARM
[11:02:10] <CaptHindsight> pcw_home: no docs
[11:02:53] <pcw_home> at least the A10 manual has SPI hardware docs, the A20 is likely the same
[11:03:06] <CaptHindsight> not a major concern, just giving it a try 2 years later
[11:03:20] <memleak> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/spi/spi-sun4i.c
[11:03:20] <CaptHindsight> hme_eth is of more interest
[11:03:32] <memleak> ^that's our docs :)
[11:03:56] <jepler> oh yeah, don't dabble with spi if eth is your goal
[11:04:09] <CaptHindsight> just looking into it
[11:05:11] <linuxcnc-build> build #1424 of 1405.rip-wheezy-armhf is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1424 blamelist: Moses McKnight <moses@texband.net>
[11:05:52] <skunkworks> cradek: rob pushed a fix to bug424 on his git hub. i can't test it atm - later.
https://github.com/robEllenberg/linuxcnc-mirror
[11:06:13] <CaptHindsight> kernel and tool chain for A10/20 is far less of a train wreck now
[11:15:20] <linuxcnc-build> build #3246 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3246 blamelist: Moses McKnight <moses@texband.net>
[11:28:48] <memleak> does hm2_eth work if netfilter is turned off in kernel?
[11:30:01] <memleak> i didn't build the kernel with much networking security except all the IPsec / security hooks
[11:32:08] <memleak> so iptables is 100% NOT functional
[11:35:49] <mozmck> I bet it would work, but have latency issues
[11:36:26] <mozmck> But I'm not expert on that.
[11:36:34] <mozmck> no expert
[11:37:20] <jepler> iirc the main problem is multicast DNS packets being sent on that network interface
[11:37:29] <jepler> I'm not sure what package / configuration setting enables that
[11:37:57] <jepler> you can tcpdump or just watch packet counts on the interface while linuxcnc is not running; if they go up, then you have other stuff using that interface
[11:38:09] <jepler> (also in its current form hm2_eth might not load if it fails to invoke iptables; patch welcome)
[11:39:14] <memleak> noted, thanks guys! and heh i'll probably end up patching it to avoid making a new kernel, will post upon completion
[11:57:58] <mozmck> I think I'll just push this new gladevcp widget. It should be non-disruptive.
[12:00:43] <KGB-linuxcnc> 03Moses McKnight 052.7 7cc5073 06linuxcnc 03lib/python/gladevcp/hal_lightbutton.py 10lib/python/gladevcp/hal_python.xml 10lib/python/gladevcp/hal_pythonplugin.py Add new HAL_LightButton gladevcp widget * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7cc5073
[12:24:21] <linuxcnc-build> build #3237 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3237 blamelist: Moses McKnight <moses@texband.net>
[12:34:33] <mozmck> I don't understand the output for that halui/mdi runtest failure.
[12:38:40] <linuxcnc-build> build #3247 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3247 blamelist: Moses McKnight <moses@texband.net>
[12:40:57] <KGB-linuxcnc> 03Moses McKnight 052.7 ef705b1 06linuxcnc 10lib/python/gladevcp/hal_lightbutton.py HAL_LightButton: Removed extra var, resize button on border width change. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ef705b1
[13:37:05] <skunksleep> cradek: it still violates with the English config that I was using. I was trying to test your config but ran out of time. I could not get it to trip with the pared down gcode. Only with the longer snipit
[13:40:22] <PCW> wonder if it can be worked-around with a naive cam detector setting
[13:42:29] <skunksleep> I wonder if he didn't push all his changes. It looks lin
[14:06:18] <Tom_itx> pcw_home, is your store site down?
[14:06:23] <Tom_itx> can't reach it here
[14:22:28] <Tom_itx> nm, interweb is slow here
[14:35:50] <skunksleep> pcw_home: probably
[16:03:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 fb950a7 06linuxcnc 10tests/halui/mdi/halui.ini 10tests/halui/mdi/test-ui.py tests: give mdi command 0 in the halui/mdi test something to do * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fb950a7
[16:05:38] <mozmck> seb_kuzminsky, I didn't think I had caused that error
[16:55:34] <seb_kuzminsky> heh yeah, you didn't
[16:55:42] <seb_kuzminsky> i'm not sure what is causing it
[16:56:04] <seb_kuzminsky> i think it's a race condition in halui, but i'm not sure
[16:56:34] <seb_kuzminsky> i recently shuffled resources (CPU & RAM) around in the buildbot, that seems to be exacerbating it
[16:57:25] <seb_kuzminsky> the test does kind of a silly thing: the machine starts at X=0, Y=0, Z=0, and the test starts by having halui run an MDI command to "g0 x0 y0 z0" and wait for it to finish
[16:57:56] <seb_kuzminsky> so the test program sets the halui input pin to run the mdi command, then waits for the machine to get to 0, 0, 0, then lowers the halui pin
[16:58:44] <seb_kuzminsky> but since the machine is already there, sometimes (often?) the test program sets the pin high, sees that it's at the end of the g0 x0 y0 z0 move, then sets the pin low again, before halui has time to notice that the pin went high
[16:59:09] <seb_kuzminsky> that should be a harmless thing to have happen, but....
[17:03:29] <seb_kuzminsky> halui does kind of an unsafe thing where it inspects its hal pins, then later makes a non-atomic copy of them all and uses that as its memory of what the hal pins were next time around
[17:04:12] <seb_kuzminsky> i wonder if this is related to the dropped mdi problem we see intermittently on the linuxcncrsh tests?
[17:05:48] <cradek> I thought someone fixed that in halui already (and that's why it looks so weird)
[17:06:52] <seb_kuzminsky> i've fixed a couple of mdi-related problems in halui recently
[17:10:20] <seb_kuzminsky> err, i guess it was just one bug i fixed, related to mode setting after mdi finishes
[19:00:11] <JT-Shop> oh darn the build warnings are back for hostmot2.9
[19:25:55] <seb_kuzminsky> in 2.7 or just in 2.6? you fixed them in 2.7, right?
[22:49:58] <mozmck> In Axis there is code like this for pause and resume:
[22:50:00] <mozmck> if s.task_mode not in (linuxcnc.MODE_AUTO, linuxcnc.MODE_MDI):
[22:50:00] <mozmck> return
[22:50:00] <mozmck> ensure_mode(linuxcnc.MODE_AUTO, linuxcnc.MODE_MDI)
[22:50:00] <mozmck> c.auto(linuxcnc.AUTO_RESUME)
[22:50:58] <mozmck> It seems like the ensure_mode is redundant - or am I missing something?
[22:52:02] <mozmck> Not just pause and resume, but that's what I happened to be looking at. The same idea was copied over into hal_actions as well.