Back
[09:14:52] <cradek> cmorley: have you seen
http://linuxcnc.org/index.php/english/forum/48-gladevcp/28147-no-linuxcnc-widgets-with-wheezy-iso-260pre5#49171
[09:15:20] <cradek> cmorley: do you know if this is a real incompatibility with newer glade, or is it something else wrong?
[09:48:04] <jepler> my experience in another project was that new glade writes out a different format than old glade, without asking
[09:48:11] <jepler> the new format doesn't work with old code
[09:48:23] <jepler> I don't remember the specifics, just that I said "f--- it, I guess I'll never improve this software again"
[09:54:10] <cradek> yargh
[10:12:32] <jepler> what do you expect from the gnome jackasses?
[10:12:48] * jepler is bitchy this morning
[10:19:29] <seb_kuzminsky> code generation tools are awesome, except when they suck, then they're awful
[10:32:23] <seb_kuzminsky> i updated the wiki with the feedback from Andrew (on the list this morning)
[10:32:42] <seb_kuzminsky> every time i touch a wiki page i wish i had vi + git + asciidoc instead
[10:32:57] <seb_kuzminsky> i think for 2.7 we should try putting all the install info in git
[11:09:49] <cradek> I almost have wheel and switches (for running 2.6/touchy) on my sherline
[11:10:21] <cradek> hm, someone should update the actual website
[11:10:58] <cradek> I see there's a thing at the top, but the Download page is still old
[11:12:12] <cradek> I wish we could replace the entire website with the/a wiki, but still keep the forum
[11:14:34] <cradek> hm, do we still have some missing dependencies?
http://linuxcnc.org/index.php/english/forum/9-installing-linuxcnc/28163-released-26#49295
[11:15:11] <seb_kuzminsky> debian jessie will ship with linux 3.16
[11:15:52] <pcw_home> may be a while before RTAI runs on 3.16...
[11:16:24] <jepler> cradek: blt and libtk-img are both listed as build-depends of linuxcnc and as binary dependencies of the main package
[11:16:36] <jepler> .. I checked v2.6.0:debian/control.in
[11:17:13] <cradek> ok, thanks
[11:22:22] <seb_kuzminsky> wow, there's a forum with a ton of people talking about linuxcnc on our website
[11:22:28] * seb_kuzminsky crawls back under a rock
[11:24:05] <cradek> seb_kuzminsky: rss2email works pretty well, except it doesn't give you coherent threads
[11:24:52] <cradek> ... but sorting by subject sort of works
[11:28:43] <lair82> Hello Guys, what is the best route to take to change from master to the new 2.6 release?
[11:29:30] <jepler> lair82: if you are using git, the "git checkout" command is used to select a different branch or tag
[11:29:44] <jepler> https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html
[11:29:59] <jepler> so after a "git fetch", you could "git checkout v2.6.0" so that your source files are exactly the ones that are in the 2.6.0 release.
[11:31:46] <seb_kuzminsky> lair82: are you building from source yourself, or are you using debian packages from the buildbot?
[11:32:22] <lair82> I build from source, would the buildbot be easier?
[11:33:16] <seb_kuzminsky> if you're not actively hacking on the source code, using debs from the buildbot is probably easier (less work for you)
[11:33:37] <seb_kuzminsky> http://buildbot.linuxcnc.org/
[11:33:39] <lair82> I guess my first question should have been, is there any advantage to changing to 2.6 vs just doing a pull on master and running that?
[11:34:17] <jepler> If you are not using any of the features that are in master branch and not in 2.6, using the v2.6.0 release is better
[11:34:28] <seb_kuzminsky> there are some advantages to running 2.6, and some to running master
[11:34:38] <lair82> About the only thing I do to the code is apply the Fanuc tool offset patch,
[11:34:57] <jepler> master branch gets changes that are experimental, and they can either be very important to your goals (e.g., new features) or totally ruin your day (e.g., new features that are buggy)
[11:34:57] <seb_kuzminsky> 2.6 will be more stable, and you wont have to keep track of things that change (ini config changes etc)
[11:35:11] <seb_kuzminsky> master will have new features that might break things from time to time (though we try to avoid that)
[11:35:20] <lair82> Which I know you can't apply patches to anything other than master
[11:35:34] <jepler> you can apply patches to anything
[11:35:40] <lair82> ????
[11:35:41] <seb_kuzminsky> i dont know about the fanuc tool change patch in particular, but most patches should apply to both 2.6 and master
[11:36:10] <seb_kuzminsky> also, there's a sample config in 2.6 (called lathe-fanucy) that implements something like fanuc-style tool offsets without any patch needed
[11:36:42] <jepler> (though I think there's some minor problem with the lathe-fanucy config as we shipped it in 2.6.0; andypugh may recall the details but it looks like he's not here)
[11:37:43] <lair82> That's the reason for my inquiry, is the lathe-fanucy config, we were wondering if this was any improvement over the patch,
[11:40:28] <seb_kuzminsky> lathe-fanucy uses the new g43.2 gcode and remapping to accomplish the same goal as the fanuc tool change patch
[11:40:51] <seb_kuzminsky> but it does so in what we believe is cleaner and more flexible way
[11:41:08] <seb_kuzminsky> it will be part of linuxcnc going forward, without anyone needing to apply any out-of-tree patches
[11:42:51] <jepler> (something we need to figure out is how to offer these things as a "library", rather than copying code into individual configs...)
[11:43:29] <seb_kuzminsky> yes
[11:48:19] <lair82> Might sound like a dumb question, but where do you put the values for the H, is it another column in the tool table? That is what I have been tripping over since chris wrote this code,
[11:50:30] <cradek> I don't understand what you mean by "for the H"
[11:51:13] <cradek> the g43.2 just lets you apply (add in) another tool table entry's offset
[11:51:47] <cradek> so if you want to apply entries from the entries for T1 and T10, you'd do G43H1, G43.2H10
[11:52:24] <cradek> if you want to add up the offsets from entries 1,3,13 you'd do G43H1, G43.2H3, G43.2H13
[11:52:27] <cradek> etc
[11:52:45] <cradek> your remap code for T and/or M6 can do whatever they want
[11:55:48] <cradek> http://www.linuxcnc.org/docs/html/ should now point to 2.6 but they don't
[11:56:26] <cradek> lair82: have you seen
http://www.linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G43_2
[11:56:28] <seb_kuzminsky> i'll fix it
[11:56:33] <cradek> thanks
[11:58:03] <lair82> I understand that, where are the H values stored at?
[11:58:21] <cradek> what do you mean H values?
[11:58:35] <cradek> do you realize H is the tool number?
[11:58:53] <cradek> I still don't understand your misunderstanding, so tell me more
[11:59:04] <seb_kuzminsky> cradek: fixed, thanks for the bug report
[11:59:56] <lair82> Were do you put the offset values, with the fanuc patch, we had to add extra tools to the tool table using 10001,10002,10003, etc to represent the offset values, how is this handled with your code?
[12:00:52] <cradek> wherever you want
[12:00:59] <lair82> ****represent the offset values "tool number" to be applied to the tool****
[12:01:01] <cradek> if you want to continue to use 10001, do that
[12:02:14] <seb_kuzminsky> lair82: i think with the fanuc patch there were special tool numbers that had offsets for specific tools, is that right?
[12:02:49] <seb_kuzminsky> with g43.2 there are no special tool numbers, it just lets the user add the offsets for arbitrary tools together
[12:03:04] <lair82> They weren't specific to a given tool,
[12:03:10] <seb_kuzminsky> ah ok
[12:03:38] <jepler> but whatever T numbers you use, those have to be in the tool table
[12:03:44] <jepler> or they read as zeros I imagine
[12:03:47] <jepler> er, H numbers
[12:04:00] <seb_kuzminsky> still, you might have had some convention like "T1001 is the wear offset for T1"? you can keep using that convention with G43.2
[12:05:03] <lair82> our turning centers have 14 tools, and I have 14 offsets configured in the tool table as well, so we can do a tool call of T0101 and get tool 1, offset 1. Or you could do T0103 tool 1, offset 3,
[12:05:38] <seb_kuzminsky> when you type "T0103", what would the fanuc tool patch do?
[12:06:27] <seb_kuzminsky> it would load T01 and give you a tool length offset of T1 from the tool table plus T10003 from the tool table?
[12:06:55] <lair82> It would apply whatever value is in 10003 ONLY.
[12:08:10] <seb_kuzminsky> strange, i thought the point of the fanuc patch was to add multiple TLOs together
[12:09:10] <lair82> The reason for doing this is say you have a shaft you are turning, and it has 4 Diameters on it, lets say 1", 2", 3" and 4". You write your program to the nominal values, then using 1 Tool T01, and 4 Offsets (1 for each diameter) T0101, T0102, T0103, T0104 You can fine tune each diameter and never mess with the main tool.
[12:09:22] <jepler> so back in January, Chris Morley said "linuxcnc needs GLADE 3.8" (not 3.12)
http://sourceforge.net/p/emc/bugs/352/
[12:09:27] <jepler> but debian 7 does not have 3.8
[12:11:57] <seb_kuzminsky> lair82: if you want to apply the TLO for a specific tool (and *only* that TLO), use "G43 H" and the tool number you want the TLO from, no fanuc patch or G43.2 needed
[12:12:33] <seb_kuzminsky> jepler: whoops!
[12:13:21] <seb_kuzminsky> maybe we should have made a versioned dependency on glade then
[12:13:39] <cradek> I thought the whole point was wear offsets
[12:13:54] <cradek> if you only care about the T0101 gcode command you could have always done that with remap
[12:14:04] <seb_kuzminsky> cradek: that was my understanding as well
[12:14:08] <cradek> I feel like I don't have the whole story here
[12:15:35] <cradek> well it doesn't matter. you can do ANY of those things, plus many more, in 2.6 now.
[12:18:14] <CaptHindsight> lair82: did you have the asrock fm2a88m-hd+ ?
[12:18:37] <CaptHindsight> with the A4 4000
[12:19:22] <lair82> Using the TXXXX tool call is a seperate issue, which I see can be remapped to work. Aside from that though, and I am not trying to sound/look like a moron, I just don't understand where you physically enter the values for the offset.
[12:21:55] <lair82> CaptHindsight, Yep that's me, that board and CPU have been sitting on my toolbox since we last talked up to about 3 Days ago. I finally got it installed and it looks like things are going better now, but they haven't ran a full shift on it since I did the install, so its hard to say how its going to work out.
[12:22:10] <seb_kuzminsky> lair82: with the fanuc patch you physically enter the values for the offset in the tool table, right? in T10003, in your example above?
[12:22:23] <lair82> I do see thought that the CPU load is down around 10% now.
[12:22:52] <lair82> seb_kuzminsky , yes that is how we do it.
[12:22:56] <seb_kuzminsky> ok good
[12:23:03] <CaptHindsight> lair82: ok, did you use 10.04 and the 2.6.32 RTAI for your testing?
[12:23:09] <seb_kuzminsky> without the fanuc tool patch, it's exactly the same
[12:23:46] <seb_kuzminsky> you'd put the tlo you want to use in T10003 in the tool table, then call G43H10003 (perhaps via some remap)
[12:23:49] <CaptHindsight> lair82: I have the same board but i haven't tested it with your APU yet
[12:24:54] <lair82> Ok, that clears everything up, sorry for all of the confusion guys
[12:25:58] <seb_kuzminsky> ok, no problem, glad it's clear :-)
[12:28:55] <CaptHindsight> preempt_rt latency delays are caused by cpu cores going idle, USB and driver interruptions and applications allocating memory
[12:30:46] <CaptHindsight> ignoring the cpu cores going idle, why do some cpu's have much shorter delays than others with similar core speeds
[12:32:44] <CaptHindsight> how much do microcode versions in the cpu effect latency?
[12:33:23] <lair82> I honestly try to not be a pain in the ass, but I have 3 turning centers that for the most part are all identical Linuxcnc builds, that run 10 hr shifts, 6 days a week, so whatever I can do to make the operators life ( and mine) easier, I do it. Myself and the owner were talking just this morning about finally retrofitting a 4 axis vertical machining center and building a plasma table, both running Linuxcnc. All in all I have o
[12:36:08] <seb_kuzminsky> there was no ass-pain felt on this end of the conversation
[12:36:26] <seb_kuzminsky> it's great that you are getting things done with linuxcnc and i'm happy to help
[12:37:32] <lair82> Thank you Seb,
[12:37:35] <seb_kuzminsky> lair82: your message got cut off after "All in all I have o"
[12:37:54] <lair82> All in all I have over 20 cnc's I am responsible for.
[12:38:08] <lair82> Things get chaotic at times
[12:38:30] <seb_kuzminsky> i can imagine
[12:39:01] <CaptHindsight> lair82: that board also work with the newer RTAI kernel but you have to turn off KMS and use the Vesa and ipipe driver vs hardware accell
[12:39:40] <CaptHindsight> if you have a need or urge to use 3.4.9 RTAI
[12:42:45] <CaptHindsight> not sure yet how RTAI handles USB interruptions vs -RT
[12:44:10] <CaptHindsight> In another life I used to work with QNX, pSOS and VX works. I'm not sure how much I really want to dig into RT Linux
[13:19:14] <jepler> seb_kuzminsky: a versioned dependency would just make linuxcnc uninstallable on debian 7 though
[13:24:58] <CaptHindsight> page faults in Firefox cause the large latency jumps
[13:26:24] <jepler> and afaict linuxcnc works .. but the tools to develop the glade screens don't
[13:32:29] <jepler> the linuxcnc people who are using gtk+ / glade will need to take a serious look at this or we'll end up having to remove it all sooner or later
[13:34:33] <jepler> Ubuntu appears to be flogging along the last gtk2-compatible glade -- it's in Trusty as glade-3_3.8.0 (requires "universe" packages). but either it's not in debian or I'm not spotting it by name
[13:35:27] <cradek> I'm glad you wrote AXIS in a dead toolkit
[13:35:49] <jepler> confusingly, glade-gtk2 is built from source package glade-3, while glade (the gtk3-only package) is built from source package glade
[14:35:35] <seb_kuzminsky> jepler: so the glade parts that ship with linuxcnc work fine on wheezy, but you can't use wheezy to develop the glade parts of linuxcnc?
[14:35:49] <seb_kuzminsky> but we build on wheezy successfully, so that can't be right
[14:35:51] <seb_kuzminsky> hrm
[14:35:58] <seb_kuzminsky> lunch will make me less confused
[14:37:56] <jepler> seb_kuzminsky: a glade.ui file doesn't have to be processed to build linuxcnc, only installed
[14:38:11] <jepler> seb_kuzminsky: the parts that work at runtime to create the gtk widgets work
[14:38:21] <jepler> seb_kuzminsky: but the program you'd use to reorganize the screen doesn't exist
[14:40:37] <jepler> but the good news is: I successfully built glade-gtk2 version 3.8.0-0ubuntu6 on debian 7
[14:41:59] <ssi> I'mma attempt to build ja5 for the laser
[14:42:27] <ssi> i want to sort out this free/teleop mode switch thing
[14:46:51] <jepler> and it will resave stepconf .glade files in a way that stepconf understands
[14:47:06] <jepler> .. though there are some spurious-looking changes in the xml
[14:47:19] <jepler> - <property name="mnemonic_widget">xsteprev</property>
[14:48:04] <jepler> seb_kuzminsky or cradek: what would the process be these days to get this package into the www.l.o deb repository?
[14:52:03] <cradek> right now it'd be easiest to have seb do it, because he's been signing lately - but you or I could do it if we warn him to be careful with future rsyncs, etc
[14:55:16] <jepler> and I didn't do an i386 build which is what our users need
[14:55:56] <jepler> seb_kuzminsky: I just debuilt
http://packages.ubuntu.com/source/trusty/glade-3 on debian 7, there aren't any tricks to it
[14:56:40] <cradek> I think he has a script to debuild for all the appropriate smells
[14:57:43] <erasmo> Helo everyone
[14:57:56] <erasmo> I would like to create my own I/O and/or brush servo ethernet card based on new uspace capabilities of linuxcnc. My question is: where do I need to search to find any informations on howto use uspace capabilities?
[14:58:58] <jepler> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Uspace says how to get the code and build it
[14:59:16] <jepler> the ethernet APIs used for hm2_eth are simply Linux socket API calls like socket(), connect(), send(), recv()
[15:00:46] <erasmo> I already have linuxcnc built with uspace
[15:00:59] <erasmo> Ill try to work it out
[15:01:13] <erasmo> thank for fast reply
[15:02:14] <jepler> there's no specific documentation on ethernet, since it's just standard linux networking. We just know from the 7i80 that UDP networking works well enough and has good latency
[15:03:18] <jepler> and keeping the number of packets low is good .. the holy grail would be just 2 per servo cycle (one in each direction)
[15:03:36] <seb_kuzminsky> jepler: i rsync wlo/dists to a local cache, add the new debs to the right places, update the debian metadata files from the linuxcnc-infrastructure.git/repositories files
[15:03:43] <seb_kuzminsky> then rsync the result back to wlo/dists
[15:04:24] <erasmo> I have ethernet device that works with UDP, looks like it will not be that complicated like I thought
[15:08:02] <jepler> good luck in your project
[15:10:35] <seb_kuzminsky> jepler: i'll look into building glade & uploading the debs tonight
[15:11:05] <jepler> seb_kuzminsky: thanks. It is probably a wiser choice than giving me the chance to louse up the repository
[15:11:23] <jepler> .. particularly in a week when a lot of people will be downloading, one hopes
[15:12:02] <seb_kuzminsky> i went against cradek's recommendations and put all of wlo/dists into a git repo here locally, just so i can see what i'm changing before i rsync things back up
[15:12:34] <cradek> all those binaries? that's crazymaking.
[15:12:46] <cradek> use zfs!
[15:13:23] <jepler> or barelyfs^Wbtrfs!
[15:13:33] <jepler> or rsync --dry-run
[15:13:44] <ssi> cradek: so I have the machine in front of me now, and I definitely don't have a free/teleop mode switch option in UI anywhere that I can find
[15:13:58] <ssi> and there doesn't seem to be a hal input pin anywhere to control it; there's a motion.teleop-mode output pin
[15:14:14] <ssi> it was this way on ja4, and I just upgraded to ja5, and still the same way
[15:15:28] <jepler> if kinematics_type in nml is KINEMATICS_IDENTITY, axis removes teleop-related items from the view menu and unbinds the "$" key which is otherwise the mode toggle
[15:15:40] <ssi> ahh!
[15:15:54] <cradek> if you're identity kinematics that switch makes no sense
[15:16:01] <cradek> what is your setup?
[15:16:08] <ssi> well I'm gentrivkins in ja for a gantry machine
[15:16:12] <ssi> and I need free mode for homing
[15:16:15] <ssi> independent homing
[15:16:22] <cradek> then gentrivkins doesn't make sense for you
[15:16:28] <jepler> (the removed items have labels "Joint mode" and "World mode")
[15:16:34] <ssi> what does? gantrykins is horribly broken in master at least
[15:16:42] <ssi> the solution that was most recommended was gentrivkins on ja
[15:16:52] <ssi> and it all works except for the mode switch stuff
[15:17:14] <cradek> all of the "solutions" need work
[15:17:31] <ssi> yeah, understandable... but you're suggesting there's a better option than gentrivkins/ja?
[15:17:49] <cradek> I don't know. you probably have tried more of the "solutions" than I have
[15:18:09] <cradek> what kind of homing process are you trying to do? do you have encoders? index?
[15:18:17] <ssi> no, it's just switches
[15:18:24] <ssi> but they're independent so the squaring can be software-adjusted
[15:19:17] <cradek> maybe you can make homing work by masking motion in hal according to the switch states, or some other hackery
[15:19:40] <cradek> I guess I don't even know how gentrivkins homes...
[15:19:51] <ssi> yeah I went down a bunch of those roads... the solution I've arrived at is pretty reasonable, the only thing I'm lacking is this mode switch issue
[15:19:56] <cradek> or perhaps you should dig in and implement gantry homing
[15:20:10] <cradek> I don't know what you mean by mode switch issue
[15:20:11] <ssi> I'd be happy to do so, if I can get a bit of direction on how to get started
[15:20:24] <cradek> if you're IDENTITY kins there are no modes to switch
[15:20:24] <ssi> well so the way these machines work as is, axis starts in free mode
[15:20:56] <ssi> so for instance on the laser, which has no Z axis, in free mode I can jog one Y joint with up/down arrow, and the other with pgup/dn
[15:21:15] <ssi> then when I do a home all, the home sequence is set up so X homes first, then both Y joints home together
[15:21:33] <ssi> there's some python in .axisrc that watches to see when all three joints are homed, and automatically switches into teleop mode
[15:21:37] <ssi> that's a hack that was suggested by someone
[15:21:48] <ssi> and all that works fine.
[15:22:04] <ssi> the specific problem I'm trying to overcome is the fact that I have no way to switch back to free mode once that happens
[15:22:10] <ssi> so if i need to re-home, I have to kill axis and restart
[15:22:13] <ssi> then I'm back in free mode
[15:22:16] <ssi> it's just an irritant
[15:22:27] <cradek> I thought you were using gentrivkins
[15:22:29] <ssi> I am
[15:22:44] <cradek> then all of what you just said doesn't make sense
[15:22:58] <ssi> loadrt gentrivkins coordinates=XYY
[15:22:59] <cradek> there is no teleop mode in trivkins
[15:23:05] <ssi> certainly seems to be!
[15:23:10] <ssi> might be ja specific, I don't know
[15:26:12] <ssi> so what is SUPPOSED to be the difference between trivkins and gentrivkins?
[15:26:28] <ssi> * Description: gentrivkins.c
[15:26:29] <ssi> * general trivkins for 3 axis Cartesian machine, based on gantrykins
[15:26:36] <ssi> "based on gantrykins"... interesting
[15:28:18] <ssi> I guess as a hacky workaround I can modify gentrivkins locally to return KINEMATIC_BOTH as type
[15:30:43] <ssi> yes
[15:30:51] <ssi> sry, mischan
[15:50:34] <jepler> seb_kuzminsky: I went ahead and entered a ticket on sf for glade-gtk2
[15:50:50] <jepler> you seem to have found it useful
[15:50:54] <jepler> to have tickets
[15:51:16] <seb_kuzminsky> yes
[15:51:18] <seb_kuzminsky> thanks
[15:51:29] <seb_kuzminsky> i forget things if i dont write them down :-/
[15:51:58] <jepler> I know how you feel. at $DAY_JOB I say multiple times a week "file a bug, otherwise it'll look like I'm blowing you off"
[15:52:03] <jepler> (well, I suppose I am, just not on purpose)
[16:29:00] <jepler> :qa
[16:29:02] <jepler> argh
[17:14:40] <ssi> so there's another odd thing that I think might be a consequence of the gentrivkins for a gantry machine setup
[17:14:54] <ssi> my axis preview is always scaled 2X along Y
[17:15:40] <ssi> https://pbs.twimg.com/media/Bt0ubYrIMAA8x8z.png:large
[17:15:51] <ssi> those are all 1" circles, and they all fit within the 24" envelope
[17:16:12] <ssi> you can see the pink lines are predicting the height of the cut correctly, but the white preview is 2x too tall
[17:16:43] <ssi> I suspect maybe it's because since two joints are moving for Y, it thinks that 2x the distance is covered?
[17:16:46] <ssi> not really sure
[17:17:56] <seb_kuzminsky> ssi: that doesn't sound right to me
[17:20:02] <ssi> just a speculation :) I know nothing of how that code works
[17:20:07] <ssi> but both my gantry machines do it
[17:20:08] <seb_kuzminsky> me neither :)
[17:20:55] <seb_kuzminsky> so are you saying that the gremlin preview shows the wrong toolpath (Y coordinates scaled up by a factor of 2) but the machine does the correct motion (not scaled in Y)?
[17:21:33] <seb_kuzminsky> one of these years someone shoudl fix gantry machines for good...
[17:29:38] <ssi> correct
[17:29:45] <ssi> the machine cuts correctly, moves correctly
[17:29:51] <ssi> just the toolpath display is wrong
[17:30:08] <ssi> both the white paths, what it thinks it should do, and the pink paths, what it actually did
[17:30:39] <ssi> but the pinkish dimensions on the display which show the bounds of the program are correct, and the dotted red rect which showes the machine envelope is correct
[17:32:03] <seb_kuzminsky> that's bizarre
[17:32:16] <ssi> :)
[17:32:19] <seb_kuzminsky> which version of linuxcnc is this?
[17:32:36] <ssi> 2.7.0pre-ja5
[17:32:46] <ssi> but it does it in 2.6.0pre-ja4 as well
[17:33:01] <seb_kuzminsky> ok
[17:33:12] <ssi> and probably just a quirk of the gantry setup
[17:33:18] <ssi> since I seem to be the only person in the universe doing this :P
[17:34:55] <seb_kuzminsky> i've worked on two gantry machines and never noticed this issue
[17:35:09] <seb_kuzminsky> both of mine ran 2.5 without any ja code
[17:35:31] <ssi> yeah...
[17:35:36] <ssi> I ran my plasma table for years like that
[17:35:41] <ssi> but I had no home switches at all
[17:35:47] <ssi> and the gantry squareness was "that looks about right"
[17:36:01] <ssi> I switched to doing it this way for software-calibratable squareness
[17:36:12] <seb_kuzminsky> these gantries homed to a single prox, with square-ness handled... by hand
[17:36:14] <ssi> and I just got done calibrating the laser to within 0.001" over 16"
[17:36:27] <ssi> that's my motivation for this
[17:36:44] <seb_kuzminsky> that's a very good reason to do what you're doing
[17:36:44] <ssi> and... linuxcnc really ought to have this capability without as much hacking as it currently takes
[17:36:56] <ssi> I'm happy to try to jump in and work on it
[17:37:00] <ssi> I just need to figure out how to begin
[17:37:01] <seb_kuzminsky> awesome!
[17:37:23] <ssi> JA fundamentally seems like a good thing to me
[17:37:28] <ssi> separating joints from axes seems important
[17:37:45] <ssi> so... maybe gantrykins needs to be freshly rewritten for JA?
[17:38:16] <seb_kuzminsky> ja is definitely on the right track, but i dont think it follows that gantrykinds needs to be thrown out and re-written
[17:38:39] <ssi> so the first time around when I did this, I used gantrykins
[17:38:42] <ssi> and it had major problems
[17:38:56] <ssi> the most significant of which is that it didn't obey axis velocity and accel limits
[17:39:04] <ssi> or endstops!
[17:39:10] <seb_kuzminsky> yeah, oops
[17:39:19] <seb_kuzminsky> this is why it's not merged into master yet ;-)
[17:39:29] <ssi> well that was gantrykins in master
[17:39:45] <seb_kuzminsky> oh, i thought we were still talking about ja, my bad
[17:39:58] <ssi> I dno't think gantrykins in ja is any different than gantrykins in master
[17:45:10] <ssi> i just really don't understand enough about the kinematics modules to know why gantrykins would behave wrong while gentrivkins would behave correctly
[17:45:18] <ssi> doesn't seem like there's all that much code in them
[19:29:54] <skunkworks> crappy video...
[19:29:57] <skunkworks> wow
[19:30:00] <skunkworks> crappy picture
[19:30:02] <skunkworks> http://electronicsam.com/images/KandT/testing/stirling/crankinstalled.jpg
[22:05:08] <skunkworks> http://electronicsam.com/images/KandT/testing/stirling/DSC_2169.JPG
[22:05:41] <skunkworks> had to add a .004" shim for it to go work.. (missed it by that much..)
[22:06:38] <skunkworks> for it to work..
[22:15:19] <seb_kuzminsky> looks good sam!
[22:15:44] <jepler> what's four thou between friends?
[22:34:07] <skunkworks> I don't know how I would live without a touch probe.. it sure makes life easier..
[22:36:20] <skunkworks> I did break a tap today.... A bit impatient.. Dad got it out with a carbide drill - didn't effect the threads at all
