Back
[01:11:01] <jmkasunich> sigh
[01:11:21] <jmkasunich> just read stuart stevenson's homing woes
[01:12:26] <SWPadnos> is that with "home to index" only (you think)?
[01:12:41] <jmkasunich> I only know what he said
[01:13:10] <jmkasunich> I can't see how the new home-to-index-only code could change states unless the driver tells it "I saw an index"
[01:13:14] <SWPadnos> 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?
[01:13:21] <jmkasunich> yes
[01:13:39] <SWPadnos> ok. I thought I saw a comment about no limit switches either - was that so?
[01:13:46] <jmkasunich> 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)
[01:14:03] <SWPadnos> right, as long as he goes the right way, and started in the correct 0.2" region
[01:14:06] <jmkasunich> switches are irrelevant
[01:14:22] <SWPadnos> separate, but in the original discussion I think
[01:14:39] <SWPadnos> I was trying to think about how you'd stop a runaway motor drive without limit switches ...
[01:14:53] <jmkasunich> 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
[01:14:54] <SWPadnos> maybe a microphone for the big thunk
[01:15:00] <SWPadnos> right
[01:15:23] <jmkasunich> them's who don't use switches are making an engineering decision that they need to live with
[01:15:33] <jmkasunich> if the machine is tiny/weak, its fine
[01:15:40] <SWPadnos> heh - hopefully their employees and machines can live with the decision as well
[01:15:47] <jmkasunich> if its big and strong, thats not the decision I would make
[01:16:02] <SWPadnos> me either - that's why I was curious
[01:16:24] <SWPadnos> but anyway - his homing thing looks almost as though the index-enable mode isn't getting initialized correctly or something
[01:16:49] <jmkasunich> or something being almost certainly in the ppmc or its driver
[01:16:53] <SWPadnos> could be
[01:17:10] <jmkasunich> some observation with halscope would tell the tale
[01:17:15] <SWPadnos> indeed
[01:17:20] <jmkasunich> but I'm in Cleveland and Stuart is in Wicheta
[01:17:44] <SWPadnos> 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)
[01:17:46] <cradek> I expect to be back down there in a few weeks.
[01:17:54] <SWPadnos> that sounds fun
[01:19:24] <cradek> 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.
[01:19:36] <jmkasunich> darn
[01:19:54] <jmkasunich> I suppose I should take a look at it
[01:20:41] <cradek> if you're not deep in other stuff
[01:20:47] <cradek> (pun intended)
[01:20:58] <jmkasunich> not at the moment
[01:21:10] <cradek> I have 9 axis working pretty well...
[01:21:12] <jmkasunich> not sure how long thats gonna last tho
[01:24:05] <cradek> when I tested it, I saw the expected state transitions, but I couldn't decipher what the different axis/joint positions should do
[01:27:13] <jmkasunich> its hard without a real machine
[01:27:31] <cradek> yep
[01:34:13] <cradek> g0x1y2z3a45b60c85u2v3w4
[01:34:19] <jmkasunich> bless you
[01:34:30] <cradek> wheee
[01:34:37] <jmkasunich> need a kleenex?
[01:34:46] <cradek> I did not expect this to work so well so soon.
[01:36:57] <cradek> oh hmm, forget it, I broke G1
[01:37:05] <cradek> that's actually pretty amazing
[01:38:26] <jmkasunich> what is?
[01:38:34] <cradek> that I managed to break G1 but not G0
[01:38:56] <jmkasunich> you're right
[01:38:59] <cradek> x = FROM_PROG_LEN(u);
[01:38:59] <cradek> y = FROM_PROG_LEN(v);
[01:38:59] <cradek> z = FROM_PROG_LEN(w);
[01:39:01] <cradek> oh, duh
[01:39:21] <cradek> if they were only all that easy to find
[01:39:47] <cradek> that's much better
[01:44:39] <jepler> I see a new version of 'tort' :-P
[01:45:19] <cradek> that would be great
[01:45:27] <cradek> it will be harder to see if it's right, though
[01:45:50] <jepler> indeed
[01:49:01] <cradek> have you run the branch yet?
[01:49:11] <cradek> we really will want your changes to allow/disallow certain axes
[01:49:36] <cradek> brb
[01:52:18] <jepler> I imagine you will
[01:59:27] <jmkasunich> the behavior of index only homing using servo-sim seems fine to me
[01:59:52] <jmkasunich> I set up the sim to have 1000 lines (4000 counts) per motor rev, and 8000 counts per inch
[02:00:02] <jmkasunich> each time you tell it to home, it moves 1/2 inch
[02:00:20] <jmkasunich> +1/2 inch, since latch-vel is positive
[02:00:39] <jmkasunich> if you jog a little to the left first, it just moves the distance you jogged, and homes at the same spot as before
[02:00:49] <jmkasunich> if you jog to the right, it moves 1/2" - the distance you jogged
[02:03:29] <jmkasunich> scary
[02:03:39] <jmkasunich> I just realized I did those tests running sim on a non-rt box
[02:04:21] <jepler> what's scary about that?
[02:04:51] <jmkasunich> that I forgot what I was running
[02:05:57] <jmkasunich> bbl
[02:10:41] <jepler> so for a [TRAJ]COORDINATES=XYZ UVW machine what is the proper setting if [TRAJ]AXES ?
[02:13:54] <jepler> I'm afraid I've worked the problem several times, and I keep getting the answer "9"
[02:33:47] <cradek> jepler: can you explain how it helps to have the user figure out [traj]axes? I don't see what it helps
[02:35:15] <cradek> I think I agree that with the current implementation it would have to be 9
[02:36:50] <jepler> cradek: [TRAJ]AXES is used in the default .hal files
[02:37:13] <cradek> oh, right
[02:37:32] <cradek> I think that's only to not clutter halspace with axis.largenumber.whatever stuff
[02:37:58] <cradek> (it's clearly not enough information to say which axes are used)
[02:44:04] <jepler> TypeError: arc_feed() takes exactly 10 arguments (13 given)
[02:44:22] <cradek> oops, loading a program with arcs in axis?
[02:44:28] <cradek> I guess I didn't try that yet
[02:44:50] <cradek> I always have trouble finding/following all the layers of axis
[02:51:22] <jepler> I "fixed" the arc thing
[02:51:32] <jepler> but yeah it is a bit .. layered
[02:51:59] <cradek> I did too - but yours is probably better
[02:52:08] <cradek> commit whenever you like
[02:52:31] <jepler> I've got a whole ball of stuff to commit after I debug it
[02:52:34] <jepler> the "mask of axes" stuff
[02:52:39] <cradek> neat
[02:53:31] <cradek> hope you don't mind me jumping into your project - I've just thought for a while that we should have this
[03:06:53] <jepler> that's OK, I'd kinda petered out
[03:06:58] <jepler> you did it a better way than me, I think
[03:08:38] <cradek> axis doesn't let me jog the new axes
[03:08:49] <cradek> oh I guess the widgets aren't there
[03:20:01] <jepler> that's it for me tonight
[03:20:11] <cradek> goodnight
[03:20:13] <cradek> me too
[03:20:17] <jepler> see you
[13:09:51] <jepler> 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
[13:11:46] <jepler> a different but related problem exists for XYYZ machines
[13:12:01] <jepler> and what about [TRAJ]HOME?
[14:58:41] <cradek_> cradek_ is now known as cradek
[21:13:46] <cradek> jepler: um, what's [TRAJ]HOME do again?
[21:21:01] <jepler> cradek: for nontrivial machines, it's the value given as the "prior position" when going from joint mode to world mode
[21:28:16] <cradek> then I guess I have no idea
[21:47:06] <jmkasunich> cradek: I think its the cartesean position that corresponds to each joint being at its home pos
[21:47:37] <jmkasunich> usually redundant, but in some cases, there can be more than one cartesean pos for a given set of joint coords
[21:47:49] <jmkasunich> (mostly parallel kins machines like hexapods)