Back
[08:06:00] <jepler_> yay, I'm "caught up" on linuxcnc mailing lists. mostly by pressing the "mark thread as read" button, but still...
[08:17:50] <skunkworks> jepler, yay!
[08:21:55] <cradek> that's still quite an accomplishment
[08:35:22] <mozmck> Heh, I know that method - after a while I right click on the whole folder (thunderbird) and mark all as read.
[09:03:19] <cradek> I wish I could use "never show me any more of this thread" but I don't trust our folks to start a new thread correctly.
[09:03:59] <cradek> although in those cases, maybe I likely won't care about the new topic either
[09:24:31] <zq> i just realized that the estop system communicates with motmod over a non-realtime mpi
[09:25:19] <zq> could anyone shed some light on how this is not unsafe from a theoretical standpoint?
[09:33:19] <cradek> your estop should not rely on talking to software running on a computer for safety
[09:33:40] <cradek> by worrying about whether it's realtime, you are thinking about safety wrong
[09:35:04] <cradek> estop chains should not use semiconductors at all
[09:37:22] <cradek> it's convenient if linuxcnc learns that the machine went into estop, but that is NOT a safety issue
[09:38:25] <zq> cradek: then why have realtime at all?
[09:39:06] <cradek> so the machine tool works
[09:39:12] <cradek> that is a very silly question
[09:39:13] <zq> if we're relying on it to generate motion
[09:39:21] <zq> we should rely on it to stop moving too
[09:40:03] <CaptHindsight> E-Stop should work even if the PC and software gets hung
[09:40:15] <zq> whether or not having another layer of external estop as a best practice is a totally different matter
[09:40:22] <cradek> linuxcnc stops the machine just fine in a controlled way, nicely decelerating to a stop, all the time in normal operation
[09:40:34] <zq> cradek: except it doesn't
[09:40:36] <cradek> that has nothing to do with emergency stop
[09:40:45] <zq> as i said, it's done over a non-rt mpi
[09:41:17] <cradek> you are confusing normal operation and emergency stop
[09:41:22] <zq> not at all
[09:41:40] <zq> it wasn't difficult to trace how aux.estop is read
[09:41:41] <cradek> estop is done with wires and and a big red button and perhaps some relays
[09:41:57] <zq> i don't think you read anything i wrote
[09:42:04] <cradek> heh, likewise
[09:42:16] <zq> i did, and i responded to each
[09:42:20] <cradek> the estop input to linuxcnc is NOT used to stop the machine
[09:42:29] <zq> it's
[09:42:30] <zq> called
[09:42:31] <zq> "estop"
[09:42:32] <cradek> it is to let linuxcnc know the machine HAS BEEN stopped in an emergency situation
[09:42:41] <zq> every ui has a button named "estop"
[09:42:56] <zq> there's a NMLmsg with substring 'estop'
[09:43:06] <zq> there's an aux.estop
[09:43:10] <zq> it's *estop*
[09:43:27] <zq> there's even a user-enable-out
[09:43:28] <cradek> it's true there are those buttons. it's NOT true that you use the mouse to poke one in an emergency
[09:43:38] <zq> as i said
[09:44:11] <zq> if one relies on it to generate motion, it follows trivially that one would rely on it to stop moving
[09:44:11] <cradek> bbl
[09:45:19] <zq> you're stuck on the fact that { yes, it's a best practice to have a second layer of estop that cuts things off at a lower physical level; }
[09:45:33] <zq> but linuxcnc is fundamentally software, not hardware
[09:45:48] <CaptHindsight> zq: what if the PC gets hung/freezes during motion and you want to stop the machine?
[09:45:55] <zq> CaptHindsight: then that's an issue with the hardware
[09:46:01] <zq> CaptHindsight: or the kernel, even
[09:46:06] <zq> CaptHindsight: and that would be totally out of our hands
[09:46:08] <CaptHindsight> do you want to hit a button on the UI that won't respond?
[09:46:14] <zq> oh man
[09:46:20] <zq> i'm not even talking about the ui
[09:46:37] <zq> the ui, as in emc/usr_intf/*, is completely not part of this conversation
[09:46:45] <CaptHindsight> zq: you're just arguing a point without looking at the entire situation
[09:47:06] <zq> heh, you're kinda like cradek, too attached to the best practice mentality
[09:47:10] <CaptHindsight> zq: please state your point
[09:47:23] <zq> everything i said in scrollback
[09:47:25] <zq> read it
[09:47:39] <zq> { best practice } != { requisite practice }
[09:47:46] <CaptHindsight> and you're like kids that just want to argue a point
[09:48:11] <CaptHindsight> semantics
[09:48:28] <zq> ugh, why would you automatically flame me if you don't understand what i'm saying?
[09:48:47] <CaptHindsight> go ahead and explain
[09:49:04] <zq> ignoring the fact that semantics is in general _everything_, this fundamentally affects how motmod would function
[09:49:30] <CaptHindsight> can you use a software estop to stopm the machine, sure
[09:49:41] <CaptHindsight> what do you really want to know?
[09:49:44] <zq> "can" isn't the point
[09:49:51] <zq> "should" is
[09:50:05] <zq> but there are at least two different meanings of "should" in this context
[09:50:06] <CaptHindsight> philosophy ah
[09:50:18] <zq> and you + cradek are stuck on one
[09:50:38] <CaptHindsight> so use estop vs? to stop the motion
[09:50:49] <CaptHindsight> please don't flame us :)
[09:51:06] <zq> i think that's a request more appropriately posed from me to you
[09:51:18] <CaptHindsight> I disagree
[09:51:32] <zq> in any case
[09:51:49] <CaptHindsight> so which discussion?
[09:52:09] <CaptHindsight> estop vs "what" to stop motion?
[09:52:21] <zq> there's an estop input
[09:52:36] <zq> it isn't a "status update" button as cradek insists
[09:53:00] <zq> even if it were, it'd be more than that purely because emc would be the one generating the motion
[09:53:46] <CaptHindsight> what would you like to use to stop the machines motion?
[09:54:14] <zq> you're essentially avoiding a design best practice and deferring its responsibility to a hardware best practice
[09:54:17] <zq> idk how else to put it
[09:54:32] <zq> CaptHindsight: what do you mean how else?
[09:54:43] <CaptHindsight> so what would you like to use to stop the machines motion?
[09:55:23] <zq> CaptHindsight: i think i've been unwaveringly reiterating that aux.estop must be a reliable source of estop
[09:55:38] <cradek> zq: you asked someone to tell you why it wasn't a safety concern, and I tried to do that, although you had already decided and I think you did not really want the answer to that question - you meant it as a statement. but let's move on and not have an argument about tone. If you want to change the estop communication in and out of linuxcnc to be realtime, that would be fine, maybe even good, but I don't think it would enhance ...
[09:55:44] <cradek> ... safety, which was your original question.
[09:55:57] <zq> cradek: safety as in safe software
[09:56:21] <zq> safety concern as in concern over how safe this software is, currently
[09:56:39] <zq> not of the unit overall. strictly speaking, that wouldn't be any of the software's business
[09:57:03] <zq> i'll work up a pr
[09:57:16] <cradek> attaching a patch would be great
[09:57:18] <zq> it's not much apart from moving around the emc-enable-in check
[09:57:27] <cradek> great
[09:57:43] <zq> but i wanted to ask here first to see what the reasoning was for the status quo
[09:59:31] <skunkworks> zq - motion is 'realtime' but you still don't depend on it.. you have physical limit switches hooked into the estop loop so if anything happens to the computer - the machine is protected... (and I agree with cradek - estop could be realtime - but I don't know if it is an enhancement)
[09:59:56] <cradek> seems like we'll eventually move everything out of iocontrol/iotask, which is fine with me
[10:00:51] <archivist> there are some sorts of machine where a controlled stop is better than a removal of power
[10:00:53] <cradek> zq: be aware that the estop buttons on the gui can't respond in realtime, whatever you do, because it's a gui
[10:00:56] <zq> skunkworks: plim switches are feedback
[10:01:27] <zq> feedback in the sense of 'status update' but yeah also as critical as estop
[10:01:35] <zq> cradek: of course
[10:01:39] <cradek> archivist: I bet almost every machine is like that.
[10:01:51] <zq> cradek: it's a gorram gui, not realtime in every aspect of its behavior
[10:02:03] <cradek> I don't know what gorram means
[10:04:02] <CaptHindsight> how do you want to measure the safety of the software? Is it safe enough to run a properly designed mill or a teleoperated surgical robot with malpractice lawyers salivation at the sidelines waiting strike?
[10:05:07] <archivist> a hobbing machine needs to remain "in gear" during a stop else damage to something will occur
[10:07:26] <CaptHindsight> software estop vs physical switches....
[10:07:51] <archivist> I think a choice is needed
[10:08:40] <CaptHindsight> I have both on a lathe with a PLC i wired yesterday, the physical e-stop cuts power to the machine and it still takes a couple of seconds to stop moving
[10:12:08] <CaptHindsight> should I add a brake to stop the machine faster? Should the lathe detect when I have possibly snagged a piece of clothing in the chuck and halt within 5 deg of rotation?
[10:12:30] <CaptHindsight> my point is with the software...
[10:13:05] <archivist> I saw a blanking press at a show that was really shifting and I asked about stopping speed, it was within a rev as he then demonstrated
[10:13:07] <CaptHindsight> if you add the realtime vs non-realtime e-stop what do you gain?
[10:16:10] <archivist> a few years ago in the other chan we were watching a youtube vid of a friction welder and there was discussion/a url to one that stopped too quick and it ripped itself off the floor and turned over (flywheel)
[10:38:31] <CaptHindsight> archivist: was missing the inertia absorbers, someone needs to invent them to replace bumpers
[10:45:25] <cradek> have you guys seen the table saw stopping device that detects meat and then (destructively) stops the blade?
[10:46:07] <cradek> I bet the still-two-handed operator wouldn't mind replacing a few parts
[10:46:26] <CaptHindsight> works great for a small saw blade
[10:48:58] <skunkworks> the table saw is the only tool that still scared the crap out of me...
[10:52:42] <CaptHindsight> the worst were the radial arm types
[10:53:21] <CaptHindsight> http://www.youtube.com/watch?v=C9uBo_4JOVI
[10:53:57] <skunkworks> I like radial arm saws..
[10:55:33] <skunkworks> just don't get your finge/arm in front of the blade.. :)
[10:55:46] <CaptHindsight> table saws and shark fins
[10:55:52] <archivist> I spent many hours on a dewalt overarm, have tinnitus now
[10:56:18] <skunkworks> what!?
[10:56:22] <archivist> was cutting ally extrusions
[10:56:30] <skunkworks> ouch - that is loud...
[10:56:46] <archivist> that vid is a tiny saw :)
[10:57:51] <CaptHindsight> yeah I us a compound miter saw and it's loud, have to wear the ear muffs
[10:58:28] <CaptHindsight> cuts them like butter though
[11:02:39] <CaptHindsight> http://www.freudtools.com/index.php/products/product/LU89M014 worth every penny
[11:07:14] <CaptHindsight> http://www.youtube.com/watch?v=cTUOhYcw4ZY You've seen the hotdog video, now see the real deal... an actual finger!
[12:38:54] <lair82> pcw_home, I have been looking at motherboards, and have looked at your recommendation of the GA-J1900N-D3V. The only possible issue you know of is a problem with graphics on the regular 2.6 kernel?
[12:41:42] <lair82> Or is the
http://www.newegg.com/Product/Product.aspx?Item=N82E16813157465 ASRock board an alternative as well, I see this one you add your own CPU, I found a 3.2 ghz ,
http://www.newegg.com/Product/Product.aspx?Item=N82E16819113343.
[12:42:04] <pcw_home> Yes no graphics accel with a 2.6 kernel But I hessitate to recomment the Gigabyte unless you dont mind futzing with the BIOS
[12:42:05] <pcw_home> (the BIOS needs to be upgraged to version 3 to boot linux)
[12:42:22] <lair82> That gigabyte is only a 2.0 ghz board
[12:42:56] <pcw_home> 4 core 2 GHz though
[12:43:04] <lair82> I've messed with the BIOS settings some with our current machines.
[12:43:27] <pcw_home> I suspect the 2 core 2.4 GHz J1800s are better
[12:44:29] <lair82> I am not going to say money is not an option, but the money we lose each week restarting the machines and reloading tool tables is no match to spending 200-300 bucks on some hardcore boards and processors.
[12:44:56] <lair82> Does the J1800 come with the PCI slots for my 5i23?
[12:45:28] <pcw_home> some do
[12:45:29] <pcw_home> http://www.amazon.com/ASUS-Mini-DDR3-Motherboards-J1800I-A/dp/B00JK9F9VW
[12:45:31] <pcw_home> for example
[12:46:41] <pcw_home> If you dont mind a MB with a fan, there are lost more choices
[12:46:46] <pcw_home> lots
[12:47:39] <lair82> Whatever it takes,
[12:48:12] <lair82> http://www.newegg.com/Product/Product.aspx?Item=N82E16813128697&cm_re=GA-J1800N-D2P-_-13-128-697-_-Product
[12:50:05] <pcw_home> if you can live with a fan, it will be less hassle to just use more standard MB
[12:50:24] <pcw_home> (full graphic support etc)
[12:54:18] <lair82> Do you mean going to a micro atx form instead of a mini itx?
[12:55:23] <lair82> I guess more or less, what are the basic req's for a motherboard to run LNCNC?
[12:55:39] <lair82> Then I can do some shopping
[12:55:45] <CaptHindsight> http://www.newegg.com/Product/Product.aspx?Item=N82E16813157228 PCIe and no PCI or LPT port, but runs 3.4.55 RTAI and accel graphics
[12:56:51] <CaptHindsight> all out of stock anyway :(
[12:56:58] <pcw_home> CaptHindsight: lair82 needs PCI and the E350 is not significantly faster than the Atom he is replacing
[12:57:30] <CaptHindsight> this is the one with the ladder logic funness
[12:57:35] <lair82> What I'm running now is all 1.8 ghz boards
[12:57:44] <lair82> Yep that would be me
[12:58:33] <CaptHindsight> ever see what part of the ladder is sucking up all those cpu cycles?
[12:58:46] <CaptHindsight> it would be interesting to use for stress test
[12:59:38] <lair82> No, I'm not sure where to start to find that info, I did pastebin the files last week, did you try them?
[13:00:10] <CaptHindsight> I have them, I'll get around to them in the next few weeks
[13:03:43] <CaptHindsight> http://www.newegg.com/Product/Product.aspx?Item=N82E16813157465 this will probably the next coreboot supported board, Micro ATX + FM2+ socket, with LPT and PCI + PCIe
[13:04:31] <lair82> Does that ASRock FM2A88M-HD+ ASrock , with the AMD A4-4000 Richland 3.2GHz look like it might work? Looking at around $120
[13:04:47] <lair82> http://www.newegg.com/Product/Product.aspx?Item=N82E16819113343
[13:05:04] <lair82> Thats the CPU
[13:05:56] <lair82> Should I be posting these questions on the user's webchat?
[13:06:18] <lair82> Not sure what I should and shouldnt post on this list
[13:06:58] <seb_kuzminsky> lair82: this channel is more for discussing development of linuxcnc, the main channel (#linuxcnc) is for usage of linuxcnc
[13:07:24] <seb_kuzminsky> the topic of what hardware runs linuxcnc well probably fits better in #linuxcnc
[13:07:46] <pcw_home> ok moving to #linuxcnc
[13:08:28] <lair82> Ok, so am I
[14:10:37] <cradek> if there is a bug that eats the tool table, a faster cpu is very unlikely to fix it
[14:11:57] <cradek> I have heard people mumbling about this for a couple years now. it seems related to the fanucalike lathe tool patch, but it might be elsewhere
[14:15:44] <pcw_home> this is just for the Classic ladder eats all CPU problem
[14:15:59] <cradek> well he also mentioned "reloading tool tables"
[14:18:34] <pcw_home> Yeah dont know about that
[14:24:44] <cradek> bogoprofiling doesn't show any smoking guns in CL
[14:24:51] <cradek> I got his ladder to load
[14:29:48] <skunkworks> bogoprofileing?
[14:42:14] <cradek> bogoprofiling: attach the debugger and interrupt it a few times to see if it's always doing the same thing
[14:44:44] <cradek> might help if I try it on a slow computer...
[14:48:21] <seb_kuzminsky> gprof will show you hotspots, if you can convince our build system to build with it
[14:48:34] <cradek> oh I know the right way to do it :-)
[14:48:39] <seb_kuzminsky> heh
[14:50:43] <PCW> the Atoms are pretty slow...
[14:51:34] <PCW> and have relatively bad latency if you actually do anything (like I/O)
[14:51:44] <seb_kuzminsky> well look at that
[14:53:11] <cradek> ?
[14:53:29] <KGB-linuxcnc> 03Sebastian Kuzminsky 05code-coverage b500ec1 06linuxcnc 10src/Makefile enable coverage analysis on builds * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b500ec1
[14:53:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 05code-coverage ea40fc2 06linuxcnc 10src/Makefile turn off optimization for coverage analysis * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ea40fc2
[14:53:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 05code-coverage adaaecb 06linuxcnc 03src/Notes notes on how to check coverage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=adaaecb
[14:53:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05code-coverage d0f7cd1 06linuxcnc 10(8 files in 8 dirs) un-skip all the linuxcncrsh tests * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d0f7cd1
[14:53:35] <KGB-linuxcnc> 03Sebastian Kuzminsky 05code-coverage e9ca700 06linuxcnc 10src/Notes notes on code coverage analysis * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e9ca700
[14:53:42] <seb_kuzminsky> i knew i had it around here somewhere
[14:53:55] <seb_kuzminsky> it's in super bad shape, but maybe it's a starting point for profile builds
[14:54:40] <linuxcnc-build> build #480 of 1402.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed configure-debian-control configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-amd64/builds/480 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:54:55] <seb_kuzminsky> heh
[14:55:25] <linuxcnc-build> build #288 of 1400.rip-wheezy-i386 is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/288 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:55:32] <linuxcnc-build> build #289 of 1401.rip-wheezy-amd64 is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-amd64/builds/289 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:56:21] <linuxcnc-build> build #318 of 1403.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-armhf/builds/318 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:59:17] <linuxcnc-build> build #1230 of 1304.rip-precise-rtpreempt-i386 is complete: Failure [4failed configure-debian-control apt-get-update configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1304.rip-precise-rtpreempt-i386/builds/1230 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:59:24] <linuxcnc-build> build #1335 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/1335 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[15:00:31] <linuxcnc-build> build #1214 of 1303.rip-precise-xenomai-amd64 is complete: Failure [4failed configure-debian-control apt-get-update configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1303.rip-precise-xenomai-amd64/builds/1214 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[15:01:00] <linuxcnc-build> build #2134 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2134 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[15:01:11] <linuxcnc-build> build #1214 of 1305.rip-precise-rtpreempt-amd64 is complete: Failure [4failed configure-debian-control apt-get-update configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1305.rip-precise-rtpreempt-amd64/builds/1214 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[15:01:27] <linuxcnc-build> build #2131 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2131 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[15:03:09] <linuxcnc-build> build #1240 of 1302.rip-precise-xenomai-i386 is complete: Failure [4failed configure-debian-control apt-get-update configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1302.rip-precise-xenomai-i386/builds/1240 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[15:03:27] <cradek> seb_kuzminsky: did you see the halui-jogging failure from last night?
[15:04:03] <seb_kuzminsky> i saw that my name was on a buildbot failure but i didn't look at it yet
[15:04:08] <seb_kuzminsky> i'll look tonight
[15:04:16] <linuxcnc-build> build #2139 of 1101.rip-hardy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1101.rip-hardy-rtai-i386/builds/2139 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[15:04:51] <cradek> it didn't really have your name on it
[15:04:58] <seb_kuzminsky> well
[15:05:06] <cradek> well yeah
[15:09:26] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/abs.comp.gcov
[15:09:43] <cradek> woo
[15:10:16] <seb_kuzminsky> (as an aside, notice how confusing line 37 is, because the conditional and the body are on the same line)
[15:12:03] <seb_kuzminsky> our coding style guidelines don't mention it, but i think that's enough reason to avoid that idiom
[15:12:09] <seb_kuzminsky> bbl
[15:31:36] <jepler> seb_kuzminsky: yes, it should have been: is_positive = tmp > 0.000001;
[15:35:54] <jepler> (and you could also quibble about the definition of positive numbers indicated here)
[15:38:04] <seb_kuzminsky> jepler: that version is better
[15:40:12] <linuxcnc-build> build #2134 of 1100.rip-hardy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1100.rip-hardy-i386/builds/2134 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[15:40:13] <linuxcnc-build> build #2135 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2135 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:13:28] <skunkworks_> logger[psha]:
[17:13:28] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-06-02.html
[20:57:37] <cradek> well no bugs filed on ja4+cba4... that must mean it's perfect and ready for master
[21:39:06] <skunkworks_> I keep meaning to do a bug about homing velocities.. but I keep forgetting
[21:42:04] <pcw_home> is that just a conversion script issue
[21:42:09] <pcw_home> ?
[22:12:12] <skunkworks_> not really - if you have a homing velocity that is faster than the joint limit -- it doesn't obey it.
[22:12:26] <skunkworks_> not a big deal if you know it..
[22:12:55] <skunkworks_> (you just set the homing velocity to a sane speed...)
[22:22:38] <pcw_home> So the homing velocity is bounded by the joint limit?
[22:25:42] <pcw_home> if so, probably not even really a bug
[22:34:36] <skunkworks_> it isn't at the moment.. (if you have the homing velocity set to 11in/sec and the joint limit is set to 5in/sec - it homes at 11 in/sec
[22:53:10] <pcw_home> Oh OK. like you say not a big deal if you know they are independent
[23:13:07] <skunkworks_> right