just read stuart stevenson's homing woes
is that with "home to index" only (you think)?
I only know what he said
I can't see how the new home-to-index-only code could change states unless the driver tells it "I saw an index"
I only scanned that discussion - is the home to index idea that you get close by hand (by eye - with marks), then use just index to get the fine adjustment?
ok. I thought I saw a comment about no limit switches either - was that so?
so he should be able to start anywhere in a 0.2" region and have it home at the same spot (the next index pulse)
right, as long as he goes the right way, and started in the correct 0.2" region
switches are irrelevant
separate, but in the original discussion I think
I was trying to think about how you'd stop a runaway motor drive without limit switches ...
no matter where he starts, the new code breaks the entire axis into 0.2" chunks, and when you start anywhere in a chunk, you wind up homed at the left or right edge of that chunk depending on the sign of latch-vel
maybe a microphone for the big thunk
them's who don't use switches are making an engineering decision that they need to live with
if the machine is tiny/weak, its fine
heh - hopefully their employees and machines can live with the decision as well
if its big and strong, thats not the decision I would make
me either - that's why I was curious
but anyway - his homing thing looks almost as though the index-enable mode isn't getting initialized correctly or something
or something being almost certainly in the ppmc or its driver
some observation with halscope would tell the tale
but I'm in Cleveland and Stuart is in Wicheta
I wonder if he has the latest EEPROM from Jon, the one that was working with rigid tapping (or home to index - whatever Jon did just before CNC workshop)
I expect to be back down there in a few weeks.
that sounds fun
jmkasunich: servo_sim does have index pulses. I couldn't quite follow what it was doing though - maybe you can do it better. I didn't spend all that much time on it.
I suppose I should take a look at it
if you're not deep in other stuff
not at the moment
I have 9 axis working pretty well...
not sure how long thats gonna last tho
when I tested it, I saw the expected state transitions, but I couldn't decipher what the different axis/joint positions should do
its hard without a real machine
need a kleenex?
I did not expect this to work so well so soon.
oh hmm, forget it, I broke G1
that's actually pretty amazing
that I managed to break G1 but not G0
x = FROM_PROG_LEN(u);
y = FROM_PROG_LEN(v);
z = FROM_PROG_LEN(w);
if they were only all that easy to find
that's much better
I see a new version of 'tort' :-P
that would be great
it will be harder to see if it's right, though
have you run the branch yet?
we really will want your changes to allow/disallow certain axes
I imagine you will
the behavior of index only homing using servo-sim seems fine to me
I set up the sim to have 1000 lines (4000 counts) per motor rev, and 8000 counts per inch
each time you tell it to home, it moves 1/2 inch
+1/2 inch, since latch-vel is positive
if you jog a little to the left first, it just moves the distance you jogged, and homes at the same spot as before
if you jog to the right, it moves 1/2" - the distance you jogged
I just realized I did those tests running sim on a non-rt box
what's scary about that?
that I forgot what I was running
so for a [TRAJ]COORDINATES=XYZ UVW machine what is the proper setting if [TRAJ]AXES ?
I'm afraid I've worked the problem several times, and I keep getting the answer "9"
jepler: can you explain how it helps to have the user figure out [traj]axes? I don't see what it helps
I think I agree that with the current implementation it would have to be 9
cradek: [TRAJ]AXES is used in the default .hal files
I think that's only to not clutter halspace with axis.largenumber.whatever stuff
(it's clearly not enough information to say which axes are used)
TypeError: arc_feed() takes exactly 10 arguments (13 given)
oops, loading a program with arcs in axis?
I guess I didn't try that yet
I always have trouble finding/following all the layers of axis
I "fixed" the arc thing
but yeah it is a bit .. layered
I did too - but yours is probably better
commit whenever you like
I've got a whole ball of stuff to commit after I debug it
the "mask of axes" stuff
hope you don't mind me jumping into your project - I've just thought for a while that we should have this
that's OK, I'd kinda petered out
you did it a better way than me, I think
axis doesn't let me jog the new axes
oh I guess the widgets aren't there
that's it for me tonight
we'll want to have a machine with joints 0 and 1, but axes 0 and 2 (X and Z).. gantrykins can do this but I'm not sure how axis will work
a different but related problem exists for XYYZ machines
and what about [TRAJ]HOME?
cradek_ is now known as cradek
jepler: um, what's [TRAJ]HOME do again?
cradek: for nontrivial machines, it's the value given as the "prior position" when going from joint mode to world mode
then I guess I have no idea
cradek: I think its the cartesean position that corresponds to each joint being at its home pos
usually redundant, but in some cases, there can be more than one cartesean pos for a given set of joint coords
(mostly parallel kins machines like hexapods)