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