Back
[00:21:27] <KGB-linuxcnc> 03chris morley 05panelui e22c0b8 06linuxcnc 10src/hal/components/panelui.c panelui: fix compiler warning in the C component * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e22c0b8
[02:36:26] <linuxcnc-build> build #3774 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3774 blamelist: chris morley <chrisinnanaimo@hotmail.com>
[02:37:52] <linuxcnc-build> build #3776 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3776 blamelist: chris morley <chrisinnanaimo@hotmail.com>
[02:45:36] <linuxcnc-build> build #2984 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2984 blamelist: chris morley <chrisinnanaimo@hotmail.com>
[03:06:57] <linuxcnc-build> build #3788 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3788 blamelist: chris morley <chrisinnanaimo@hotmail.com>
[07:44:40] <jepler> weird, I would have said I was sure I'd merged my streams stuff to master branch
[07:44:55] <jepler> I wonder what was wrong with it when I last touched the project in september or so...?
[07:45:15] <jepler> linuxcnc-build: force build --branch=jepler/hal-streams 0000.checkin
[07:45:16] <linuxcnc-build> build forced [ETA 1h46m40s]
[07:45:16] <linuxcnc-build> I'll give a shout when the build finishes
[07:49:03] <linuxcnc-build> build #38 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed install-missing-build-dependencies compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/38
[08:22:32] <linuxcnc-build> build #1968 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/1968
[08:24:15] <linuxcnc-build> build #3789 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3789
[09:15:17] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja10v4 9ab1ed6 06linuxcnc 10src/emc/usr_intf/keystick.cc keystick.cc incorporate jogging fixes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9ab1ed6
[09:15:17] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja10v4 e3798af 06linuxcnc 10src/emc/usr_intf/keystick.cc keystick.cc enforce use of trivkins (joints_axes) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e3798af
[09:54:34] <jepler> there's also an intermittent failure I observed in test stepgen.1 twice
[09:54:47] <jepler> but now it hasn't come back out to play for 200 iterations of that test
[10:02:00] <seb_kuzminsky> jepler: thanks for fixing those guis a little bit
[10:14:56] <jepler> hypothetically, if a user got permission to distribute an Ubuntu ISO "on the Linuxcnc.org web site" (but by implication not from any other website), would we want to host this ISO?
[10:16:09] <jepler> I would be reluctant, because e.g., Debian and the Free Software Foundation identify the freedom to redistribute copies as core freedoms.
[10:16:23] <jepler> apparently the quoted wording above is what Tim March asked Ubuntu to allow.
[10:17:15] <jepler> .. software which only Debian has permission to distribute can't even go in non-free
[10:23:34] <jepler> linuxcnc-build: force build --branch=jepler/hal-streams 0000.checkin
[10:23:35] <linuxcnc-build> build forced [ETA 1h17m17s]
[10:23:35] <linuxcnc-build> I'll give a shout when the build finishes
[10:24:01] <jepler> I saw the stepgen.1 failure twice before changing branches; zero times since changing to master branch and back to jepler/hal-streams
[10:24:11] <jepler> I wonder whether I was not fully built the first time or something
[10:24:19] <jepler> I've done ~1000 trials now with no failures
[10:25:23] <linuxcnc-build> build #40 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed install-missing-build-dependencies compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/40
[10:56:27] <jepler> .. 643 iterations of all 3 stepgen.* tests since I started counting, right after the 1000 trials claim
[11:08:08] <Roguish> jepler:: re github. go for it.
[11:09:56] <Roguish> seb_kuzminsky: re website and bugtracking go for it.
[11:10:08] <seb_kuzminsky> cool :-)
[11:17:40] <mozmck> jepler: I don't think March's ISO is even an Ubuntu ISO - it's just a set of installation scripts and packages for linuxcnc.
[11:17:57] <Roguish> and once again, THANK YOU GUYS FOR ALL THE WORK.
[11:18:22] <mozmck> As far as I can see, there was no need to ask Canonical anything.
[11:18:31] <jepler> mozmck: I saw that being said, and I haven't looked at what he has done, but I don't understand why that would *be* an ISO, instead of being more like the old install.sh we used to have
[11:19:22] <jepler> EXCEPT IF the goal is to support unnetworked installations, in which case it would most likely need to include ubuntu packages not on the official ubuntu install media (e.g., we depend on tcl/tk but that's not in the base system)
[11:19:35] <mozmck> I'm not sure I do either - unless he is including the linuxcnc pacakges and maybe some dependency packages on it as well. It is not a bootable CD I'm pretty certain.
[11:19:49] <jepler> the bootability doesn't matter
[11:20:20] <jepler> it matters whether there are Canonical/Ubuntu trademarks inside
[11:20:40] <mozmck> True, but even if packages from Ubuntu are included, I'm fairly sure that unless the packages included have Canonical IP then no permission is needed.
[11:20:51] <mozmck> i.e. what you just said :-)
[11:21:15] <cradek> but I understand there's no list of which packages *they think* contain their IP
[11:21:31] <jepler> cradek: canonical/ubuntu has not provided a list of such packages
[11:22:01] <jepler> https://help.ubuntu.com/community/Repositories
[11:22:17] <jepler> of course if you take their Community wiki at its word, packages in main "can be freely redistributed"
[11:22:49] <jepler> so, dear ubuntu: are the packages in main subject to a restrictive license or can they be freely redistributed
[11:23:47] <jepler> .. do they conform to the ubuntu free software philosophy that users "should have the freedom to [] distribute [] for any purpose without paying licensing fees"?
http://www.ubuntu.com/about/about-ubuntu/our-philosophy
[11:23:59] <jepler> problem detected: corporation wants to "have it both ways"
[11:24:57] <mozmck> heh, maybe two different guys writing the two documents?
[11:24:59] <jepler> http://www.ubuntu.com/about/about-ubuntu/licensing ah here's the non-Community page that makes it clear that software in main "must allow redistribution"
[11:25:47] <jepler> > Must not be distributed under a licence specific to Ubuntu. The rights attached to the software must not depend on the program being part of Ubuntu system. So we will not distribute software for which Ubuntu has a "special" exemption or right, and we will not put our own software into Ubuntu and then refuse you the right to pass it on.
[11:27:58] <mozmck> I think the main thing they don't want is someone making a customized distribution and calling it Ubuntu
[11:28:09] <jepler> that may or may not be their intent
[11:28:44] <CaptHindsight> control the Ubuntu name
[11:28:52] <jepler> the *wording* of
http://www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy is much broader than what you stated
[11:29:48] <jepler> > You can redistribute Ubuntu, but only where there has been no modification to it.
[11:30:12] <jepler> vs "freedom to distribute for any purpose"
[11:31:04] <jepler> which, for software from main, also includes "Must allow modification and distribution of modified copies under the same licence"
[11:31:40] <mozmck> Section 3 expands that statement though: Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks.
[11:32:14] <mozmck> Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries.
[11:32:47] <jepler> but the real question in my mind is not "would we be *IN THE RIGHT* to redistribute software from Ubuntu Main" but "if Canonical sends a C&D letter, what will we do -- mount a legal defense or knuckle under"
[11:33:10] <mozmck> It is not clear if the recompile is only part of removing trademarks or not.
[11:33:19] <jepler> mozmck: yes I am familiar with those words in the intellectual-property-policy document
[11:33:36] <jepler> mozmck: but that flatly contradicts the claimed license properties of ubuntu main
[11:33:54] <jepler> but ultimately, my desire is to not risk getting a letter from a lawyer
[11:34:16] <mozmck> I understand that!
[11:34:51] <jepler> > Ubuntu is an aggregate work; this policy does not modify or reduce rights granted under licences which apply to specific works in Ubuntu.
[11:35:23] <archivist> have they ever written such a letter, it would kill their business as well as the recipient
[11:35:43] <jepler> so while I'm arguing *for* redistributing stuff from Ubuntu main, I'd say that they have given me separate assurance about that software, namely that these problems don't exist
[11:38:36] <mozmck> I hope I don't sound like I'm arguing either way. Trying to understand it all myself. I just didn't think March needed to ask permission for what he is doing AFAIK.
[11:40:17] <mozmck> I'd say it's definitely more of a problem to distribute a customized live CD based on ubuntu - yuck! I need to read the Debian terms more closely as well, but I remember they seemed a lot more relaxed.
[11:41:00] <jepler> Debian main and ubuntu main rules are superficially very similar
[11:42:05] <jepler> https://micahflee.com/2013/11/canonical-shouldnt-abuse-trademark-law-to-silence-critics-of-its-privacy-decisions/
[11:43:58] <jepler> that's the only C&D letter evidence I can find, and it's from 2013 and not about a software distribution as such
[11:44:01] <jepler> https://lists.ubuntu.com/archives/ubuntu-community-team/2015-May/000422.html
[11:44:16] <jepler> here's a nice long thread about the apparent conflict between the policies for software in "main" and the iprights document
[11:52:06] <linuxcnc-build> build #3791 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3791
[11:52:39] <jepler> my own test failed at iteration 1257 in stepgen.1
[11:52:51] <jepler> so ugh, a less than one in 3000 bug in streamer/sampler :-(
[11:53:45] <jepler> 0 0 1059
[11:53:45] <jepler> 1 0 1060
[11:53:45] <jepler> 1 0 1060
[11:53:45] <jepler> 1 1 1061
[11:53:46] <jepler> 0 1 1061
[11:53:48] <jepler> 0 1 1062
[11:53:50] <jepler> well this is sure wrong
[11:53:55] <jepler> first two columns are quadrature outputs of stepgen
[11:54:05] <jepler> third column is stepgen position feedback
[11:54:19] <jepler> the outputs change from 11 to 01 without counting a step
[11:54:36] <skunkworks> yikes
[11:54:58] <skunkworks> a bug in sampling or a bug in stepgen?
[11:55:00] <archivist> ew does that explain some thing I have seen
[11:57:01] <jepler> skunkworks: I don't know yet
[11:57:58] <jepler> at the end of the test everything looks OK, the expected 1280 steps are counted and reported
[11:58:40] <jepler> but in this one case over 3500 cycles of the test there's a 1-period delay in seeing the stepgen "counts" reflected in the sampler
[11:59:40] <jepler> the test uses just one thread for stepgen and sampler
[13:11:28] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 3c4729f 06linuxcnc 10(5 files) tests: verify that the exported realtime math functions exist, except for round() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3c4729f
[13:13:24] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 392c463 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=392c463
[13:26:43] <KimK_laptop> jepler, mozmck: I haven't read back all the way on your Ubuntu IP discussion, but is this a situation similar to Firefox/Iceweasel? Is it necessary (that is, would it help) to convert Ubuntu to "Non-buntu"(?), in a way similar to the Firfox/Iceweasel situation?
[13:27:46] <mozmck> KimK_laptop: It's not necessary, we can just use Debian instead ;-)
[13:29:29] <KimK_laptop> OK, that works.
[13:30:37] <mozmck> but it appears that if we were to want to use ubuntu as a base, we would have to remove all ubuntu trademarks, which would likely be non-trivial
[13:30:56] <mozmck> and possibly re-compile all binaries?
[13:32:31] <mozmck> wow, after reading most of the thread jepler posted we finally get a partial answer anyhow:
https://lists.ubuntu.com/archives/ubuntu-community-team/2015-May/000478.html
[13:35:16] <mozmck> If that is really accurate either I don't know. Seems as though Redhat's terms are at least as restrictive as Ubuntu's
[13:39:58] <KimK_laptop> Yes, isn't that (the trademark-removal-and-substitution process) what happens with RedHat -> to -> CentOS, maybe others too? I wonder if other people for other purposes would also be interested in a Nonbuntu distribution?
[13:40:42] <mozmck> Well, that's what Mint and elementary are, but at least Mint has similar terms.
[13:41:16] <mozmck> I bet starting from Debian like this project has done is the easiest.
[13:48:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/rtai5 9f19425 06linuxcnc 10scripts/rtapi.conf.in 10src/configure.in 10src/module_helper/module_helper.c stop looking for the rtai_shm module, it hasn't existed for years * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9f19425
[13:48:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/rtai5 2c5218a 06linuxcnc 10scripts/realtime.in realtime script: detect RTAI correctly * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2c5218a
[13:48:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/rtai5 9d6291c 06linuxcnc 10debian/configure debian: accept the 3.16.0-9-rtai linux/rtai kernel * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d6291c
[13:48:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/rtai5 0df9238 06linuxcnc 10debian/configure debian: accept the new style of rtai-modules package name * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0df9238
[13:48:52] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/rtai5 677ae2b 06linuxcnc 10src/Makefile.inc.in 10src/configure.in 10src/hal/Submakefile handle building with lxrt.so (RTAI 4.1 and newer) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=677ae2b
[13:48:56] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/rtai5 75a626a 06linuxcnc 10src/rtapi/rtai_rtapi.c rtapi: teach rtai_rtapi about renamed RTAI constant * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=75a626a
[13:49:00] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/rtai5 77ee408 06linuxcnc 10src/Makefile 10src/Makefile.modinc.in build system: all versions of RTAI need -msse for math * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=77ee408
[13:49:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/rtai5 cca64c0 06linuxcnc 10scripts/rtapi.conf.in 10src/configure.in 10src/rtapi/rtai_rtapi.c teach build system & rtapi about RTAI 5 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cca64c0
[13:49:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/rtai5 4298f0f 06linuxcnc 10tests/symbols.0/test_define.comp 10tests/symbols.0/test_use.comp tests: fix a compiler warning that fails this test on Jessie * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4298f0f
[13:49:13] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/rtai5 672dd0a 06linuxcnc 10scripts/platform-is-supported buildbot: this branch works under Jessie's RTAI (5.0-test1) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=672dd0a
[13:49:25] <seb_kuzminsky> jepler: i think that new branch (seb/2.7/rtai5) addresses all your comments on the rtai5 support
[14:08:54] <jepler> seb_kuzminsky: thanks, ping me if I don't say I've taken a look at it
[14:09:10] <jepler> just reaching 5000 tests of stepgen.[012] on x86_64 uspace with no errors
[14:09:26] <jepler> on arm, a failure in stepgen.2 after an additional 1412 iterations
[14:19:21] <seb_kuzminsky> still a lurking arm memory order bug?
[14:21:29] <jepler> that would seem to be the default assumption
[14:24:28] <jepler> stepgen.2 counts the number of times the "step" pin was asserted in a stepgen instance that was told to go 1280 steps
[14:24:35] <jepler> in the failed test, it went 1279 steps instead
[14:26:22] <jepler> in this run, the last step pulse is observed at iteration 3381; the test logs 3500 iterations
[14:27:23] <jepler> but it appears the actual problem may be a lost step around iteration 2773
[14:28:39] <jepler> so unfortunately yes, it looks like a memory order bug
[14:29:47] <pcw_home> possibly, but whether the extra information is of any real use is debatable
[14:32:26] <jepler> on reflection, both test failures that I've captured could be due to reading zeroes instead of the value that should have been stored in the stream. In the case where I said "the outputs change from 11 to 01 without counting a step", it's the 0 that is spurious, not the step count
[14:32:44] <pcw_home> oops
[14:35:49] <seb_kuzminsky> cradek: zultron reminded us on emc-developers to merge g52, any objections?
[14:42:19] <jepler> seb_kuzminsky: I think he may be on the lam today
[14:42:29] <jepler> er that's not the right word
[14:47:13] <mozmck1> I'm getting a realtime error every time I start linuxcnc ja10v3 2.7 has no such problem so I wonder what is different?
[14:52:02] <jepler> umm I finally sat down and read the code
[14:52:09] <jepler> .. I didn't write the atomic ops into the refactored code at all
[14:54:18] <mozmck> Of course, I also get a following error if I try to jog or home any axis, so I have something wrong in my config I guess.
[15:02:43] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams 788558b 06linuxcnc 10src/hal/hal_lib.c WIP oops forgot the atomics * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=788558b
[15:08:29] <seb_kuzminsky> yay
[15:22:52] <jepler> mozmck: sim configs from the tree, or other configs?
[15:23:44] <mozmck> hand modified configs from ones that work on 2.7
[15:26:13] <skunkworks> mozmck: you used the converter to convert the config to JA?
[15:26:33] <skunkworks> (I have not played with JA in quite a while)
[15:26:46] <mozmck> No, I modified by hand. Used the wiki page here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?JointAxesBranch
[15:28:41] <skunkworks> did you try the converter? It runs when you use the config picker
[15:29:06] <mozmck> No, my hal file is tcl so I figured that would not work well.
[15:29:29] <skunkworks> ah
[15:30:24] <mozmck> I also have sample configs I'm looking at as well.
[15:37:37] <mozmck> here's my "hal" tcl file:
http://pastie.org/10649864
[15:38:57] <mozmck> and ini file:
http://pastie.org/10649867
[16:02:37] <cradek> seb_kuzminsky: oh did I miss something? I thought he was going to squash some stuff (and I assumed do the merge), but it's totally fine with me if we do it as-is
[16:03:25] <cradek> I think cradek/zultron/g52 would be the one to take
[16:08:28] <cradek> rebase was easy; running tests
[16:09:40] <cradek> er no, I porked it
[16:14:23] <cradek> ouch, git rerere is biting me
[16:14:31] <cradek> stop it stop it
[16:18:13] <skunkworks> heh
[16:18:37] <skunkworks> he just pushed something - didn't he? (within the last few days..)
[16:21:32] * cradek pokes at the C++ with a stick
[16:34:16] <jepler> seb_kuzminsky: is this one unneeded after fixing rtai right? build system: all versions of RTAI need -msse for math
[16:35:13] <jepler> otherwise looks good
[16:37:17] <KGB-linuxcnc> 03John Morris 05master f95bf31 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc interp_convert.cc: noop: wrap ridiculously long lines * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f95bf31
[16:37:17] <KGB-linuxcnc> 03John Morris 05master 2177805 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc interp_convert.cc: use readable symbols for `switch(g_code)` * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2177805
[16:37:17] <KGB-linuxcnc> 03John Morris 05master 5fc7c5e 06linuxcnc 10(24 files in 6 dirs) Implement G52 offsets * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5fc7c5e
[16:37:18] <KGB-linuxcnc> 03Chris Radek 05master b3e620f 06linuxcnc 10docs/src/gcode/coordinates.txt don't imply something is wrong with using G92 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b3e620f
[16:37:22] <KGB-linuxcnc> 03John Morris 05master 0d12475 06linuxcnc 10(11 files in 3 dirs) fixup: incorporate Chris Radek's feedback * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0d12475
[16:37:26] <KGB-linuxcnc> 03Chris Radek 05master 047b5e2 06linuxcnc 10docs/html/gcode.html add G52 to the quickref * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=047b5e2
[16:37:30] <KGB-linuxcnc> 03Chris Radek 05master a86aeb5 06linuxcnc 10docs/src/gcode/coordinates.txt fix typo * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a86aeb5
[16:37:33] <KGB-linuxcnc> 03Chris Radek 05master 8f98c7e 06linuxcnc 10docs/src/gcode/g-code.txt mention G52 at the G92 summary, too * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8f98c7e
[16:37:51] <jepler> whee thanks zultron
[16:37:51] <skunkworks> Oooh.. awesome
[16:37:59] <jepler> and thanks cradek
[16:38:06] <cradek> welcome
[16:38:11] <cradek> he did the dirty work
[16:38:23] <cradek> I massaged the dirty work
[16:38:32] <KGB-linuxcnc> 03Chris Radek 052.7 7ea2793 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc Fix two error message typos that would lead a user astray * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7ea2793
[16:39:11] <skunkworks> are we still thinking the m98/99 is too intrusive? I played with it a bit and it works as expected (with my memory of writing fanuc programs)
[16:39:56] <cradek> I wonder how he feels about the other branch by now. I have no confidence that I can understand or test the scope of that change.
[16:40:39] <cradek> he recently changed it some more, I think (??) to allow bare Onnnnn at the first line which I guess means something to fanuc
[16:41:31] <skunkworks> That is the commit I remember recently I bet.
[16:42:04] <cradek> if it's widely used and works successfully, I think we should take it. but that mostly depends on zultron's experience, or maybe tormach's experience, and I don't feel like I have much insight into that
[16:42:52] <cradek> I don't know, in general, how much convolution we should add to be compatible with other controls
[16:42:52] <KGB-linuxcnc> 05jepler/hal-streams 788558b 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=788558b
[16:43:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams 424df73 06linuxcnc 10tests/stepgen.1/checkresult make failure more verbose * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=424df73
[16:43:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams 391e1a3 06linuxcnc 10src/rtapi/rtai_ulapi.c rtai: don't hide an informative error message * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=391e1a3
[16:43:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams 773c944 06linuxcnc 10(10 files in 3 dirs) hal: factor out streamer/sampler * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=773c944
[16:43:06] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams eef9f52 06linuxcnc 03docs/man/man3/rtapi_stream.3rtapi hal: document the new C API * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eef9f52
[16:43:10] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams 2b6c8ad 06linuxcnc 10src/hal/halmodule.cc halmodule: factor out to/from python functions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b6c8ad
[16:43:12] <cradek> I bet that way lies madness, but also pragmatism
[16:43:14] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams fdb95c7 06linuxcnc 10src/hal/halmodule.cc halmodule: expose streams to Python * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fdb95c7
[16:43:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/hal-streams 3df5e11 06linuxcnc 10(5 files) tests: test stream interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3df5e11
[16:43:55] <KGB-linuxcnc> 05cradek/zultron/g52 59cf7d3 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=59cf7d3
[16:44:19] <cradek> I wonder if it's polite to also delete zultron/g52
[16:44:34] <jepler> he has push access himself? if so I would leave it for now
[16:44:41] <cradek> yes he does
[19:19:16] <mozmck> Hmm, figured out the following errors
[19:21:11] <mozmck> apparently turning off irq coalescing is not safe on all ethernet cards.
[19:23:03] <mozmck> I think the NIC in the computer I'm using is a marvel chipset, and when I add hardware-irq-coalesce-rx-usecs 0 to the interfaces file I get realtime errors on startup and following errors. After removing that I had to reboot before things worked again - ifup/ifdown did not do it.
[19:23:44] <mozmck> Now my ja10v4 config works basically, but when I try to home the Y axis with 2 joints it moves only one joint.
[19:40:34] <andypugh> Does it “think” it is moving both joints?
[19:40:59] <andypugh> (joint.N.motor-position-cmd changing)
[20:38:18] <jepler> is there a sim gantry configuration you can check to see how its homing is configured?
[20:47:30] <mozmck> I have the config from guymalpass on the forum here:
http://forum.linuxcnc.org/forum/49-basic-configuration/30033-w-axis-with-gantry-kins-hal-ini-configuration?start=30
[20:48:48] <mozmck> He said he had gantry auto-squaring working, maybe I didn't get something quite right. I did do an MDI command on Y and both axes moved, but jog and home moved only one side.
[20:51:04] <mozmck> Maybe he is homing each side separately somehow? Maybe that's where the synchronized homing is still needed. My jogging may not be putting it in teleop mode - not sure.
[20:59:35] <jepler> Subject: [ANNOUNCE] 4.4-rc6-rt1
[21:00:04] <jepler> >> If your machine starts blinking like a
[21:00:08] <jepler> christmas tree while using the patch then *please* send a photo.