Back
[00:47:25] <linuxcnc-build> build #2248 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/2248 blamelist: Norbert Schechner <nieson@web.de>
[01:40:20] <linuxcnc-build> build #162 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/162 blamelist: Norbert Schechner <nieson@web.de>
[01:40:20] <linuxcnc-build> build #3908 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3908 blamelist: Norbert Schechner <nieson@web.de>
[02:01:20] <linuxcnc-build> build #163 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/163 blamelist: chris morley <chrisinnanaimo@hotmail.com>, Dewey Garrett <dgarrett@panix.com>
[02:20:16] <linuxcnc-build> build #3909 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3909 blamelist: chris morley <chrisinnanaimo@hotmail.com>, Dewey Garrett <dgarrett@panix.com>
[03:01:20] <linuxcnc-build> build #164 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/164 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:01:20] <linuxcnc-build> build #3910 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3910 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:22:20] <linuxcnc-build> build #165 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/165 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:25:34] <linuxcnc-build> build #3899 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3899 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:26:26] <linuxcnc-build> build #3898 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3898 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:26:28] <linuxcnc-build> build #3898 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/3898 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:26:58] <linuxcnc-build> build #3897 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3897 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:27:20] <linuxcnc-build> build #2057 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/2057 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:28:08] <linuxcnc-build> build #2251 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/2251 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:29:11] <linuxcnc-build> build #525 of 1520.rip-jessie-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/525 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:29:58] <linuxcnc-build> build #2058 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/2058 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:30:14] <linuxcnc-build> build #1723 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/1723 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:30:26] <linuxcnc-build> build #1568 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/1568 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:30:39] <linuxcnc-build> build #525 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/525 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:30:43] <linuxcnc-build> build #3108 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3108 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:31:35] <linuxcnc-build> build #525 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/525 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:31:40] <linuxcnc-build> build #525 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/525 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:41:58] <linuxcnc-build> build #2090 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/2090 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:42:29] <linuxcnc-build> build #3903 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3903 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:42:30] <linuxcnc-build> build #3911 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3911 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:08:02] <linuxcnc-build> build #166 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/166 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:22:43] <linuxcnc-build> build #3912 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3912 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:46:57] <linuxcnc-build> build #167 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/167 blamelist: Jeff Epler <jepler@unpythonic.net>
[05:02:40] <linuxcnc-build> build #3913 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3913 blamelist: Jeff Epler <jepler@unpythonic.net>
[07:47:34] <jepler> insmod: ERROR: could not insert module /usr/realtime-3.16.0-9-rtai-686-pae/modules/rtai_hal.ko: File exists
[07:47:41] <jepler> command timed out: 1200 seconds without output running /bin/bash -c 'if [ -f scripts/rip-environment ]; then source scripts/rip-environment; else source scripts/emc-environment; fi; runtests -v', attempting to kill
[07:48:14] <jepler> at least some of those are spurious
[07:48:52] <jepler> but not all of them
[07:49:14] <jepler> *** /home/buildslave/emc2-buildbot/precise-amd64/precise-amd64-sim/build/tests/remap/introspect: FAIL: result differed from expected
[07:57:12] <KGB-linuxcnc> 03Jeff Epler 05jepler/interp-machine-coord 0b4d87a 06linuxcnc 10src/emc/rs274ngc/interp_namedparams.cc 10src/emc/rs274ngc/interp_read.cc 10src/emc/rs274ngc/rs274ngc_pre.cc 10tests/remap/introspect/expected interp: add "machine position" parameters * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b4d87a
[07:57:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/interp-machine-coord bf5c528 06linuxcnc 10docs/src/gcode/overview.txt docs: document machine coordinate parameters * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bf5c528
[07:57:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/interp-machine-coord 896baee 06linuxcnc 03tests/interp/5440/expected 03tests/interp/5440/test.ngc 03tests/interp/5440/test.sh 03tests/interp/5440/test.tbl tests: test "machine position" parameters" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=896baee
[07:58:50] <jepler> [442521.676091] INFO: rcu_preempt detected stalls on CPUs/tasks: { 0} (detected by 1, t=5255 jiffies, g=2534393, c=2534392, q=17933)
[08:01:28] <jepler> seb_kuzminsky: cleanup on aisle ... <looks around for aisle number, fails>
[08:02:01] <jepler> seb_kuzminsky: I wonder whether, since we seem to routinely hit kernel bugs there, you shouldn't offline the jessie-rtai builder(s) :-/
[08:02:43] <jepler> AIUI having the one builder fail means no packages from any builds
[08:22:24] <linuxcnc-build> build #168 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/168 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[08:37:57] <linuxcnc-build> build #3914 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3914 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[08:56:01] <seb_kuzminsky> jepler: i think you're right, unfortunately
[08:56:12] <seb_kuzminsky> either that or actually debug it :-/
[08:57:55] <jepler> all I see in the tracebacks is, one CPU is idle and the other is trying to figure out why something's hung
[08:59:45] <jepler> I wonder if after that flurry it always prints the thing about changing timesource
[09:00:54] <jepler> if so I bet it's a virtualization-related problem
[09:01:10] <jepler> too bad there's not a 'virtualize *time*' option in qemu
[09:09:30] <JT-Shop> I did a git pull on jepler/2.7/hm2-sserial-faults and running it on the BP with no errors
[09:46:54] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes11 37c7aed 06linuxcnc 03configs/sim/axis/canterp_example.can canterp_example.can: omitted in prior update (JA) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=37c7aed
[09:46:54] <KGB-linuxcnc> 03Jeff Epler 05joints_axes11 a10f0dd 06linuxcnc 10src/emc/nml_intf/canon.hh nml_intf: Work around poor c++11 support in g++4.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a10f0dd
[09:46:55] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes11 0f7480f 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py: error if [TRAJ]COORDINATES misconfig (JA) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0f7480f
[09:46:56] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes11 5508cd8 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt updating-linuxcnc.txt consistent JA specifications * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5508cd8
[09:47:01] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes11 f0f6c86 06linuxcnc 10src/emc/usr_intf/pyui/commands.py pyui/commands.py: handle some special configs (JA) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f0f6c86
[10:00:17] <seb_kuzminsky> hmm
[10:00:51] <seb_kuzminsky> new and improved! now, with less jessie-rtai!
[10:01:07] <jepler> :-/ thanks
[10:08:15] <seb_kuzminsky> linuxcnc-build: force build --branch=joints_axes11 0000.checkin
[10:08:16] <linuxcnc-build> build #3915 forced
[10:08:16] <linuxcnc-build> I'll give a shout when the build finishes
[10:08:31] <seb_kuzminsky> off to work
[10:08:35] <seb_kuzminsky> see you all later
[10:57:39] <linuxcnc-build> Hey! build 0000.checkin #3915 is complete: Success [3build successful]
[10:57:39] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3915
[11:36:07] <jepler> linuxcnc-build: force build --branch=jepler/interp-machine-coord 0000.checkin
[11:36:09] <linuxcnc-build> build forced [ETA 49m22s]
[11:36:09] <linuxcnc-build> I'll give a shout when the build finishes
[12:26:38] <maxcnc> jepler: did you got over the problem as i see builds runing on mashine coord
[12:28:20] <jepler> maxcnc: You are welcome to look at what I've done and see whether it meets your needs.
[12:29:29] <maxcnc> i got no system that handels the new builds
[12:29:45] <maxcnc> but shure you made it
[12:30:06] <maxcnc> plasma and remoddelling people wil love it
[12:31:51] <maxcnc> Thanks from all for your work on the system
[12:32:11] <maxcnc> im off here as i dont deserve to be on the davel channel
[12:32:21] <jepler> It won't go in master branch until someone confirms it's useful to them.
[13:08:36] <linuxcnc-build> Hey! build 0000.checkin #3916 is complete: Success [3build successful]
[13:08:37] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3916
[15:33:07] <cradek> jepler:
http://www.fsf.org/news/canonical-updated-licensing-terms
[15:33:17] <cradek> especially interesting is the paragraph starting "Today's"
[15:49:42] <cradek> also "It would be helpful for the FSF..."
[15:49:58] <cradek> they would probably be interested in our story, if someone cares to tell it
[16:33:20] <mozmck> There needs to be a way to put up only one error when the 7i92 card gets disconnected.
[16:35:07] <mozmck> Right now I get an endless stream of notifications "Error Message" "hm2/hm2_7i92.0:error finishing read! iter=1856796"
[16:35:58] <jepler> I don't think hostmot2 in general has a way to deal with an entire lost hostmot2 card
[16:37:22] <jepler> it's somewhere on my stack of not started hm2_eth improvements to deal gracefully with small numbers of lost packets
[16:40:32] <jepler> dealing better with an unplugged or powered off card might fall out of that
[16:40:39] <mozmck> Hmm, I would be willing to work on that if I'm pointed in the right direction! In XFCE it seems the notifications (using gscreen) do not go away either - you have to click each one.
[16:42:43] <jepler> there's llio's io_error
[16:43:23] <jepler> one possibility is that hm2_eth should set it before returning with an error from its functions called by e.g., hm2_tram_read
[16:43:42] <jepler> just like 7i43 does
[16:43:42] <jepler> if (hm2_7i43_epp_check_for_timeout(board)) {
[16:43:42] <jepler> THIS_PRINT("EPP timeout on data cycle of read(addr=0x%04x, size=%d)\n", addr, size);
[16:43:45] <jepler> (*this->io_error) = 1;
[16:45:16] <jepler> that would fix the infinite spew of errors, but it might have to be undone as a first step of handling occasional missing ethernet packets..
[16:47:15] <mozmck> ok, I'll try and look at the code before long. thanks!
[16:48:24] <jepler> good luck! I'll review whatever you come up with, I am probably most familiar with that code atm
[16:48:50] <jepler> I can see it would be inconvenient to end up with 1000 operating system notification pop-ups every second :-/
[21:54:38] <jepler> huh I don't know what was wrong with the forum, but doing a "clear cache" in the admin interface fixed it
[21:54:50] <jepler> there were lots of log errors like
[21:54:50] <jepler> [Mon Jan 25 13:57:58.547767 2016] [:error] [pid 7404] [client 79.161.33.46:59743] PHP Notice: unserialize(): Error at offset 2965692 of 2970227 bytes in /var/www/html/libraries/joomla/cache/controller.php on line 203, referer:
https://www.google.no
[21:55:00] <jepler> and later
[21:55:01] <jepler> [Mon Jan 25 18:20:45.685455 2016] [:error] [pid 11965] [client 207.46.13.27:39366] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 11457906 bytes) in /var/www/html/libraries/joomla/cache/storage/file.php on line 140
[21:55:07] <jepler> so I made a guess..
[22:00:35] <jepler> http://forum.joomla.org/viewtopic.php?f=706&t=888690
[22:00:39] <jepler> no clues from the joomla forum...
[22:01:33] <jepler> you can also find lots of sites with the same problem
https://www.google.com/search?q=%22joomla%2Fcache%2Fcontroller.php+on+line+203%22
[22:01:40] <jepler> bonus: local paths are exposed
[22:24:13] <strokercrate> hiya
[22:25:37] <seb_kuzminsky> oi
[22:26:37] <strokercrate> Hows it going?
[22:34:30] <strokercrate> I have a question in regards to slave axis homing and logic ladder and if what I have an Idea with is possible.
[22:36:29] <seb_kuzminsky> ok
[22:39:42] <strokercrate> Basically I was wondering if you could build a ladder that would allow the system to home on a slave by triggering the step signal to be killed on the slave motor once the first limit is tripped for a set amount of time. Then it reinitializes the slave with a timer and shuts the main drive off and triggers another home for the slaved axis only allowing the slave to auto square? and once done reinitializing the whole ax
[22:39:42] <strokercrate> is that has a slave?
[22:40:41] <seb_kuzminsky> a general scheme like that could probably be made to work
[22:40:59] <seb_kuzminsky> but i wouldn't use ladder for the first attempt personally
[22:41:39] <strokercrate> I tried gantrykins, But for some reason I could not ever get a good rapid without a following error
[22:42:02] <seb_kuzminsky> i doubt that's gantrykins' fault
[22:42:11] <strokercrate> I eventually made the slave a manual home. So i was contemplating this route
[22:42:17] <seb_kuzminsky> gantrykins has some problems, but ferror at rapid isnt one of them afaik
[22:42:34] <seb_kuzminsky> some of us have been batting around an idea similar to yours
[22:43:13] <seb_kuzminsky> whereby you would mark the two gantry joints as being part of a group, and they would proceed through the homing state machine in a kind of lock-step
[22:43:19] <strokercrate> I could only rapid it at about 120ipm.. But without gantrykins with a slave tied to Y through another output pin I can get 500ipm
[22:43:21] <seb_kuzminsky> like you suggested above
[22:44:09] <strokercrate> Yes, WinCNC does something similar to what im contemplating. I was unaware others have been working on it in a similar way.
[22:44:32] <seb_kuzminsky> it's mostly a gleam in cradek's eye at the moment
[22:44:53] <seb_kuzminsky> the work-in-progress is in the synchronized-homing branch, here:
https://github.com/LinuxCNC/linuxcnc/commits/synchronized-homing
[22:46:10] <strokercrate> I wonder why this is difficult in LinuxCNC, But Mach, UCCNC and WinCNC have no problem? Is it because of the linux rtai system?
[22:46:49] <seb_kuzminsky> do you mean why it's difficult to set up an auto-squaring gantry in linuxcnc?
[22:47:29] <seb_kuzminsky> the answer to that is that lots of people run gantry machines (including me), but no one has written the code to do auto-squaring yet
[22:48:12] <seb_kuzminsky> i carefully located my two home switches so that they trip when the gantry is square, then home the two gantry joints together
[22:48:52] <seb_kuzminsky> it accomplishes the same result, but without the nice feature that you and cradek have thought about, where the gantry becomes more square gradually throughout the homing process
[22:49:39] <strokercrate> So basically you are using switches to dead stop a drive?
[22:51:09] <strokercrate> Oh I see what you are doing now, nevermind.
[22:59:42] <seb_kuzminsky> just regular home switches
[22:59:53] <mozmck> strokercrate: there is a component called gantry.comp that will work...
[23:00:55] <mozmck> I've just been working on this stuff, and I am using that for now, because it was going to take too long to get synchronized homing AND joint-axes working for me.
[23:01:21] <strokercrate> I don't think I noticed that in my research.
[23:01:46] <mozmck> but gantry.comp is not in linuxcnc repositories that I'm aware of - I lifted it from machinekit ;-)
[23:02:22] <mozmck> I'll have to find some links.
[23:02:35] <strokercrate> ahh, I have yet to toy with machinekit, Have debated about it with a beaglebone.
[23:03:23] <mozmck> I haven't used it, and I sure wouldn't try it on a plasma table like I'm working with!
[23:04:57] <strokercrate> Just built a plasma using WinCNC, but dang it cost to much.
[23:05:52] <mozmck> gantry.comp has the limitation that when a switch trips it stops that joint immediately (no decel). I looked at it at some length and determined that there is no good way to add decel. But, in practice you can set your homing speed at a decent rate unless your motors are really wimpy.
[23:06:30] <mozmck> I've never used WinCNC.
[23:07:42] <strokercrate> Its a decent system, and the guys that run it are awesome. But the cost, well its heavy at times. I personally love linuxcnc more then the others I have used thus far.
[23:07:52] <mozmck> I think that a sychronized homing is really the way to go. The hal component is a stop-gap measure.
[23:09:05] <strokercrate> Well, a direct stop atm would be a great benefit, even if its a few thousands off in square, most router applications thats not a problem
[23:09:46] <seb_kuzminsky> mozmck: does the output of gantry.comp become the command to a stepgen?
[23:10:02] <seb_kuzminsky> if so you could run it through limit3 to get decel
[23:11:37] <mozmck> limit3? I guess I should look at that. Yes, although I'm using pcw's PID stuff and the stepgen gets the velocity output of the pid
[23:11:54] <strokercrate> I would love to toy with this.
[23:13:02] <seb_kuzminsky> mozmck: i should connect you with Brian Hicks, who contacted me recently about a hy-vfd bug that he had fixed
[23:13:05] <seb_kuzminsky> he was looking at gantry.comp too
[23:14:21] <mozmck> interesting. I worked on it for a while. There is also a version called gantry_latching that is supposed to work better for the homing method I use where it moves off the switch.
[23:15:17] <mozmck> But I could never get that one to work - it would trip all switches and then have a following error. The standard one works well enough though.
[23:16:35] <strokercrate> Do you remember where the info is located, not really finding references in a search
[23:16:47] <mozmck> Let me look again - hold on...
[23:18:10] <strokercrate> think I just found it. lgantry.icomp?
[23:18:38] <mozmck> no - the icomp is a new machinekit thing. It is mostly the same...
[23:20:46] <strokercrate> oh, okay
[23:22:11] <seb_kuzminsky> https://sourceforge.net/p/emc/mailman/message/32654660/
[23:27:07] <strokercrate> The link within to the github turns a 404, a manual search through components shows its not there.
[23:27:52] <seb_kuzminsky> this was the final version of gantry.comp before it became an icomp:
https://github.com/machinekit/machinekit/blob/0e1acad530651837e0c13c704850c69cf2c2acef/src/hal/components/gantry.comp
[23:29:21] <seb_kuzminsky> looks like charles steinkuehler was the only person to commit to it, which agrees with the copyright at the top of the file
[23:29:39] <strokercrate> Awesome Thanks, this gives me something to toy with
[23:30:01] <seb_kuzminsky> let us know what you find out!
[23:30:40] <mozmck> thanks seb - I can look up more stuff tomorrow.
[23:32:18] <strokercrate> Sure will, retrofitting an old camtech now for UCCNC, but will be able to accept Linux as well, so I may use it for Experimentation
[23:32:56] <strokercrate> Anyone ever use UCCNC?