Back
[00:02:44] <KGB-linuxcnc> 03Dewey Garrett 05master 5668382 06linuxcnc 10lib/hallib/check_config.tcl 10scripts/haltcl.in 10tcl/tklinuxcnc.tcl 10tcl/twopass.tcl work on support of desktop shortcuts using rip * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5668382
[00:02:45] <KGB-linuxcnc> 03Dewey Garrett 05master 77a5e09 06linuxcnc 10tcl/bin/pickconfig.tcl pickconfig.tcl allow shortcut creation if missing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=77a5e09
[02:25:00] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15tinkercnc commented on issue #107: @andypugh @jepler ... 02
https://github.com/LinuxCNC/linuxcnc/pull/107#issuecomment-233247573
[03:22:26] <KGB-linuxcnc> 03Matsche 05hm2_raspi 6cabb28 06linuxcnc 03src/hal/drivers/mesa-hostmot2/hm2_rpspi.c 03src/hal/drivers/mesa-hostmot2/spi_common_rpspi.h New hostmot2 driver for the Mesa 7i90HD Anything IO Card for the Raspberry2/3 over SPI interface. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6cabb28
[03:22:26] <KGB-linuxcnc> 03Matsche 05hm2_raspi 87ca7a7 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_rpspi.c 10src/hal/drivers/mesa-hostmot2/spi_common_rpspi.h some cleanups... * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=87ca7a7
[03:22:26] <KGB-linuxcnc> 03Matsche 05hm2_raspi 06a85ac 06linuxcnc 10src/Makefile rules for hm2_rpspi added... * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=06a85ac
[03:22:29] <KGB-linuxcnc> 03Matsche 05hm2_raspi 648eb36 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_rpspi.c compiler warning sedation... * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=648eb36
[03:22:33] <KGB-linuxcnc> 03Matsche 05hm2_raspi 7d3167e 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_rpspi.c bugfix * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7d3167e
[03:22:37] <KGB-linuxcnc> 03Matsche 05hm2_raspi c5bcd08 06linuxcnc 03docs/man/man9/hm2_rpspi.9 new man page for the hm2_rpspi hal driver * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c5bcd08
[03:25:11] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #107: This looks pretty good to me. It builds on uspace on Jessie. I pushed the branch to git.linuxcnc.org to let the buildbot chew on it on the other platforms. If it does the right thing on RTAI (ie, not try to build) I think we should merge it. 02
https://github.com/LinuxCNC/linuxcnc/pull/107#issuecomment-233258915
[03:27:58] <tinkerer> seb_kuzminsky: Hi Seb.
[03:30:11] <tinkerer> WOST is a acronym for "Without Source Tree". It's a switch and helps building the driver with halcompile.
[03:39:26] <tinkerer> the function "probe_board" has been borrowed from jepler's hm2_spi.c code and I've left on the part for 7i43.
[04:01:39] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15tinkercnc commented on issue #107: @SebKuzminsky ... 02
https://github.com/LinuxCNC/linuxcnc/pull/107#issuecomment-233270220
[05:57:34] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master 3f1655b 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py Merge branch 'master' into gmoccapy_JA_based_on_master * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3f1655b
[05:57:34] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master 0872758 06linuxcnc 10(5 files in 2 dirs) minor changes to ini and some more comments in gmoccapy.py * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0872758
[05:57:34] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master ebfa647 06linuxcnc 10(5 files in 2 dirs) gmoccapy_JA_master_2.0.21 - support joint jogging * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ebfa647
[05:57:37] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master c080eaa 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into gmoccapy_JA_based_on_master * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c080eaa
[06:36:25] <KGB-linuxcnc> 03Norbert Schechner 052.6 16d8e64 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_6_2_1 - bug in initialize optional stops * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=16d8e64
[06:36:32] <linuxcnc-build> build #1377 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1377 blamelist: Edward Tomasz Napierala <trasz@FreeBSD.org>, Norbert Schechner <nieson@web.de>, Luke Peterson <hazelnusse@gmail.com>, Jeff Epler
[06:36:33] <linuxcnc-build> <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[07:16:09] <skunkworks> zlog
[08:49:24] <skunkworks> cradek, seb_kuzminsky, did you see robs post
https://github.com/LinuxCNC/linuxcnc/issues/68
[09:41:55] <seb_kuzminsky> skunkworks: i saw it, have not read it in detail yet
[09:44:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master b19c7b4 06linuxcnc 10src/Makefile Merge remote-tracking branch 'tinkercnc/hm2_raspi' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b19c7b4
[09:44:53] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #107: This built on all our platforms:
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4385... 02
https://github.com/LinuxCNC/linuxcnc/pull/107#issuecomment-233341583
[09:51:23] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15cradek closed pull request #107: Driver for the Raspberry Pi and the Mesa 7i90HD Anything IO Card over SPI. (06master...06hm2_raspi) 02
https://github.com/LinuxCNC/linuxcnc/pull/107
[10:02:09] <tinkerer> Many thanks to all who supported developing this driver!
[10:03:34] <jepler> tinkerer: congratulations
[10:03:40] <jepler> and thank you for your effort!
[10:03:45] <tinkerer> would it be ok to mention it on the devel list?
[10:03:48] <jepler> sure!
[10:03:56] <tinkerer> jepler: thanks
[10:04:29] <jepler> by the way, is this driver expected to work with pi3?
[10:04:46] <tinkerer> and sorry for the "lost in translation" in the past.
[10:04:52] <tinkerer> yep
[10:05:11] <jepler> I'm sorry for my part in that episode, and I hope we will be able to work together better in the future.
[10:07:14] <tinkerer> I will send you a pm with a link for a updated iso image in the next days for testing.
[10:09:41] <tinkerer> err: sd image
[10:09:51] <jepler> ok. I don't own a pi3 I've been looking for an excuse to purchase one.
[10:13:50] <tinkerer> a Pi3 is always useful in a regular houshold... ;)
[10:16:48] <jepler> I have a pi2 permanently installed in an alarmclock, an odroid u3 permanently installed as a music player and digital picture frame, another odroid u3 with 7i90 perpetually waiting for me to return to that CNC project, a BBB and an original beaglebone in the bottom of a box somewhere, two parallela boards (one never unboxed), ...
[10:16:55] <jepler> so surely what I need is to order more boards with ARM processors.
[10:18:06] <jepler> er I guess "beagleboard", they weren't even calling them "bones" yet
[10:20:32] <archivist> Japs bought ARM announcement today
[10:21:08] <tinkerer> yes, who knows what brings the future:
http://www.phoronix.com/scan.php?page=news_item&px=Japan-Softbank-ARM
[10:21:15] <archivist> http://www.bbc.co.uk/news/business-36822806
[10:26:02] <tinkerer> jepler: ok, I have 1 odroid X, 1 pi1, 2 pi2, 2 pi3, 1 bbb ... ;)
[11:19:11] <jepler> the odroid u3 is so much better for building software than the pi2. the RAM (2GB) and eMMC both really help.
[11:21:29] <seb_kuzminsky> the armhf buildslave in the buildbot is a U3, it's been surprisingly reliable as long as i keep it cool
[11:21:51] <tinkerer> yes, this was the reason for the WOST on the PI :)
[11:22:27] <jepler> even incremental builds are too slow?
[11:22:38] <jepler> .. doesn't make me want to pick up a pi3 very much
[11:23:36] <tinkerer> the main issue on the pi is the ethernet port.
[11:24:48] <jepler> oh?
[11:25:07] <tinkerer> it's usb
[11:25:28] <jepler> same on most ARM SOCs, it seems like. but yes, that makes it useless for hm2-eth.
[11:25:42] <jepler> other than that shouldn't it be OK?
[11:25:43] <CaptHindsight> the Pi3 already works over SPI with the Mesa FPGA
[11:26:20] <CaptHindsight> someone on the ML has it going bu they didn't post any info about the SPI driver and issues they had
[11:26:55] <tinkerer> hah
[11:27:29] <CaptHindsight> tinkerer: the allwinner boards have integrated ethernet but then you don't have accelerated graphics
[11:27:49] <CaptHindsight> since they use Mali
[11:28:54] <CaptHindsight> it makes me ill but the Rpi3 has open gpu drivers so it's about the only ARM board that runs Linuxcnc well and has a GPU to run a GUI fast enough
[11:29:20] <CaptHindsight> but over SPI vs ethernet
[11:29:35] <jepler> pi3 supports glx and OpenGL 1.x ?
[11:30:26] <tinkerer> yes put the spidev driver in linux works not realy well
[11:31:09] <CaptHindsight> I forget, ntulinux looked at it all, he had Linuxcnc working on the orange pi using software rendering using all the extra cores
[11:31:34] <tinkerer> CaptHindsight: do you have link of the "ML" post?
[11:31:50] <CaptHindsight> tinkerer: use the Google :)
[11:32:38] <jepler> linuxcnc's opengl use is really quite simple, it wouldn't take someone familiar with opengl es to port it. but nobody seems to have the right combination of knowledge and motivation.
[11:32:52] <CaptHindsight> https://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf
[11:33:05] <jepler> then it would work on a much wider range of ARM boards with decent performance, and be more future-proof to boot
[11:33:08] <CaptHindsight> the Rpi3 video core data sheet ^^
[11:33:39] <CaptHindsight> Fully supports OpenGL-ES 1.1/2.0 and OpenVG 1.1.
[11:34:20] <tinkerer> CaptHindsight: no I meant "someone on the ML has it going bu they didn't post any info about the SPI driver and issues they had"
[11:34:50] <CaptHindsight> tinkerer: yes, I understood, but you'll have to find the message yourself
[11:35:05] <tinkerer> aha...
[11:36:28] <kwallace> To me OpenGL is like two sharp sticks in the eye. Poor docs, many active old and new versions, semi-proprietary. I could be wrong though.
[11:36:33] <archivist> tinkerer, title is [Emc-users] linuxcnc and raspberry pi3
[11:38:03] <jepler> kwallace: the opengl API is thoroughly documented and most hardware you can put in an x86 PC has linux drivers with good adherence to the spec. but there are many versions of the spec, and many of the well-conforming drivers are proprietary in whole or in part
[11:38:52] <jepler> but the modern standards eliminate a lot of items in old versions that were very convenient for writing simple OpenGL programs
[11:39:17] <tinkerer> archivist: I've thought you know me.
[11:39:47] <jepler> for instance, OpenGL 1.x has the idea of two matrices (called modelview and projection) and provides basic APIs on them to set up standard projections (orthographic, perspective), to perform rotations, to compose matrix operations, etc.
[11:40:10] <jepler> all those things are removed from current versions of OpenGL, and you have to write your own or take someone else's implementation..
[11:40:22] <archivist> tinkerer, I was searching in my local to get the title, not online
[11:44:26] <tinkerer> the "someone" is me :)
[11:45:21] <jepler> (tinkerer is W. Martinjak / matsche, I think)
[11:45:39] <archivist> now...we know
[11:47:17] <archivist> because I had another nick next door with a speed problem on a pi, I thought it was him
[11:47:36] <tinkerer> jepler: Yep
[11:48:09] <archivist> Magnificus next door is on pi iirc
[11:48:41] <tinkerer> but anyway, the reason to write this driver was, testing the direct access to the socs spi regs.
[11:51:37] <tinkerer> and now I will try it with other platforms/socs. ie.: the bbb.
[11:52:10] <jepler> I hope we don't have to make a third copy of hm2_spi and edit it again. Are you familiar with function pointers in C?
[11:53:17] <tinkerer> a bit rusty...
[11:53:25] <jepler> OK
[11:55:08] <kwallace> jepler, From my point of view, it seems very hard for someone to teach themselves OpenGL through Internet searching. It seems one _really_ needs to commit to formal study, which makes for a high bar for dabblers, which are a major force in LinuxCNC. my2c.
[11:55:13] <archivist> function pointers are damned fast. wonderful things
[11:56:31] <jepler> tinkerer: let me take a moment to explain how I imagine it should be possible to support /dev/spidev, rpi, and bbb with a single hm2_spi.c and some good use of function pointers...
[11:56:50] <tinkerer> is there another abstraction layer beyond lowlevel hm2?
[11:56:55] <jepler> tinkerer: in hm2_spi.c take a look at 'static int do_pending'
[11:56:57] <tinkerer> yep
[11:57:11] <jepler> it is specific to spidev, because it says: int r = ioctl(this->fd, SPI_IOC_MESSAGE(1), &t);
[11:58:11] <tinkerer> yep
[11:58:22] <jepler> imagine that instead, it said: int r = this->spi_implementation->perform_spi_transaction(this, SPI_IOC_MESSAGE(1), t);
[11:58:56] <jepler> "this->spi_implementation->perform_spi_transaction" being a function pointer that we arranged elsewhere during setup
[11:59:09] <jepler> the implementation for /dev/spidev will be simple, it just calls ioctl
[11:59:18] <jepler> the implementation for rpi will be more complicated, it will set lots of hardware registers
[11:59:33] <tinkerer> yes i know
[12:01:53] <tinkerer> and we need a appropriate header file
[12:01:55] <jepler> anyway, that is just my idea for how to make a third SPI implementation with less copy and paste, and you're free to do with it whatever you like.
[12:02:31] <jepler> perhaps spidev_open_and_configure would say: if(!strcmp(dev, "rpi")) /* set things up for raspberry pi and return */
[12:03:43] <jepler> and then someone would write this to enable that mode: spidev_path=rpi
[12:06:17] <tinkerer> yes, but would this at this level really a gain?
[12:07:42] <seb_kuzminsky> how much code commonality is there between the two(?) spi hm2 drivers today? the more code could be shared, the bigger the gain
[12:08:13] <tinkerer> I know you want to select the driver automatically
[12:08:35] <jepler> seb_kuzminsky: not much unfortunately
[12:09:51] <jepler> the files are 897 lines together, the diff between them is 696 lines (diff -bU0)
[12:10:59] <jepler> tinkerer: (I am not saying that you must do this, I am saying how I imagine it could be done. It would be better to have a bbb hm2 spi driver that copies code than not have one that would have used function pointers)
[12:11:46] <tinkerer> but managing the different socs in a super driver could be expensive. consider device tree management aso.
[12:12:02] <jepler> I am so far blissfully unaware of device tree
[12:12:03] <tinkerer> yes I've got you
[12:12:20] <jepler> I know it's a thing people on BBB worry about a lot
[12:12:56] <seb_kuzminsky> i think device tree is what you use when you dont have PCI config space
[12:13:15] <tinkerer> it's mandatory for arms in newer kernels
[12:13:38] <tinkerer> or almost
[12:15:27] <jepler> and another way-higher-effort way to approach the problem would be to fix the kernel drivers so they are OK for latency with preempt-rt kernels, which was what I chose to do on odroid u3
[12:15:37] <jepler> then you can just use /dev/spidev API everywhere
[12:15:45] <jepler> but this is all dreaming
[12:16:03] <tinkerer> I will go right into me about all this
[12:18:57] <tinkerer> but consider free time is the dampening part :)
[12:23:09] <mozmck> when using a 7i92 hm2_eth setup, what could cause the message "iptables: No chain/target/match by that name."?
[12:24:04] <mozmck> hm2_eth found the 7i92, but then there was that error and it all quit.
[12:24:21] <jepler> hostmot2 invokes iptables to try to prevent other processes from accessing the ethernet device at the same time
[12:24:44] <jepler> static int shell(char *command) {
[12:24:44] <jepler> char *const argv[] = {"sh", "-c", command, NULL};
[12:24:45] <mozmck> Or maybe that's not why it quit - I think I see another problem in the debug file.
[12:25:01] <jepler> you could change this from -c to -cx to print the actual commands being executed
[12:25:18] <mozmck> ok, what file is that in?
[12:25:33] <jepler> src/hal/drivers/mesa-hostmot2/hm2_eth.c
[12:25:58] <KGB-linuxcnc> 03Norbert Schechner 052.7 a9e4ad1 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_added the bugfix from 1.5.6.2.1, as merge from 2.6 would fail * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a9e4ad1
[12:26:27] <mozmck> thanks jepler.
[12:29:12] <jepler> just guessing that it's the one from clear_iptables, because the others are all followed by a line that prints a message in the case of failure
[12:29:49] <jepler> that would mean you should probably look at the earlier error message if there is one, because maybe the driver is just cleaning itself up at that point; if it didn't create its rule, then clearing the rule will fail.
[12:32:51] <mozmck> I see that could be. Looks like the real problem was something else, but that was the first message I saw in the file.
[12:33:46] <mozmck> So maybe it had not created the rule yet, a different error caused linuxcnc to exit so it gave that message when it tried to delete the rule.
[12:34:00] <jepler> right, I think that's a state of affirs that could occur
[12:35:24] <mozmck> ok, thanks for the help.
[12:35:49] <jepler> hm messages from clear_iptables are redirected to /dev/null though
[12:36:03] <jepler> so either the redirection is wrong or it's a dfferent iptables invocation that errored
[13:03:11] <mozmck> seb_kuzminsky: did you see this post?
https://forum.linuxcnc.org/forum/38-general-linuxcnc-questions/31270-2-7-5-becomes-unresponsive
[13:04:25] <seb_kuzminsky> mozmck: yikes
[13:04:30] <seb_kuzminsky> no, i didnt see that before, thanks
[13:04:56] <mozmck> no problem - I think it was posted this morning.
[13:05:09] <seb_kuzminsky> i'll take a look at it tonight
[13:05:14] <mozmck> yesterday actually.
[13:05:28] <seb_kuzminsky> ok i'll take a look at it yesterday
[13:05:31] <mozmck> :-)
[13:05:45] <mozmck> that means it's as good as fixed now right?
[13:06:52] <seb_kuzminsky> heh i wish
[13:39:36] <jepler> Until we find a fix, the user is in one.
[13:40:44] <seb_kuzminsky> maybe instead of fixing the Abort bug Zultron reported, i should have issued a "known problems" release note in 2.6 and 2.7, and saved the fix for 2.7+1
[13:44:27] <KGB-linuxcnc> 03Jeff Epler 052.7 1553e42 06linuxcnc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1553e42
[13:47:19] <jepler> merge conflict from 2.7 to master over updating-linuxcnc.txt, I'm too tired to try to resolve it
[13:55:01] <skunkworks> I have not seen the pause/stop issue on real hardware - both rtai and rt_preempt./.
[13:55:10] <skunkworks> so far ;)
[14:23:54] <KGB-linuxcnc> 03Jeff Epler 05master b8576c9 06linuxcnc 10src/hal/utils/halcmd_commands.h halcmd: Make this header safe for inclusion from C++ * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8576c9
[14:23:54] <KGB-linuxcnc> 03Jeff Epler 05master 943142f 06linuxcnc 10scripts/linuxcnc.in runscript: remove environment variable related to xlinuxcnc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=943142f
[14:23:54] <KGB-linuxcnc> 03Jeff Epler 05master ba2d365 06linuxcnc 10scripts/linuxcnc.in runscript: Get all rip-environment settings * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ba2d365
[14:23:56] <KGB-linuxcnc> 03Jeff Epler 05master 1e7d6ae 06linuxcnc 10scripts/linuxcnc.in runscript: remove some never-used, never-exported variables * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1e7d6ae
[14:24:00] <KGB-linuxcnc> 03Jeff Epler 05master d86314e 06linuxcnc 10scripts/linuxcnc.in runscript: remove variables now set by rip-environment * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d86314e
[14:24:04] <KGB-linuxcnc> 03Jeff Epler 05master 37ff8b5 06linuxcnc 10lib/hallib/check_config.tcl 10scripts/haltcl.in 10tcl/tklinuxcnc.tcl 10tcl/twopass.tcl Revert "work on support of desktop shortcuts using rip" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=37ff8b5
[16:21:55] <seb_kuzminsky> skunkworks_: you can't reproduce Mike29's "crash on pause" on 2.7.5?
[16:22:02] <seb_kuzminsky> that's disturbing/great
[16:24:14] <skunkworks_> no.. and I used it quite a bit this weekend
[16:42:39] <seb_kuzminsky> hmm, yeah, pause works fine for me with sim/axis/axis in 2.7.5 (standard wheezy-rtai installed off our iso)
[16:49:25] <JT-Shop> I just upgraded my plasma and I hit esc then it would not run after that, rebooted and ran into the limit switch Axis let me check the check box but the power button won't engage so I can jog off of the limit
[16:49:31] <JT-Shop> to 2.7.5
[16:50:36] <seb_kuzminsky> i just tried Esc while running here (2.7.5, sim/axis/axis) and it's fine
[16:50:43] <seb_kuzminsky> curiouser and curiouser
[16:51:39] <seb_kuzminsky> can you turn on debugging in your ini and repro the problem and paste the output?
[16:52:11] <JT-Shop> I have to cut some parts first, I went back to 2.7.4 give me a bit
[16:52:30] <seb_kuzminsky> ok
[17:00:19] <skunkworks_> yeck. should be able to bisect it then
[17:08:01] <mozmck> What do y'all think about the idea of having linuxcnc switch modes automatically based on the command? If a program is executing it would reject a jog or mdi command, but my thought is that if it is idle and gets a jog or mdi command, instead of giving an error because it's not "in the mood", it could just switch to that mode.
[17:09:47] <seb_kuzminsky> i like that idea
[17:10:01] <seb_kuzminsky> and i think it's Task and Motion that should do it, not the UIs
[17:10:23] <mozmck> exactly my idea.
[17:10:36] <mozmck> I don't know if you've been reading the thread on the ML
[17:11:12] <seb_kuzminsky> yeah
[17:11:21] <seb_kuzminsky> i just sent out something to that effect
[17:11:26] <mozmck> jmk's idea of two manual modes is interesting, but my thought is that it could simply be two different jog commands - one for jogging a joint, one for jogging an axis.
[17:11:35] <seb_kuzminsky> well, we have that now
[17:11:53] <seb_kuzminsky> or rather, the one jog command we have specifies if it's a joint-jog or axis-jog
[17:12:01] <seb_kuzminsky> and task passes that on to motion
[17:12:18] <seb_kuzminsky> and motion aborts if it's in the wrong mode for the kind of jog that the ui asked for
[17:12:18] <mozmck> I see - I really have not had time to use JA/master yet.
[17:12:41] <seb_kuzminsky> me neither - i'm playing catch-up and reading as i go
[17:12:47] <mozmck> I see. So with my idea (cmorely's actually I think) it would just switch to the right mood.
[17:13:26] <seb_kuzminsky> i think it could try, but i think sometimes it won't be able to
[17:13:38] <seb_kuzminsky> for example an axis-jog on an unhomed non-id-kins machine should fail
[17:13:59] <seb_kuzminsky> that's the only example i can think of at the moment, but maybe there are more
[17:14:03] <mozmck> Yes, there would still need to be checks and all like that.
[17:14:13] <mozmck> If it's running a program it can't jog.
[17:14:21] <mozmck> or run an MDI command.
[17:14:30] <seb_kuzminsky> yep
[17:14:56] <seb_kuzminsky> but if it finished running a program and a jog command came in, it could switch to manual and do the jog
[17:15:01] <mozmck> The main difference is that the mode switching could be transparent to the GUI.
[17:15:07] <seb_kuzminsky> yeah
[17:15:11] <seb_kuzminsky> pushed down the stack, as they say
[17:15:20] <mozmck> LinuxCNC is currently like a grouchy old geezer who is never in the right mood to do anything.
[17:15:24] <seb_kuzminsky> or is it up? i can never tell
[17:16:17] <seb_kuzminsky> i'm really worried about the crash that Mike29 and JT are seeing :-(
[17:17:02] <mozmck> That does sound worrisome. I have not switched to 2.7.5 yet or I might have seen it too.
[17:20:43] <JT-Shop> which debug 7 or 3
[17:21:02] <seb_kuzminsky> i like 0x7fffffff
[17:21:10] <seb_kuzminsky> "turn on EVERYTHING"
[17:22:48] <mozmck> then send the 16gb file to seb on his cell phone.
[17:30:49] <JT-Shop> http://paste.ubuntu.com/19960227/
[17:31:29] <JT-Shop> tested the limit problem I saw again and could not even check the checkbox to jog off of the switch
[17:31:40] <JT-Shop> terminal and dmesg
[17:32:31] <JT-Shop> line 108 is where I hit the limit switch
[17:32:42] <seb_kuzminsky> yeah
[17:33:34] <JT-Shop> just checked and the GUI is unresponsive to any input
[17:33:41] <seb_kuzminsky> you homed on line 104, how could you hit the limit switch?
[17:34:08] <seb_kuzminsky> (it's still a bug that it becomes unresponsive, no matter how you ran in to the switch)
[17:35:29] <seb_kuzminsky> it looks a bit like
https://github.com/LinuxCNC/linuxcnc/issues/96, but without JA
[17:36:12] <JT-Shop> I restarted Axis and it allowed me to jog off the limit switch, should I try esc
[17:36:46] <seb_kuzminsky> which kins are you using on your gantry?
[17:37:14] <JT-Shop> trivkins, it's a single stepper with a jack shaft
[17:37:21] <seb_kuzminsky> ok
[17:39:56] <seb_kuzminsky> JT-Shop: on sim/axis/axis i can jog into the soft limits all day and it stops where it should without problems
[17:44:09] <JT-Shop> this is a hard limit switch... I don't have my soft limit set correctly as I thought I did
[17:44:32] <seb_kuzminsky> ah, that makes sense
[17:44:51] <seb_kuzminsky> hm, i wonder why i'm not gettin an "override limits" checkbox
[18:06:01] <jepler> seb_kuzminsky: axis is supposed to figure out whether you have any physical limit switches, and show them only in that case
[18:06:11] <jepler> it does it by looking whether certain HAL pins from motion have any connections
[18:06:16] <jepler> maybe it's not checking the right pins now?
[18:06:53] <seb_kuzminsky> i thought that might be the case, so i netted axis.*.{pos,neg}-lim-sw-in to a bunch of nets
[18:07:07] <seb_kuzminsky> those nets are not connected to anything, but i dont think it should be able to tell that
[18:09:05] <seb_kuzminsky> it uses hal.pin_has_writer on those pins
[18:09:55] <seb_kuzminsky> ah, which needs a writer on the signal
[18:09:56] <seb_kuzminsky> ok
[18:11:59] <PCW_> mozmck: did you figure out the iptables issue?
[18:12:39] <seb_kuzminsky> jepler: that did it, thanks
[18:13:11] <mozmck> PCW_: no, I didn't pursue it more because the problem was somewhere else - and I think that was just a by-product of linuxcnc exiting before it was fully running.
[18:14:13] <seb_kuzminsky> JT-Shop: no joy here, if i manually trip a limit switch it doesn't crash, and it lets me check the 'override limits' checkbox, F2, and jog off the limit switch
[18:14:19] <seb_kuzminsky> this is with 2.7.5 and sim/axis/axis
[18:22:57] <JT-Shop> hmm
[18:23:07] <JT-Shop> sure is repeatable on my hardware
[18:46:00] <seb_kuzminsky> please post your config
[18:48:22] <JT-Shop> http://gnipsel.com/files/linuxcnc/plasma.zip
[18:49:53] <seb_kuzminsky> thanks
[18:51:18] <seb_kuzminsky> this has nothing to do with the problem you're seeing, but you should turn the hm2 watchdog timeout down to 2-3x the servo period
[18:52:38] <JT-Shop> so 2 and a bunch of zeros lol
[18:52:52] <seb_kuzminsky> not quite that many zeros
[18:53:49] <JT-Shop> thanks for the tip, I probably just copied and pasted and changed the names to fit
[18:58:10] <PCW_> This is what I get (no other errors printed)
[18:58:11] <seb_kuzminsky> your machine is set up a little different than sim/axis/axis, i'll copy over the differences and see if i can reproduce it
[18:58:12] <PCW_> hm2/hm2_7i92.0: registered
[18:58:14] <PCW_> iptables v1.6.0: can't initialize iptables table `filter': Permission denied (you must be root)
[18:58:17] <seb_kuzminsky> bbl
[18:58:58] <jepler> PCW_: that's .. weird
[18:59:01] <jepler> master?
[18:59:18] <PCW_> yes master
[18:59:19] <jepler> if it's an RIP, can you double check that you did a sudo make setuid?
[18:59:26] <PCW_> i did
[18:59:50] <jepler> I must have loused something up, probably the preparatory work for multiple rtos support. I'll go fire up my test system and test
[19:00:33] <PCW_> this is Mint 18 (based on Ubuntu 16.04) if it matters
[19:01:04] <jepler> hm2_eth has worked on it before today, right?
[19:01:30] <PCW_> no first try, let me try 2.7
[19:02:21] <jepler> OK, let me shut this down .. all-day (no load) latency with xenomai RT: 18.9us
[19:03:58] <jepler> hm2_eth: WARNING: Unable to restrict other access to the hm2-eth device.
[19:04:25] <jepler> oh but
[19:04:25] <jepler> Note: Using POSIX non-realtime
[19:06:03] <jepler> things look fine here, tip of master
[19:06:04] <jepler> $ scripts/get-version-from-git
[19:06:04] <jepler> v2.8.0-pre1-2344-g37ff8b5
[19:06:16] <jepler> 7i92 plus some sserial daughterboards
[19:21:50] <PCW_> 2.7 is the same so maybe mint18/ubuntu 16.04/I screwed something up
[19:29:42] <PCW_> Ahh I think its what mozmck said earlier, a hal file problem
[19:41:04] <PCW_> weirder and weirder 2.7 cant home the y axis
[19:41:27] * seb_kuzminsky squints
[19:49:57] <PCW_> Exception in Tkinter callback
[19:49:59] <PCW_> Traceback (most recent call last):
[19:50:01] <PCW_> File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1540, in __call__
[19:50:03] <PCW_> return self.func(*args)
[19:50:05] <PCW_> File "/home/pcw/linuxcnc-dev/bin/axis", line 2356, in home_axis
[19:50:07] <PCW_> if s.homed["xyzabcuvw".index(vars.current_axis.get())]:
[19:51:04] <seb_kuzminsky> PCW_: which 2.7 is that?
[19:52:19] <PCW_> 2.7.5
[19:52:47] <seb_kuzminsky> grumble
[19:52:51] <seb_kuzminsky> worst 2.7 yet
[19:52:57] <seb_kuzminsky> does 2.7.4 do the same thing?
[19:53:48] <PCW_> let me try
[19:54:12] <PCW_> may be just something borked with Mint 18
[19:54:40] <seb_kuzminsky> JT-Shop: i made a sim config like yours and i still can't repro it :-(
[19:56:16] <seb_kuzminsky> i guess it's not enough like yours, but i don't know what's missing
[19:57:38] <PCW_> I built 2.7 from source (git checkout 2.7) , how would I get 2.7.4?
[19:57:46] <seb_kuzminsky> git checkout v2.7.4
[19:59:10] <PCW_> ok building
[19:59:31] <PCW_> is -jN ok on linuxcnc builds?
[20:00:06] <seb_kuzminsky> yep
[20:00:12] <seb_kuzminsky> it works fine
[20:07:38] <jepler> I couldn't live without -j#
[20:12:38] <PCW_> 2.7.4 wont built on Mint18
[20:12:45] <PCW_> build
[20:17:25] <PCW_> isinf problem
[20:20:17] <PCW_> just trying to debug a stability issue and duplicating hardware/software. but I think I found the stability cure so this is probably academic at this point
[20:25:08] <jepler> oh yeah I remember fixing some build problems lately
[20:25:16] <jepler> it would be nice for the software to work right, not just build
[20:25:29] <jepler> oh yeah that homed thing rings a bell now too
[20:26:19] <jepler> tcl doesn't have a real type system, so the letter for the second axis is inconsistently treated as a true value sometimes ("y"), and in fact it does when retrieving the value from Tcl to Python...
[20:28:50] <seb_kuzminsky> (tcltrollface)
[20:33:58] <PCW_> missing <max linear speed> specifier
[20:34:00] <PCW_> Is this a fatal error?
[20:37:18] <PCW_> OK so master is working now even with the iptables problem
[20:41:07] <jepler> PCW_: in the file share/axis/tcl/axis.tcl I would like you to try two things to do with the Y axis homing problem..
[20:41:13] <jepler> foreach {letter} {x y z a b c u v w} {
[20:41:14] <jepler> radiobutton $_tabs_manual.axes.axis$letter \
[20:41:14] <jepler> -anchor w \
[20:41:14] <jepler> -padx 0 \
[20:41:14] <jepler> -value $letter \
[20:41:31] <jepler> first, try changing '-value $letter' to 'value "$letter"'
[20:42:17] <jepler> alternately, change {x y z ... w} to {"x" "y" "z" ... "w"}
[20:42:26] <jepler> this would count as shaking a stick at the problem
[20:44:42] <PCW_> I will try tomorrow SO is yelling "its time to go home"
[20:44:52] <jepler> I guess I need to toss another hdd in my main dev system to work on these two problems. I can go look whether they show up in debian squeeze, which I know gave seb_kuzminsky a fair number of fits
[20:46:22] <PCW_> different TK/TCL version issue?
[20:48:27] <jepler> yes they upgraded I guess
[20:48:36] <jepler> even tcl changes over time, to everyone's surprise
[22:39:54] <mozmck> Can I make one hal pin point to another in a component? something like: hal->pin1 = hal->pin2;
[22:41:04] <mozmck> pin1 and pin2 being defined as hal_u32_t*
[22:53:28] <seb_kuzminsky> mozmck: i dont think so
[22:53:49] <seb_kuzminsky> each hal_pin_new() is like a malloc(), that allocates storage for that pin
[22:54:04] <seb_kuzminsky> if you move those pointers around i'd expect things to get confused
[22:54:09] <mozmck> that makes sense.
[22:54:12] <seb_kuzminsky> you can copy the *value* of a pin to another, of course
[22:54:30] <seb_kuzminsky> *hal->pin1 = *hal->pin2;
[22:55:03] <seb_kuzminsky> making them point to the same memory location is what halcmd net does
[22:55:33] <mozmck> Maybe that will work. I have a case where if (certaincondition) then *hal->pin1 = value; but if not, then I would need to copy pin2's value to pin1 every run through a loop
[22:56:16] <mozmck> Yeah, but I need to do this inside the component instead of trying to set the hal file up differently