#emc-devel | Logs for 2007-04-01

Back
[00:04:19] <roltek> does somebody have alex's e-mail
[00:08:48] <jmkasunich> cradek: you asked about stuff for 2.1.5
[00:09:09] <jmkasunich> how bout that chargepump enable pin?
[00:09:27] <cradek> sure, if it's harmless (sure looks that way to me
[00:09:28] <cradek> )
[00:21:08] <jmkasunich> I actually tested it and everything
[00:21:51] <jmkasunich> its also not used in any of the standard configs, so only folks with at least a little HAL clue are using it
[00:24:30] <cradek> yes
[00:24:59] <jmkasunich> I also verified that if you don't connect to the new pin, it works just like before
[00:25:06] <jmkasunich> so no config changes even for those who do use it
[00:33:17] <jmkasunich> backported
[00:37:36] <cradek> don't forget changelog
[00:38:00] <cradek> * cradek builds a kernel on a 300MHz machine
[00:57:21] <jmkasunich> thats gonna take a while
[00:57:28] <jmkasunich> still sparcing?
[00:57:43] <jmkasunich> I mean power-pc-ing
[00:57:45] <cradek> yeah
[01:02:28] <cradek> never got emc to work right though
[01:08:52] <jmkasunich> maybe you need a helper: http://www.funnycatpix.com/_pics/sittingup_kittah.jpg
[01:09:25] <jmkasunich> or food: http://bp3.blogger.com/_6PbD56mSkS8/RfFjmrOe9jI/AAAAAAAAABY/14cQKZz0PM0/s1600-h/cookie.b.jpg
[01:11:53] <cradek> ha the first one is very funny
[01:38:02] <jmkasunich> stuart stevensone is at it again
[01:38:54] <cradek> oh wow
[01:39:48] <cradek> again I don't agree with his idea...
[01:40:04] <jmkasunich> this time he's simply full of crap
[01:40:11] <jmkasunich> soft limits don't overrun
[01:40:28] <cradek> well yes, that's another way of looking at it
[01:40:28] <jmkasunich> because they don't wait for you to hit them and then slow down, they limit the target position in the first place
[01:40:39] <jmkasunich> (which is what I'm writing in my reply)
[01:52:31] <cradek> jmkasunich: I'm finding that some of hal expects 'char' to be signed
[01:53:19] <jmkasunich> nuts
[01:53:35] <cradek> it might just be the utils, I'll have to dig some more
[01:53:39] <jmkasunich> all right thinking compliers know that char is signed!
[01:53:59] <jmkasunich> or is that unsigned
[01:54:20] <cradek> I thought they were usually unsigned, but if so there's breakage
[01:54:33] <jmkasunich> now I don't know which it is
[01:54:45] <jmkasunich> can you point me to a specific place?
[01:54:55] <cradek> halcmd_main.c, search for cp1
[01:56:23] <lerman_> lerman_ is now known as lerman
[01:56:48] <jmkasunich> you mean things like this: if(cp1 == -1) break;
[01:56:52] <cradek> yes
[01:57:19] <jmkasunich> I think that code got bogofied when getopt was added
[01:57:31] <cradek> getopt returns int
[01:57:35] <jmkasunich> when I use "cp", it means "generic character pointer"
[01:58:04] <jmkasunich> cp1 is probably left over from my original hand-coded parsing, it was a pointer that would walk thru the string
[01:58:46] <jmkasunich> cp1 should be renamed to "c", and declared as an int I think
[01:59:15] <jmkasunich> you want me to fix it?
[01:59:28] <cradek> halcmd_commands.c:1289
[01:59:39] <cradek> ^^ another one
[02:00:02] <cradek> still looking for more...
[02:02:26] <cradek> that may be all
[02:02:24] <cradek> I'll fix it later if you don't want to, no problem
[02:02:24] <cradek> gotta run, bbl
[02:02:24] <jmkasunich> I'll do it, you seem to be bust
[02:02:24] <jmkasunich> busy
[02:31:24] <steve_stallings> steve_stallings is now known as steves_logging
[02:49:27] <jmkasunich> cradek: you back?
[02:53:09] <jmkasunich> never mind
[02:57:05] <jmkasunich> hmm, I just thought of an exception to my statement to Stuart
[02:57:14] <jmkasunich> where I say "emc won't overrun soft limits"
[02:57:50] <jmkasunich> I think we've seen that arcs where both endpoints are inside the limit but the arc extends outside the limit can cause trouble
[03:51:02] <SWPadnos_> hi folks. how goes it?
[03:59:45] <jmkasunich> getting late
[03:59:53] <SWPadnos_> indeed
[04:03:00] <cradek> heh, kernel is still building
[04:04:00] <SWPadnos_> I imagine I'd have the same problem on the Mesa 4c81 (ARM 166 MHz)
[04:04:45] <SWPadnos_> maybe I should take the course "Setting up Linux for cross development" :)
[04:04:50] <cradek> well whaddya know - with jmk's little changes, hal works
[04:05:43] <SWPadnos_> somehow, the changes didn't make it to me at 37000 feet
[04:05:57] <cradek> no idea whether I have test_and_[set|clear]_bit right...
[04:06:17] <SWPadnos_> the GNU assembler interface is pretty incomprehensible
[04:06:21] <cradek> no kidding
[04:06:35] <cradek> combine it with the C preprocessor for extra fun
[04:06:36] <SWPadnos_> generic, powerful, etc., but not usable for the most part
[04:06:40] <SWPadnos_> yeah
[04:07:20] <jmkasunich> those char->int changes were all it needed?
[04:07:28] <cradek> oh noooo
[04:07:35] <cradek> but those were the last straw
[04:07:52] <cradek> hal looked really broken when it couldn't parse its commandlines
[04:08:01] <jmkasunich> heh
[04:10:51] <cradek> crap, this is an anon checkout
[04:10:55] <cradek> crap crap
[04:12:52] <jmkasunich> for f in `find -name Root` ; do echo :ext:cradek@cvs.linuxcnc.ort:/cvs >$f ; done ?
[04:13:02] <cradek> yep something like that
[04:14:33] <SWPadnos_> find -name root | sed s/\.ort/\.org/g ;)
[04:20:54] <SWPadnos_> well, it looks like bedtime. see you guys sometime
[04:28:04] <cradek> woohoo, axis works
[04:28:58] <cradek> can someone on a normal computer check to make sure configure still works for checking asm/bitops.h?
[04:35:25] <cradek> now we know
[04:36:00] <jmkasunich> darn
[04:36:02] <jmkasunich> getting an update now
[04:44:42] <jmkasunich> cradek: I don't know if theres anything I can do to help
[04:45:09] <jmkasunich> I noticed the failure is on ulapi - that might just be because it compiles ulapi before rtapi, or
[04:45:33] <jmkasunich> it might relate to your config changes
[04:45:44] <jmkasunich> the old config tested for "AC_MSG_CHECKING([if asm/bitops.h is usable in userspace])"
[04:46:09] <cradek> yes it's definitely the configure thing
[04:46:32] <jmkasunich> its gotta be more than just the test
[04:46:54] <jmkasunich> because adding a more restrictive test (or even a less restrictive one) won't change the truth on a particular machine
[04:46:57] <jmkasunich> it either works or not
[04:47:16] <jmkasunich> the new tests must be changing an include path or something
[04:47:42] <cradek> the previous test #included <asm/bitops.h> and checked for a successful compile
[04:47:56] <cradek> that's not a good enough test of course - it could be missing those functions we need
[04:48:09] <jmkasunich> the actuao code also includes asm/bitops.h
[04:48:10] <cradek> so the new test is supposed to link a program that calls the function
[04:48:33] <jmkasunich> and it worked on my machine - if its including the same file, it should still work regardless fo the test
[04:48:40] <jmkasunich> s/actuao/actual/
[04:48:51] <jmkasunich> ergo, its not including the same file
[04:49:09] <cradek> well the new test doesn't work
[04:49:28] <cradek> it doesn't include asm/bitops.h at all
[04:49:32] <cradek> I think I have a new test that works
[04:49:37] <jmkasunich> in the test?
[04:49:40] <jmkasunich> or in the real code
[04:49:40] <cradek> right
[04:49:53] <jmkasunich> the compile is failing while compiling real code
[04:50:23] <cradek> that's because the test gives the wrong answer!
[04:51:00] <jmkasunich> I thought the result of the test was yes or no?
[04:51:10] <cradek> right
[04:51:17] <jmkasunich> if it used to say yes, and now says now, the configure would fail
[04:51:18] <cradek> the right answer is yes on your system
[04:53:08] <jmkasunich> I see that it is saying no
[04:53:10] <cradek> fixed
[04:53:24] <jmkasunich> so how come configure doesn't quit at that point
[04:53:31] <cradek> it's not an error
[04:54:13] <jmkasunich> "no" is supposed to substitute some other bitops instead?
[04:54:20] <cradek> yes
[04:54:30] <cradek> the ones in rtapi_bitops.h
[04:55:40] <jmkasunich> crap
[04:56:02] <jmkasunich> the object file is newer than the source, so its not getting rebuilt
[04:56:06] <jmkasunich> needs a make clean I think
[04:56:16] <cradek> how did that happen?
[04:56:28] <jmkasunich> you didn't change the source, only configure
[04:57:10] <cradek> yuck
[04:57:28] <jmkasunich> last time, the object file was created (the compile error was only a warning), then the actual error occurred at the link stage
[04:57:27] <cradek> changing cflags (that's what this comes down to) does break make
[04:57:53] <jmkasunich> I did a make clean on my regular checkout
[04:58:05] <jmkasunich> if it works, I'll go into the farm and force complete builds
[05:00:07] <cradek> worked here - sim and not
[05:01:31] <jmkasunich> with a make clean?
[05:01:40] <jmkasunich> looks like its working here too
[05:01:43] <jmkasunich> (slowly)
[05:05:16] <cradek> (now don't ask me why I bothered making powerpc work in the first place)
[05:05:25] <skunkworks> do you guys ever sleep?
[05:05:37] <jmkasunich> on rare occaisions
[05:05:41] <cradek> I try not to - it wastes time
[05:06:14] <skunkworks> I try not too also - but I get incoherent (how ever that is spelled)
[05:06:26] <cradek> actually that was right
[05:06:54] <skunkworks> I guess I have to get lucky every once in a while ;)
[05:10:47] <jmkasunich> * jmkasunich takes up a collection to get a faster machine (its for the farm, honest!)
[05:16:08] <cradek> wonder if there's a powerpc equivalent of rdtsc
[05:18:30] <jmkasunich> one down two to go
[05:21:08] <cradek> yay
[05:41:59] <jmkasunich> two down
[06:11:23] <jmkasunich> all happy, time for bed
[08:54:09] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[13:41:21] <alex_joni> is that ray hidden under there?
[13:41:25] <alex_joni> :-)
[13:44:01] <a-l-p-h-a> duno tink so, mr roboto. Arrogato.
[13:45:32] <smithy> Yep it is rayh
[13:49:19] <smithy> This old box used smithy but I've lost smithy's passwd.
[13:49:19] <alex_joni> ouch ;)
[13:49:19] <alex_joni> does sudo still work?
[13:49:19] <alex_joni> sudo passwd smithy :P
[13:49:19] <smithy> Yes I know the linux passwords just the freenode one has left my head.
[13:49:27] <alex_joni> ahh..
[13:49:50] <smithy> not a biggie.
[13:50:40] <steves_logging> steves_logging is now known as steve_stallings
[13:53:39] <roltek> ray when you getting back in town
[13:54:54] <smithy> I was wanting to come by your place. I'll try but don't know just when.
[13:55:13] <alex_joni> * alex_joni goes out for a bike ride
[13:55:15] <alex_joni> bbl
[13:55:28] <alex_joni> roltek: nice setup (like the handwheel)
[13:56:03] <roltek> how's it going ray you getting burnt out yet
[13:56:37] <rayh> Yep.
[13:56:43] <roltek> how long you been there 2-weeks
[13:57:24] <roltek> i took the day off had enough
[13:57:44] <roltek> working on handwheel today
[13:58:10] <roltek> thru messa card
[13:58:47] <rayh> Great. Hope you get it working.
[13:59:44] <roltek> i'll probaly make mistakes but will
[14:00:18] <roltek> any great advancements at smity
[14:00:41] <rayh> did a lot of testing of emc2 and steppers.
[14:01:14] <roltek> did you go to future mate for hand wheel yet
[14:01:37] <rayh> No
[14:01:53] <rayh> I'll look for samples in China.
[14:02:01] <roltek> is the machine cutting good
[14:05:35] <rayh> Yes. Fairly well.
[14:05:48] <rayh> Making me remember a few gcodes.
[14:05:53] <rayh> Been a while.
[14:11:27] <roltek> are you using any kind of relay board on your set up yet
[14:13:36] <rayh> PMDX-131 with a few mods.
[14:13:51] <rayh> and a prototype spindle controller.
[14:14:28] <rayh> As you know, I like 24 volt control relays.
[14:15:08] <rayh> The 131 can pull a couple of 'em. And read 24 volt NPN prox switches.
[14:17:26] <roltek> i'll send you a file
[14:20:55] <roltek> have to go now have parts to get
[14:21:05] <rayh> Okay.
[14:47:40] <SWPadnos_> hiya smithy
[14:48:38] <smithy> Hi Steven
[14:48:48] <SWPadnos_> how goes it, Ray?
[14:48:55] <smithy> Good.
[14:49:01] <SWPadnos_> great
[14:49:03] <smithy> Checking out the new homing routines
[14:49:10] <smithy> Got the board, thanks.
[14:49:11] <SWPadnos_> cool. how's the MPG?
[14:49:33] <smithy> Great. Completing the box got put off a bit.
[14:49:46] <SWPadnos_> a common occurrence :)
[14:49:50] <smithy> next week or the week after it should be done and shipped.
[14:50:16] <SWPadnos_> I sent you the AVR programmer. I haven't had a chance to look into using the USB version on Linux
[14:50:57] <smithy> I haven't either
[14:51:12] <SWPadnos_> I actually had a problem programming an older MPG board with one of the USB ones, while the serial one worked fine. hopefully you (a) won't need it and (b) won't run into any problems if you do
[14:51:39] <smithy> Doesn't look like we need to do any programming.
[14:51:50] <SWPadnos_> excellent
[14:51:58] <smithy> Won't have much chance to play in the next few weeks.
[14:52:07] <smithy> Probably not till after fest.
[14:52:20] <SWPadnos_> I'm glad you showed up. I wanted to make sure things are going well. I've got to run to this conference
[14:52:36] <SWPadnos_> ok. we can work on it then if you need to
[14:53:55] <SWPadnos_> well. got to run. see you around (sporadically this week)
[14:54:22] <smithy> Great. you'll have to get me a proto board.
[14:54:32] <smithy> catch you later.
[15:41:29] <cradek_> cradek_ is now known as cradek
[15:49:30] <rayh> Interesting stuff of usb here. http://www.evaluationengineering.com/archive/articles/0604/0604USB.asp
[16:26:55] <alex_joni> been running lintian on our debs today
[16:27:03] <alex_joni> still have a couple of warnings..
[16:39:27] <rayh> Is it possible that we have not tested multi axis home from limits?
[16:42:59] <rayh> It does seem to ignore the limit if I have only one axis doing homing.
[16:43:18] <alex_joni> rayh: it only ignores the current joints limits
[16:43:47] <rayh> but if all limits are connected to a single pin?
[16:44:02] <alex_joni> then I suggest you home them one by one
[16:44:18] <alex_joni> err.. that might not work either
[16:44:30] <rayh> I don't think it does.
[16:44:30] <alex_joni> ask jmk .. he looked at this recently
[16:45:00] <rayh> Looks like he got dumped in the last round of problems.
[16:45:38] <rayh> What happens if more than one axis has limits defined is it trips out on that axis when the other is homing.
[16:46:06] <alex_joni> yeah, I think that's right
[16:46:26] <rayh> Okay it isn't just me!
[16:46:30] <alex_joni> no, not just you
[16:46:51] <rayh> Then I'll move on to the next task.
[16:47:01] <alex_joni> you could and the input to the limits with the homing-active signal
[16:48:01] <rayh> Oh. That might work.
[16:48:17] <alex_joni> now you only need to see if there's a homing in progress pin ;)
[16:48:23] <alex_joni> but jmkasunich is back.. maybe he knows
[16:48:27] <alex_joni> * alex_joni pings jmkasunich
[16:48:54] <jmkasunich> hi
[16:49:20] <alex_joni> hi, ray is having some issues with common-home and limitswitches
[16:49:30] <alex_joni> I mean connected together.. 1 pin for all homes and all limits
[16:49:31] <jmkasunich> what kind of issues?
[16:49:41] <rayh> It won't home
[16:49:54] <alex_joni> jmkasunich: hitting home on joint 0 trips the limit on joint 1
[16:49:54] <rayh> It will if I only define limits for a single axis.
[16:50:15] <jmkasunich> hmm
[16:50:34] <alex_joni> jmkasunich: there was another one in #emc having the same issue
[16:50:49] <jmkasunich> I don't think you can do what you want to do
[16:50:51] <jmkasunich> you can share limits between axes, you can share homes between axes, and you can share limit and home on one axis
[16:51:03] <rayh> I followed the lathe pluto config for ini and hal setup but that only homes
[16:51:34] <alex_joni> jmkasunich: how about 'and'-ing together the limitswitches and the homing-active signal
[16:52:03] <jmkasunich> let me make sure I understand what you are doing first
[16:52:16] <alex_joni> jmkasunich: one parport pin
[16:52:18] <jmkasunich> 6 switches, one at each end of each axis, all wired to a single pin
[16:52:22] <alex_joni> right
[16:52:36] <jmkasunich> then in HAL that on pin drives all 9 pins on the motion controller
[16:52:44] <jmkasunich> (2 limits and one home per axis)
[16:52:47] <alex_joni> right
[16:52:55] <alex_joni> if I understood ray allright ;)
[16:53:10] <jmkasunich> and you have "home_ignore_limits" turned on in the ini file
[16:53:35] <alex_joni> yes, but the home_ignore_limits is single-joint
[16:53:41] <jmkasunich> right
[16:54:00] <jmkasunich> when you say "home X", it says OK, I'll ignore X limits
[16:54:06] <jmkasunich> but the Y limit trips
[16:54:07] <alex_joni> right
[16:54:38] <rayh> exactly
[16:55:37] <jmkasunich> I dunno if we want "ignore limits" to extend beyond one axis in the motion controller
[16:55:51] <rayh> I DO!
[16:55:55] <alex_joni> jmkasunich: I know.. somehow it feels ok how it is
[16:56:00] <jmkasunich> I'd be more inclined to gate the limits in hal and/or cl
[16:56:03] <alex_joni> rayh: not necessarely _inside_ the motion controller
[16:56:28] <alex_joni> rayh: it's a thing where someone might want it, and some won't
[16:56:37] <alex_joni> and specifying it in the ini will make a mess
[16:56:53] <alex_joni> adding a simple and2 will do the trick
[16:56:58] <rayh> If we are not able to we have no way to replicate how stepper used to do it.
[16:57:09] <alex_joni> parport-pin -> and2.in0
[16:57:25] <jmkasunich> stepper used to allow 6 switches on one pin and you could home to a switch?
[16:57:30] <rayh> yep
[16:57:35] <alex_joni> motion.is-not-homing -> and2.in11
[16:57:41] <alex_joni> what's stepper in your context ray?
[16:57:56] <jmkasunich> alex_joni: is there a "is-not-homing" pin already? or is that a proposal?
[16:58:06] <cradek> this was why we added axis.N.homing right?
[16:58:08] <alex_joni> jmkasunich: I don't think there is..
[16:58:17] <alex_joni> cradek: right..
[16:58:23] <rayh> I could try to use ladder to say if home 1 ignore 2, 3, N. but that seems like a real mess.
[16:58:27] <alex_joni> I know there was "something"
[16:58:31] <jmkasunich> ok, so we have axis.N.homing
[16:58:39] <alex_joni> nor them all together
[16:58:41] <alex_joni> and use that
[16:58:53] <jmkasunich> we need to OR all the axis.N.homing pins together, to get homing_something
[16:59:06] <jmkasunich> and then use "homing_something" to gate off the limits
[16:59:49] <alex_joni> sounds good enough for me.. (4-5 hal lines)
[17:00:12] <rayh> sounds like bs to me.
[17:00:20] <jmkasunich> I wish I completely understood the "home is shared" stuff that jepler did
[17:00:35] <jmkasunich> that might convey the info neccessary to deal with this in the motion controller
[17:00:39] <jmkasunich> (or it might not)
[17:01:58] <cradek> shared only means don't start homing when already sitting on the home switch
[17:02:14] <jmkasunich> I thought it was something like that
[17:02:16] <cradek> because when you do the initial "back off" move you might be backing the wrong axis and crash
[17:02:54] <jmkasunich> the way I see it, the motion controller's job it to provided a "canonical axis"
[17:03:18] <jmkasunich> and when an intergrator does weird things like share switches, the integrator gets to work out the logic
[17:03:57] <jmkasunich> that way they can suit whatever particular combination of sharing they are using
[17:04:20] <cradek> my opinion is the HOME_IGNORE_LIMITS in the ini is there for backward compatibility only (it only lets you do the simplest case) - the axis.N.homing outputs let you do any configuration you want
[17:04:24] <rayh> Is there only the 2 input or?
[17:04:55] <jmkasunich> I think jepler wrote a much more capable logic gate component (configurable number of inputs)
[17:05:08] <jmkasunich> not sure its in 2.1, and would have to check to see if it does what I think it does
[17:05:47] <jmkasunich> in head, its called "logic"
[17:05:48] <cradek> I've used match8 (clumsily) to make a larger logic gate
[17:05:56] <rayh> I guess it would be a lot faster to do this in cl if it has to be done at the HAL level.
[17:06:23] <jmkasunich> it would kinda suck if thats the only thing you need ladder for
[17:06:36] <rayh> I thought about adding em watching the sum
[17:06:38] <jmkasunich> but if you already have even one rung, then another rung or two definitely makes sense as the cleanest way
[17:07:05] <rayh> as long as we are thinking about ways to work around another of those things that ought to be accomplished by task.
[17:07:32] <jmkasunich> task?
[17:07:34] <alex_joni> rayh: in an ideal world, I agree
[17:07:35] <rayh> It's not a rung, its a rung for each axis.
[17:07:54] <jmkasunich> task can't handle limits and homes, its too slow
[17:08:06] <cradek> bbl
[17:08:06] <alex_joni> but as it is now, task is a hardcoded thing with little options for the integrator to change that
[17:08:28] <jmkasunich> ----|xhoming|-----|yhoming|------|zhoming|-------(homing)----
[17:09:06] <jmkasunich> ----|parport.pin.whatever.in|-------|\homing|--------(onlimit)-----
[17:09:15] <jmkasunich> then send onlimit to the axis.N.limit pins
[17:09:28] <jmkasunich> parport.pin.whatever.in goes direct to the axis.N.home pins
[17:10:46] <alex_joni> jmkasunich: I think you need to invert the logic on homing
[17:10:57] <jmkasunich> duh, right
[17:11:00] <alex_joni> use NC contacts that open when homing one joint
[17:11:12] <jmkasunich> its harder to draw parallel rungs in ascii art!
[17:11:29] <alex_joni> you're forgiven :P
[17:11:42] <jmkasunich> actually, you can do it in one rung
[17:11:53] <alex_joni> right..
[17:12:21] <jmkasunich> on the left, you have parallel rungs for /homingx, /homingy, /homingz
[17:12:22] <alex_joni> ---|parport.pin|---|\xhoming|--|\yhoming|--|\zhoming|--(onlimit)
[17:14:01] <jmkasunich> right
[17:14:43] <rayh> * rayh goes off to see what he can fail at next.
[17:20:52] <rayh> I see that home vel without latch vel won't work either.
[17:21:32] <rayh> And that when the home routine finds the second home switch trip it faults on a limit anyway.
[17:22:05] <jmkasunich> huh?
[17:24:33] <rayh> It doesn't seem to move to the home offset position.
[17:30:19] <rayh> Looks to me like what happens is that it ignores a negitive home offset.
[17:30:34] <rayh> back after lunch.
[17:40:34] <jmkasunich> hmm
[17:40:49] <jmkasunich> looks like I had connection problems
[17:40:52] <jmkasunich> rayh, you there?
[17:41:00] <alex_joni> netsplit for you jmkasunich
[17:41:10] <alex_joni> 20:25 -!- Netsplit sterling.freenode.net <-> irc.freenode.net quits: tfmacz,
[17:41:10] <alex_joni> jmkasunich, skunkworks, roltek
[17:41:10] <alex_joni> 20:28 < rayh> Looks to me like what happens is that it ignores a negitive home
[17:41:13] <alex_joni> offset.
[17:41:13] <alex_joni> 20:29 < rayh> back after lunch.
[17:41:16] <alex_joni> 20:38 -!- Netsplit over, joins: roltek, jmkasunich
[17:41:30] <jmkasunich> figures
[17:41:46] <jmkasunich> everything I said to ray went into the bitbucket
[17:42:31] <jmkasunich> what was the last thing you saw from me?
[17:43:51] <alex_joni> 20:20 < jmkasunich> huh?
[17:43:59] <jmkasunich> ok, lemme repost the rest
[17:44:09] <jmkasunich> http://www.linuxcnc.org/docs/devel/html/config/ini_homing/index.html
[17:44:15] <jmkasunich> can you take a look at that page?
[17:44:22] <alex_joni> * alex_joni ?
[17:44:22] <jmkasunich> (I need visual aids to communicate)
[17:44:28] <alex_joni> er.. me?
[17:44:29] <jmkasunich> search vel without latch vel is an error - as stated in the paragraph labeled "latch_vel"
[17:44:54] <jmkasunich> alex_joni: this is the answers that I was trying to give ray
[17:45:03] <jmkasunich> I didn't know I was offline
[17:45:11] <jmkasunich> if you use the approach in the first drawing (latch vel has opposite sign as search vel) then you should be ok, cause once the homing is done, you are off the switch
[17:45:24] <jmkasunich> if you use the approach in the 2nd drawing, you are also OK, but only if you have home != home_offset, so that you move off the switch after the latch phase
[17:45:39] <jmkasunich> otherwise, as soon as homing finishes, the limits are enabled, and you trip because you parked on a limit
[17:45:51] <jmkasunich> * jmkasunich heads to the range to turn perfectly good ammo into smoke and noise and holes in paper
[17:46:04] <jmkasunich> there - ray can read that when he gets back
[17:46:11] <jmkasunich> I'll be gone for a few hours
[17:47:24] <alex_joni> jmkasunich: just don't start shooting in the wrong directions
[17:47:37] <alex_joni> did you get what I wrote in -board?
[18:59:00] <rayh> So I take it we can no longer do a single home motion.
[19:01:46] <rayh> And it looks like from jmks description that the definitions of home_offset and home have been inverted.
[19:02:27] <rayh> home offset used move off the switch by the value set there.
[19:02:50] <rayh> It seemed to me that it did that when home offset was positive but not negitive.
[20:36:04] <jmkasunich> rayh: single home motion means go to the switch, and stop when you hit it?
[20:55:36] <rayh> back sorry I was away.
[20:55:52] <rayh> did you shread lots of targets?
[20:56:14] <alex_joni> * alex_joni wonders who's photos jmk shot
[20:56:15] <jmkasunich> yeah
[20:56:22] <jmkasunich> no photos, just circles
[20:56:29] <rayh> Probably rath
[20:56:33] <rayh> rayh
[20:56:39] <rayh> can't even type.
[20:56:40] <jmkasunich> 281, 285, and 290 out of 300 possible ;-)
[20:56:49] <alex_joni> you need to practice more :P
[20:56:53] <alex_joni> kidding..
[20:56:57] <jmkasunich> ;P
[20:57:05] <rayh> The original homing motion went to the switch then retreated to home_offset.
[20:57:46] <rayh> I don't see that happening at all now.
[20:57:58] <jmkasunich> the second move was added to allow slow (and thus precise) location of the switch, without waiting all day for it to travel the whole length of the table
[20:58:15] <jmkasunich> now it finds the switch going fast, then makes a slow pass to refine position
[20:58:23] <rayh> Sure I understand that and can live with it.
[20:58:26] <jmkasunich> did you see the drawing at the URL I posted?
[20:58:33] <cradek> you can locate the home position while backing off
[20:58:39] <rayh> What I find disconcerting is the home offset.
[20:58:39] <jmkasunich> that shows how home and offset work
[20:59:00] <rayh> I don't want to find home backing off. I want to move back a known distance.
[20:59:20] <rayh> So that I can set my soft limits to have a cushion.
[20:59:20] <jmkasunich> ray: see the 2nd drawing here:
[20:59:24] <jmkasunich> http://www.linuxcnc.org/docs/devel/html/config/ini_homing/index.html
[20:59:35] <rayh> I've gone over that several times.
[20:59:42] <jmkasunich> ok, what is the issue then?
[20:59:51] <rayh> I do not get a retreat when I set home offset.
[20:59:53] <rayh> and I used to.
[20:59:58] <rayh> that is all im saying
[21:00:05] <cradek> HOME_OFFSET is the location of the switch. HOME is the final position
[21:00:11] <jmkasunich> I cannot guarantee that it works the way it used to
[21:00:36] <jmkasunich> especially since at the time I was writing that code I could find no docs that clearly explained what it did
[21:00:46] <jmkasunich> I can guarantee that it works they way that drawing describes
[21:00:49] <rayh> and that is not at all how it used to be.
[21:00:56] <jmkasunich> (and if ti doesn't I'll fix it)
[21:01:09] <rayh> I used a negitive home offset and got nothing. is that a part of that drawing?
[21:01:19] <jmkasunich> home and home-offset interact
[21:01:33] <jmkasunich> what are you using for HOME ?
[21:01:36] <rayh> and that's the shits
[21:01:47] <jmkasunich> what are you using for HOME ?
[21:01:57] <rayh> 0
[21:02:01] <jmkasunich> ok
[21:02:12] <rayh> i want home to be zero so I set home 0
[21:02:17] <jmkasunich> HOME is "where it goes when the entire homing process is done"
[21:02:28] <jmkasunich> HOME_OFFSET is "where the switch is, in machine coords"
[21:02:43] <jmkasunich> if you set home offset to -1, you are saying the switch is -1 relative to the home position
[21:02:47] <rayh> Ands that is exactly opposite what it used to do,
[21:03:12] <rayh> and it is fucking confusing.
[21:03:13] <jmkasunich> well, it would have been nice if we had this conversation two years ago when I wrote the homing code and that drawing
[21:03:39] <jmkasunich> I tried to figure out what the old code did, but it was documented poorly if at all
[21:03:43] <rayh> so if I want my zero position -.25 away from the switch what do I do
[21:03:53] <jmkasunich> set home offset to 0.25, and home to zero
[21:04:21] <jmkasunich> it will find the switch, say "this is 0.25, now I want to go to zero" so it will move -0.25
[21:04:21] <rayh> and if +.25
[21:04:43] <jmkasunich> you want your home position +0.25 from the switch?
[21:05:08] <jmkasunich> that means the switch is at the negative end of travel then, so that you can move positive away from it (mirror image of the drawing)
[21:05:11] <rayh> I wasn't able to give a negative number to home offset at all
[21:05:21] <jmkasunich> set home offset to -0.25, and home to zero
[21:05:45] <jmkasunich> and set search vel negative
[21:06:03] <jmkasunich> if home is 0.25 to the plus of the switch, then the switch can't be at the plus end of travel
[21:07:06] <rayh> and the middle of travel was the undefined thing you guys talked about a while back.
[21:07:22] <jmkasunich> ?
[21:07:35] <rayh> If the switch was in the middle
[21:07:37] <jmkasunich> you mean if you want the home switch to be in the middle of the travel?
[21:07:44] <jmkasunich> that can work too, under two conditions:
[21:07:52] <jmkasunich> 1) you can't use a limit for the home ;-)
[21:08:02] <jmkasunich> 2) the home needs to remain tripped once you pass it
[21:08:12] <rayh> you approach from the same side always
[21:08:18] <jmkasunich> (otherwise if its not tripped, you have no clue which side of it you are on)
[21:08:29] <jmkasunich> yeah, that is a replacement for 2
[21:08:42] <jmkasunich> if you never hit the home button while on the wrong side, it will work
[21:09:17] <rayh> Okay. Damn lot harder to explain than the old way.
[21:09:28] <rayh> but hey things change
[21:09:40] <jmkasunich> only harder when you already know the old way
[21:09:51] <rayh> No I don't think so.
[21:09:57] <rayh> the vars didn'
[21:09:58] <jmkasunich> I sure didn't think it was harder - but I had to draw that picture to be clear about _any_ way
[21:10:03] <jmkasunich> words failed me
[21:10:06] <rayh> t interact in the old way
[21:10:26] <jmkasunich> then what did the vars mean the old way?
[21:10:47] <rayh> home offset was a position away from the home switch
[21:10:58] <jmkasunich> then what was HOME?
[21:11:10] <rayh> Home was the position assigned to the place where homing completed
[21:11:29] <jmkasunich> "homing completed" you mean where it when when it finished the entire process?
[21:11:49] <jmkasunich> damn I can't type
[21:12:03] <rayh> me either.
[21:12:04] <jmkasunich> "homing completed" you mean where it went when it finished the entire homing process?
[21:12:35] <rayh> I'd better get on the road. Long trip home.
[21:12:44] <jmkasunich> ok, have a safe drive
[21:13:43] <rayh> Thanks. With your help I can get this going.
[21:13:59] <rayh> I'll plan on starting classicladder so that I can ignore limits.
[21:15:24] <rayh> Maybe when we get into task for real we can sort out some of these other issues.