Back
[04:27:02] <cradek> what happened to my weekend?
[04:29:51] <jmkasunich> dunno, you tell me
[04:31:00] <jmkasunich> you did some stuff, and then you worked on that thing, and then you did that other thing, and got some stuff from that store, and...
[04:32:04] <jmkasunich> I've been writing down indicator readings and spreadsheeting
[04:32:19] <cradek> did you do the other screws?
[04:32:25] <jmkasunich> working on Y
[04:32:53] <jmkasunich> It has about 0.0075 backlash and about 0.001 variability, when measured every half inch
[04:33:08] <jmkasunich> when measured every 0.010, it has another thou of periodic error once per turn (0.100")
[04:33:33] <jmkasunich> (I've only measured the periodic error at two places, over a distance of 0.1" each place
[04:33:44] <jmkasunich> gonna do another when I stop procrastinating
[04:34:30] <cradek> sounds sooo tedious
[04:34:35] <cradek> you must be very patient
[04:34:56] <jmkasunich> perfectionist
[04:35:19] <jmkasunich> trying to silk-pursify a sow's ear
[04:36:04] <jmkasunich> I found a linear error on Y as well - about 0.0003" per inch, very similar to Z
[04:36:20] <cradek> interesting
[04:36:21] <jmkasunich> which is odd, given that one is a surplus ballscrew and the other is a chinese acme
[04:37:03] <cradek> how much could temperature cause?
[04:37:38] <cradek> I forget if you said they're short or long
[04:37:55] <jmkasunich> I had to lower my scale values
[04:38:18] <jmkasunich> temperature should cause very little, since both the gage blocks and the screws are steel, and both are at the same temp
[04:38:43] <cradek> only if you let the blocks set a while after you assemble them
[04:38:53] <cradek> (not that this could cause enough difference)
[04:39:00] <jmkasunich> you mean just from handling?
[04:39:07] <jmkasunich> I didn't handle them that much
[04:40:53] <jmkasunich> hmm, temperature does raise another possibility though
[04:41:11] <jmkasunich> when they were making the screws, I'm sure they warmed up relative to the machine
[04:41:22] <jmkasunich> (although flood coolant would minimize that you'd think)
[04:42:46] <jmkasunich> so what did happen to your weekend?
[04:43:08] <cradek> well two hours midday today involved a nap
[04:43:19] <cradek> that never helps the weekend last, but is pleasant
[04:43:25] <jmkasunich> yeah
[04:43:31] <jmkasunich> I took time out today to read a book
[04:43:54] <jmkasunich> something mindless but amusing
[04:44:27] <cradek> that's pleasant too
[04:44:41] <cradek> I have been meaning to get to the library - I'm out of books currently
[04:45:20] <cradek> I think I drive them crazy - instead of starting at the computer, I pick stuff from the shelves. Seems like every time I find something that's not in their inventory
[04:49:08] <jmkasunich> sounds like they have crappy inventory
[04:49:26] <jmkasunich> when I'm just looking for something to read I never use the catalog
[04:50:27] <cradek> I like to find weird old stuff
[04:50:35] <cradek> probably not checked out since B.C.
[04:50:40] <jmkasunich> heh
[04:50:51] <jmkasunich> half-price books is good for that
[04:51:13] <jmkasunich> I got a copy of Eschbach's Handbook of Engineering Fundamentals for 9.95 once
[04:51:19] <jmkasunich> new it sells for well over $100
[04:51:33] <jmkasunich> this was probably a 50s or 60s edition
[04:51:49] <cradek> cool
[04:52:14] <jmkasunich> I have an assortment of old tech books - machining, etc
[04:52:26] <cradek> I try hard not to buy books anymore...
[04:53:13] <cradek> I really hit abebooks.com for a while
[04:53:24] <cradek> it's an index of lots of little book shops
[04:54:27] <jmkasunich> sounds dangerous
[04:56:07] <cradek> hmm, I guess amazon has that too now
[04:56:24] <cradek> http://www.amazon.com/gp/offer-listing/0592027066/ref=dp_olp_2/105-8293362-5238034
[04:57:09] <cradek> I looked for this book pretty hard several years ago
[04:57:42] <jmkasunich> for building clocks?
[04:57:42] <cradek> it's a nice summary of pre-transistor computing technology
[04:57:57] <cradek> I did build a no-transistor all-electronic clock
[04:58:06] <cradek> it has never worked right :-)
[04:58:26] <cradek> one day I'll get back to it
[04:58:40] <jmkasunich> no transistors eh?
[04:58:45] <jmkasunich> did you use tubes?
[04:58:46] <cradek> nope
[04:58:48] <cradek> yes
[04:58:58] <cradek> dekatrons and triodes
[04:59:22] <jmkasunich> I thought you were gonna say you used diacs or something ;-)
[04:59:26] <cradek> you could do it with all neon bulbs, but it would not work reliably
[04:59:51] <cradek> you have to carefully age and match them
[05:00:15] <cradek> trigger tubes are much better, but unavailable
[05:00:29] <jmkasunich> I used a neon at work a while back, for a prototype of a high power crowbar
[05:00:46] <jmkasunich> if V > 800V, fire 500A SCR
[05:01:17] <cradek> sounds scary
[05:01:43] <jmkasunich> had a 720V stack of zeners feeding a 0.1uF or so cap, so it had about 80V in it
[05:01:44] <cradek> resistive divider so the neon fires at the right voltage?
[05:01:55] <cradek> ah
[05:02:16] <jmkasunich> the neon dumped part of the cap charge into the gate of a small SCR, which dumped the rest into the gate of the main SCR
[05:03:38] <jmkasunich> the production version has about 10 times as many parts
[05:03:47] <cradek> ha
[05:03:51] <jmkasunich> (and is also about 20 times more accurate on threshold voltage)
[05:04:26] <jmkasunich> zeners are only good for 5% at best
[05:05:05] <cradek> you could hand tune one, but for production it wouldn't be good enough
[05:05:11] <jmkasunich> right
[05:05:43] <jmkasunich> I remember when every product had a half-dozen trim pots
[05:05:44] <cradek> I bet I'll be the only one at work tomorrow...
[05:05:58] <jmkasunich> surf's up!
[05:06:01] <cradek> ha
[05:08:22] <jmkasunich> I should either take another set of readings, or go to sleep
[05:08:32] <jmkasunich> the latter would be smart, think I'll do the former
[05:08:38] <jmkasunich> (and then the latter)
[05:08:40] <cradek> I'm leaning toward sleep personally
[05:08:56] <cradek> when do you go back to work?
[05:09:28] <jmkasunich> jan 2
[11:15:57] <kloeri> [Global Notice] Hi all, we're celebrating New Years in #freenode-newyears. Happy New Years from freenode staff and thank you for using freenode.
[12:52:04] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[12:55:53] <cradek> haha xkcd
[13:18:33] <skunkworks259> feels odd coming back to work after a week off..
[13:31:28] <skunkworks259> logger_dev: boommark
[13:31:28] <skunkworks259> I'm logging. I don't understand 'boommark', skunkworks259. Try /msg logger_dev help
[13:31:35] <skunkworks259> logger_dev: bookmark
[13:31:35] <skunkworks259> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-12-31.txt
[13:44:16] <skunkworks259> http://www.cnczone.com/forums/showthread.php?t=49477
[14:09:30] <jepler> hi skunkworks259
[14:11:22] <skunkworks259> good morning jepler.
[14:12:16] <skunkworks259> jepler: did you have a good few days off?
[14:13:09] <jepler> skunkworks259: unfortunately I spent most of the last two weeks suffering from a cold .. so it could have been better
[14:16:07] <skunkworks259> yeck.. I have dodged the bullet so far.
[14:16:15] <skunkworks259> everyone seems to be sick around here.
[14:18:22] <skunkworks259> I don't know if you saw this.. very happy on how it turned out. grouting this week.
http://www.electronicsam.com/images/house/floor.JPG
[14:18:53] <skunkworks259> wife now knows how long things take.. she thought we would have the whole kitchen done over the week vacation.
[14:18:55] <jepler> nope, hadn't seen it
[14:19:34] <jepler> you should meet my friend Michael. I think it's nearly 4 years since he and his wife started their kitchen renovation project..
[14:20:00] <skunkworks259> heh - my wife would freak out and die.. ;)
[14:23:41] <skunkworks259> I figure about 2 more weeks..
[14:23:52] <skunkworks259> if we don't have any suprises.
[14:25:36] <skunkworks259> the floor was probably the hard part.. we still have to knock a 'window' in the wall between the kitchen and the dining room.
[14:26:06] <jepler> I hate 'home improvement' stuff
[14:26:37] <skunkworks259> we have decided we don't like 'home improvement' either :)
[14:28:24] <skunkworks259> this is a pretty inexpensive home improvement.. we are re-using the kitchen cabenets. they are hickory and still in very good shape.
[14:29:50] <skunkworks259> jepler: did you try out your hardware stepgen for the pluto yet? I saw you mention it.
[14:32:57] <jepler> skunkworks259: nope, still haven't.
[14:48:56] <jepler> hmm -- the "step" (if there is one) is tiny, but the accel and vel sure spike at that one point.
http://emergent.unpy.net/files/sandbox/homing-position-step.png http://emergent.unpy.net/files/sandbox/homing-position-step-2.png
[14:54:08] <cradek> what does everyone think about G28.1, G30.1 to set the reference positions to the current absolute position? My BOSS has something like this (actually a front panel button)
[15:01:12] <cradek> it also uses a reference point for the tool change location, which is neat, since a workpiece might be obstructing any particular part of the table - you just set it somewhere else
[15:04:01] <cradek> I'd like that in emc too, but I'd have to move the tool change location from the ini into vars
[15:17:40] <jmkasunich> cradek: when you saw "reference positions", what does that mean?
[15:17:45] <jmkasunich> G54 coords?
[15:19:19] <cradek> g28 and g30 are special gcodes that move to a set point in axis space, disregarding all the kinds of offsets
[15:19:25] <jmkasunich> jepler: that step - were you doing home to index?
[15:20:03] <cradek> the setpoints (called reference points in the docs) are in #vars
[15:20:31] <jmkasunich> so its not a coord system change, just "remember this spot" ?
[15:20:37] <cradek> right
[15:20:54] <cradek> this axis position, NOT this tooltip position
[15:21:11] <jmkasunich> oh, length and dia comp not included
[15:21:20] <cradek> right
[15:21:39] <jmkasunich> seems interesting,but I dunno about using G28 for it
[15:21:57] <cradek> huh? that's already what g28 does
[15:22:00] <jmkasunich> once you do G28.1, you've lost your original reference position
[15:22:08] <jmkasunich> G28 moves to that point
[15:22:13] <jmkasunich> it doesn't change where that point is
[15:22:20] <jmkasunich> (unless I'm misreading things)
[15:22:22] <cradek> g28 has always been a configurable refernce position
[15:22:33] <jmkasunich> configurable in the ini file
[15:22:41] <cradek> no, configurable in gcode/mdi
[15:22:42] <jmkasunich> and fixed from then on
[15:22:45] <skunkworks259> var file.
[15:22:45] <cradek> nope
[15:22:47] <jmkasunich> oh
[15:22:50] <jmkasunich> * jmkasunich shuts up
[15:22:56] <cradek> #5161=3.1416
[15:23:03] <cradek> it was just a pain to set it
[15:23:17] <jmkasunich> so 5161 is a magic var?
[15:23:26] <cradek> you had to divine the machine coordinates which might not be shown on your screen, or might be shown in another length unit
[15:23:47] <skunkworks259> * skunkworks259 also used it to set the tool length microswitch position..
[15:23:53] <cradek> yes 5161..5169 are g28 position, 5181..5189 are g30
[15:24:12] <cradek> yes for example I've used g30 to be over the tool length sensor
[15:24:20] <jmkasunich> in that case, your proposal makes perfect sense
[15:24:53] <cradek> it's just a "UI" simplification really (if gcode can be considered a UI)
[15:24:57] <jmkasunich> g28 and 30 are in effect equivalent to g53 g0 X#5161 Y#5162 ... ?
[15:25:12] <cradek> yes exactly
[15:25:37] <cradek> well they have other obscure meaning but pretty much that's right
[15:25:48] <jepler> only if you're in the same distance units as your inifile
[15:25:55] <jepler> otherwise it could be off by a factor of 25.4
[15:26:00] <jmkasunich> oh, right
[15:26:15] <cradek> bleh
[15:26:21] <jmkasunich> so g28 and 30 are safer ways of doing that
[15:26:30] <jepler> jmkasunich: no, I think it's just home to switch. however, I think maybe I have screw comp in that configuration -- haven't checked yet, real work is calling
[15:26:31] <cradek> g28/g30 also have an intermediate point, and can move a subset of the axes
[15:26:45] <cradek> but never mind that
[15:27:21] <jmkasunich> screw comp could give you a small jump I think
[15:27:32] <jmkasunich> but I thought that passed through accel and vel limiting
[15:28:00] <jmkasunich> (the signal from screw comp replaces the backlash correction signal, and then goes thru the same processing, or at least it should)
[15:28:20] <jmkasunich> I'm gonna be setting up screw comp on my Y today, I'll do some testing
[15:29:30] <CIA-20> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (5 files): G28.1, G30.1 to set the corresponding reference point to the current position
[15:30:46] <jmkasunich> heh, was it really that easy, or did you have it coded up before you asked about it?
[15:30:56] <cradek> I won't say
[15:31:24] <jmkasunich> "that's my story and I'm stickin' to it!"
[15:35:03] <jmkasunich> I suppose it would be possible to have [AXIS_n]HOME_FINAL_VEL, and if not set, use the G0 value
[15:40:46] <cradek> haha
[15:41:23] <jmkasunich> they really want that "feature" don't they?
[15:41:44] <cradek> yes but I haven't seen a (believable) reason yet
[15:42:18] <jmkasunich> the reason is that "I want it to"
[15:42:25] <jmkasunich> I = bigjohn
[15:42:30] <cradek> yes
[15:48:47] <jmkasunich> part of me wants to go ahead and do it
[15:49:57] <cradek> adding complexity should only be done for a reason
[15:50:06] <cradek> I don't know the rule for adding optional complexity
[15:52:37] <cradek> I hate to just always argue for what it already does - that kind of developer is irritating
[15:54:09] <jmkasunich> the actual change would entail:
[15:54:33] <jmkasunich> 1) an if to choose between maxvel and finalvel (easiest and safest part)
[15:54:47] <jmkasunich> 2) inifile cut-n-paste code to read finalvel
[15:55:02] <jmkasunich> 3) docs text to describe finalvel
[15:55:18] <jmkasunich> 4) homing diagram change to change "maxvel" to "finalvel"
[15:55:27] <jmkasunich> item 4 is probably the most annoying
[15:56:59] <cradek> yeah, ick
[15:57:03] <jmkasunich> actually, that drawing should be updated anyway, to include index-only homing
[15:57:14] <cradek> ah, true
[15:57:52] <jmkasunich> it doesn't look like index only is documented at all
[15:57:59] <cradek> it is in the text
[15:58:08] <cradek> iirc
[15:58:34] <jmkasunich> ah, one sentence near the end of the latch_vel paragraph
[16:08:55] <skunkworks259> actually - on the old k&t we never used g0.. It sounded like it was falling apart. (150ipm)
[16:10:06] <skunkworks259> I think 50ipm was about the fastest we ever ran the thing - for the most part.
[16:10:10] <cradek> what do you think was wrong (or did it just sound that way?)
[16:10:32] <cradek> I can't believe you actually used that thing in this century :-)
[16:12:52] <skunkworks259> the main thing I think was the z axis had a bit of backlash as it was coupled all the way down to the x axis hydralic servo.
[16:13:29] <skunkworks259> (x and z shared the same servo)
[16:14:47] <cradek> wonder if you or I will get our machines converted first
[16:14:54] <skunkworks259> heh
[16:15:03] <jmkasunich> I beat you both!
[16:15:04] <skunkworks259> I have been way too busy.
[16:15:11] <skunkworks259> jmkasunich: you suck ;)
[16:15:13] <jmkasunich> (which still amazes me)
[16:15:19] <cradek> you had years of head start
[16:15:45] <jmkasunich> I'm far from "done" anyway
[16:16:03] <jmkasunich> I hope to do ballscrews some day, and I want to replace the spindle motors, and, and, and,....
[16:16:41] <skunkworks259> cradek: when are we going to see some more 5 axis videos?
[16:17:39] <cradek> one of these days...
[16:17:45] <skunkworks259> heh :)
[16:18:04] <skunkworks259> are you actually working on joint limits?
[16:18:19] <skunkworks259> (or whatever you call it)
[16:18:26] <cradek> joint constraints
[16:18:31] <cradek> I need them...
[16:18:32] <skunkworks259> right
[16:18:38] <cradek> I've been trying to think up a good way.
[16:19:15] <cradek> I can't tell if it's a hard problem or I'm procrastinating
[16:19:18] <cradek> maybe it's both
[16:20:23] <jepler> I think it's a hard problem
[16:20:48] <skunkworks259> yeck
[16:22:12] <skunkworks259> why - if you have each individuals axis setup with its max acc and vel - That isn't enough?
[16:22:35] <cradek> no because several axes might cause a joint to move, and those add up
[16:22:53] <cradek> or, a small axis move might cause a large joint move
[16:23:19] <skunkworks259> * skunkworks259 still doesn't get it - but that is ok.
[16:23:26] <cradek> on my little mill, you know how when B turns, the table has to slide sideways? this keeps the workpiece under the tooltip
[16:23:42] <cradek> now imagine I put in a 1-mile long end mill
[16:23:54] <cradek> the same B rotation speed causes a huge motion at the table
[16:24:13] <skunkworks259> right.. so the individual axis constraints are ignored?
[16:24:15] <cradek> so, the table (joint constraint) has to slow down B a lot
[16:24:24] <cradek> no, only B (an axis) is moving
[16:24:31] <cradek> it moves two joints, one rotary, one linear
[16:26:09] <cradek> a C axis motion moves three joints: the table, saddle, and horizontal rotary
[16:27:02] <cradek> imagine the tool tip is over X=1mile on the workpiece, and I move the C axis at its normal speed. Both the table and saddle joints have to move very fast
[16:27:33] <cradek> * cradek waves his hands
[16:27:45] <skunkworks259> right. I see that. but I guess I am assuming that the ini file individule constraints would take effect..
[16:27:59] <cradek> there are no constraints on joints, only axes
[16:28:34] <cradek> on the machines we're used to, you can interchange them, which is why emc works today
[16:28:43] <skunkworks259> right - so the saddle and table would only go as fast as the ini constrains and c would move very slow.
[16:28:58] <jmkasunich> thats what it _should_ do
[16:29:00] <cradek> yes if we had joint constraints
[16:29:02] <skunkworks259> is what I was thinking..
[16:29:11] <skunkworks259> ah.
[16:29:24] <jmkasunich> but the code to calculate exactly how fast C can move when the real limit are table and saddle, doesn't exist yet
[16:29:29] <jmkasunich> and is non-trivial
[16:29:49] <skunkworks259> that sucks. :)
[16:33:06] <skunkworks259> I think I had asked a related question before.. On a robot arm - you could have on joint accelerating in one direction and a lower joint acceleraating in a different direction. The sum of the two might be too much for the lower joint..
[16:33:21] <jmkasunich> right
[16:34:02] <jmkasunich> today limits are calculated and applied in user space, and I think that simply isn't possible for non-trivlins
[16:34:04] <jmkasunich> kins
[16:34:11] <jmkasunich> because user space has no clue at all about the kins
[16:36:25] <jmkasunich> so either we have to figure out how to make kins more globally visible, or we have to figure out how to apply constraints at the motion controller level
[16:36:44] <jmkasunich> the latter is probably easier
[16:36:47] <skunkworks259> I think cradek is working on that.. ;)
[16:37:15] <jmkasunich> the former is more powerfull, since that could lead to things like the interp understanding non-rectangular workspace limits and such
[16:37:48] <skunkworks259> again - things are going a bit over my head.
[16:37:59] <skunkworks259> again - that is ok.
[16:38:07] <jmkasunich> think about a scara robot
[16:38:51] <jmkasunich> a trivkins machine can put the tooltip anywhere in a rectangular block, easily defined by min and max X, Y, and Z coords
[16:39:13] <jmkasunich> a scara can put the tooltip anywhere in a complex rounded volume
[16:39:25] <skunkworks259> ah - and a scara has a more circular... rigt
[16:39:27] <skunkworks259> right
[16:39:59] <jmkasunich> emc has no way to tell you if a program is outside the workspace of a non-trivkins machine, until you actually run the program
[16:40:26] <skunkworks259> that does sound like a lot of work.
[16:40:32] <skunkworks259> (to make it all work)
[16:56:13] <cradek> jmkasunich: imagine moving across a polar machine. a straight move starts out mostly in R, goes to mostly theta near the center, then back to mostly R. I don't see any way to calculate that ahead of time and rewrite the constraints into cartesian space
[16:57:07] <cradek> hmm, but you could rewrite it with one velocity along the move
[16:57:27] <cradek> I was imagining the controlled point velocity would change throughout the move as the joint constraints require
[16:57:42] <cradek> there are two very different approaches, I hadn't noticed that :-)
[17:01:30] <jmkasunich> if the geometry and kins were known in user space, it is possible to split that long straight move into many segments, and calculate the limiting factor for each segment
[17:01:40] <jmkasunich> some would be R limited, some would be theta limited
[17:01:50] <jmkasunich> (not saying thats the right way to do it, just a way)
[17:02:01] <jmkasunich> that segmentation is artificial
[17:02:13] <jmkasunich> the motion controller segments every move anyway, into 1mS segments
[17:02:17] <cradek> my scheme 1 gives segmentation at the servo cycle
[17:02:18] <cradek> right
[17:02:29] <jmkasunich> it seems more natural to apply vel and accel limits there
[17:02:41] <jmkasunich> although, lookahead raises its ugly head
[17:03:16] <cradek> yes you can blindly fly toward a singularity and then not be able to slow down enough (accel constraint)
[17:03:21] <jmkasunich> you could concievably run into accel limts
[17:03:23] <jmkasunich> right
[17:03:31] <cradek> but, that's a somewhat bogus machine configuration
[17:03:40] <cradek> (with a singularity in the middle of travel)
[17:03:56] <jmkasunich> thats what stepgen maxacell and following error detection is for ;-)
[17:04:24] <cradek> it's important to remember that if there is no perfect solution, a good enough solution is good enough
[17:04:54] <cradek> but, all this is why I haven't coded anything yet
[17:05:16] <jmkasunich> yeah, I think picking the right method has got to be the first step
[17:05:38] <jmkasunich> and I'm afraid it will also be something that happens servo period by servo period
[17:05:55] <cradek> yes I think so too
[17:06:33] <cradek> that's not necessarily the hardest solution just because it runs the most often...
[17:07:02] <cradek> I think finding the closed form solution for cartesian space (in userland) would surely be harder
[17:07:06] <jepler> surely you can hit the accel constraint trying to slow down even if you don't actually move through a singularity
[17:07:15] <jmkasunich> a naive but maybe practical approach might be to simply calculate where you want to be (in joint space) 1mS from now using the current cartesean velocity, then calculate the joint velocities
[17:07:17] <cradek> jepler: yes probably
[17:07:39] <cradek> jmkasunich: right that's what I was thinking too.
[17:07:47] <jmkasunich> if any of them exceed a joint limit, decrease the cartesean velocity by that ratio
[17:07:58] <cradek> "oh heck, can't get there, but I see I can get .3 of the way there"
[17:08:02] <jmkasunich> right
[17:08:14] <cradek> it's just discrete derivatives
[17:08:21] <jmkasunich> yep
[17:08:42] <jmkasunich> the original NIST kins had additional functions that would calculate the actual derivatives
[17:08:44] <cradek> it's nice to see that we independently came to a similar approach
[17:09:05] <jmkasunich> but I think doing that would make the job of a kins module writer harder
[17:09:12] <jmkasunich> much harder in some cases
[17:09:25] <cradek> I thought so too, I don't see how that works, considering the derivatives can be different when you go in different directions
[17:09:40] <jmkasunich> you have to do the calculus
[17:09:55] <cradek> explain please
[17:10:14] <jmkasunich> suppose you are doing XY to theta
[17:10:33] <jmkasunich> R = sqrt(x^2+y^2)
[17:10:58] <cradek> sure, theta = atan2(y,x)
[17:10:59] <jmkasunich> you can take that and do calculus to get dR/dX
[17:11:21] <jmkasunich> (you can maybe, I've forgotten 95% of the calculus I ever knew)
[17:11:30] <cradek> "one can"
[17:11:33] <jmkasunich> yeah
[17:11:34] <jmkasunich> one
[17:11:50] <jmkasunich> that means that kins writers would have to be "the one"
[17:11:55] <jmkasunich> and I don't want to do that
[17:12:24] <jmkasunich> I think discrete derivatives is "good enough" and has benefits in simplifying the kins modules
[17:13:44] <cradek> would this look like: Polar d1kins(double dr, double dtheta)
[17:14:00] <cradek> I still don't quite see how you would use it
[17:14:21] <cradek> how do you know dr, dtheta unless you do the position kins first?
[17:14:59] <jmkasunich> you did position kins for the current position last time, you do delta kins for that position this time, to determine how far you can move
[17:15:01] <cradek> if there's a right solution, we should do that, even if it makes kins more complex -- a kins writer could approximate the deriv functions discretely if he wants
[17:15:15] <cradek> (not discreetly, haha)
[17:15:28] <jmkasunich> I disagree
[17:15:44] <jmkasunich> this stuff will be done once, and kins will be done many times by many people
[17:16:24] <cradek> I will try to understand the right approach before I decide whether to pick the not-quite-so-right approach
[17:16:41] <jmkasunich> (neither solution is "right" in that neither deals with lookahead, so either one can run into accel contstraints
[17:16:42] <cradek> the discrete derivs would be boilerplate that the writer could replace if he wants
[17:16:55] <cradek> (I think)
[17:17:00] <jmkasunich> I still disagree
[17:17:21] <jmkasunich> discrete derivs work reasonably well if and only if you pick a reasonable delta
[17:17:32] <jmkasunich> the kins writer doesn't know a reasonable delta
[17:17:46] <cradek> but the servo cycle gives us one?
[17:17:56] <jmkasunich> but the TP does - the distance it would travel if it kept going in the same direction at the same speed as it is now
[17:18:04] <cradek> I see
[17:18:06] <jmkasunich> (kins doesn't know how fast you are moving)
[17:18:42] <cradek> so motion will have to keep track of the previous two positions to calc these discrete derivs
[17:18:58] <jmkasunich> I don't think so
[17:19:05] <jmkasunich> it knows where it is
[17:19:18] <cradek> yes that's the first one
[17:19:21] <jmkasunich> and it knows where it would be if it kept going at the same speed
[17:19:28] <cradek> it has to know the old velocity to get accel
[17:19:38] <jmkasunich> hmm
[17:19:48] <cradek> you forget it could be accelerating (in cartesian space)
[17:20:27] <cradek> this is very useful compared to my internal stewing, thanks
[17:20:32] <jmkasunich> yeah, I guess it needs either two sets of old positions, or one set of old positions and one set of old velocities
[17:20:58] <jmkasunich> I was thinking of the latter
[17:21:01] <cradek> well you're right that the old position is "here"
[17:21:09] <cradek> the new position is what TP gives you
[17:21:26] <jmkasunich> old vels would be "how you got here"
[17:21:27] <cradek> you only additionally need the previous position delta I think
[17:21:39] <jmkasunich> and new vels would be "how you have to get there"
[17:22:10] <cradek> (I hope you can help with this - I don't seem to be getting it done myself)
[17:22:23] <jmkasunich> I can try
[17:22:31] <jmkasunich> certainly I can help with the discussions
[17:22:56] <jmkasunich> I don't know about the TP though
[17:23:00] <cradek> even in trivkins joint constraints are useful. we could remove most of the cartesian stuff.
[17:23:10] <jmkasunich> yep
[17:23:14] <cradek> (the cartesian assumptions)
[17:23:21] <cradek> then, rotatekins can work right
[17:24:09] <jmkasunich> I can never keep things straight - is "forward kins" the one that goes from cartesean to joints, or is that reverse kins?
[17:24:10] <cradek> you could actually do a virtual C axis like we've talked about before
[17:24:19] <cradek> inverse is cartesian to joints
[17:24:35] <jmkasunich> so you always need inverse
[17:24:37] <cradek> you can get by with only inverse (that's what max5 has so far)
[17:24:40] <cradek> right
[17:24:55] <jmkasunich> seems backwards, but who am I to change conventions
[17:25:29] <jmkasunich> I think we have a handle on the basic approach
[17:25:31] <cradek> sssshhh skunkworks is back
[17:25:50] <cradek> yeah, now it's SMOP
[17:25:58] <jmkasunich> well, not so simple
[17:26:02] <skunkworks259> heh - I noticed I dropped out - so I read the log. Cool conversation.
[17:26:09] <jmkasunich> right now the TP is blissfully unaware of kins
[17:26:35] <cradek> yep
[17:26:55] <jmkasunich> I'm beginning to wonder if I made a mistake when I stopped using the TP for jogs
[17:27:00] <cradek> even unaware of what cartesian is
[17:27:15] <jmkasunich> huh? the TP _is_ cartesean
[17:27:18] <cradek> yeah we're going to have to figure that out
[17:27:31] <cradek> yes but it doesn't care
[17:27:47] <jmkasunich> well, its got some hardcoded assumptions in it that are cartesean
[17:27:56] <cradek> it interpolates along a path at some rate
[17:28:06] <jmkasunich> like V = sqrt(vx^2+vy^2+vz^2)
[17:28:22] <cradek> I think all the cartesian assumptions are before TP
[17:28:27] <jmkasunich> oh
[17:28:33] <cradek> in userland even
[17:28:39] <jmkasunich> what about circles?
[17:28:40] <cradek> (I could be forgetting something)
[17:28:54] <cradek> sorry what about them?
[17:29:11] <cradek> same thing I think: it interpolates along the path at some rate
[17:29:21] <jmkasunich> the definition of an arc path assumes cartesean coords doesn't it?
[17:29:43] <cradek> I was probably not clear, let me try again
[17:30:26] <cradek> the TP doesn't change anything about vel/acc if the path is in 1,0 or 1,1 even though those have different acceptable vel/acc
[17:30:36] <jmkasunich> ok
[17:30:49] <cradek> all those assumptions about what 1,1 motion means (it moves two joints at sqrt(2) each) are before the tp
[17:31:31] <cradek> I don't remember why we're talking about this now
[17:31:40] <jmkasunich> for lines I can agree - it simply does linear interpolation between x1 and x2, y1 and y2, a1 and a2, v1 and v2, etc
[17:31:42] <cradek> ah "the TP is unaware of kins" - true
[17:32:18] <jmkasunich> for arcs though, the interpolation isn't linear, and there is definitely some cartesean reference system in which the path is a circl
[17:32:46] <cradek> for circles it's the same - it just does circular interpolation along the path at the given v,a
[17:33:01] <cradek> v,a are along the circular path
[17:33:18] <cradek> userland figured out what those should be
[17:33:37] <jmkasunich> ok - we digressed when you said TP isn't cartesean, and I guess that doesn't really matter
[17:33:45] <cradek> ok
[17:34:02] <jmkasunich> TP _is_ dealing (always) with XYZABCUVW, correct?
[17:34:18] <cradek> yes
[17:34:57] <jmkasunich> and inverse kins is a function that given XYZABCUVW, returns saddle/table/head/rotary1/rotary2, or some other set of numbers
[17:35:14] <cradek> yes
[17:35:52] <jmkasunich> today, TP runs, productes a X..W set, and hands it to the main part of motion
[17:35:59] <jmkasunich> motion calls kins to get the joint stuff
[17:36:15] <jmkasunich> that won't work anymore
[17:36:44] <skunkworks259> so - the tp is limited to the ini constraints - then get sent thru kins which there are no constraints? (I might be getting it)
[17:37:19] <cradek> yes kins is the axis<->joint translation. all constraints are on the axis side so far
[17:37:24] <jmkasunich> seems like TP has to produce a "tentative" X...W set, run kins, validate that the results don't violate joint constraints, and if needed generate a new final X...W set
[17:37:52] <cradek> yes
[17:38:19] <cradek> I guess TP will have a new interface that motion can call to give that tentative info
[17:38:37] <jmkasunich> we definitely need to rethink teleop too
[17:38:38] <cradek> it will not actually update the machine position (tpGetPos or whatever it is)
[17:39:04] <cradek> yeah we don't have incremental or jogwheel in teleop. it would be best if we could have both.
[17:39:14] <jmkasunich> yep
[17:39:37] <cradek> (jogwheel is going to be another hard problem)
[17:39:49] <jmkasunich> to be honest, I think the first major step (boring, but needed) is to finish splitting out joint vs. axis
[17:40:02] <jmkasunich> hal pin names should be joint.N.motor-pos-cmd, etc
[17:40:03] <cradek> I don't know what that means
[17:40:23] <cradek> oh you just mean renaming things?
[17:40:23] <jmkasunich> and we'll also want hal pins that have the cartesean stuff - axis.N.pos
[17:40:41] <jmkasunich> some of it is just renaming
[17:40:55] <cradek> are you sure hal should have axis info?
[17:41:03] <jmkasunich> but I bet as we do that we'll find places where we've made trivkins based assumptions
[17:41:09] <jmkasunich> yes, if only to allow you to halscope it
[17:42:14] <jmkasunich> it will be alot easier to debug kins and such if you can see the inputs and outputs
[17:42:17] <cradek> ((this is going to be major breakage isn't it))
[17:42:39] <jmkasunich> waffle
[17:42:46] <cradek> no kidding
[17:43:11] <jmkasunich> definitely will involve config changes, because of naming
[17:43:21] <jmkasunich> but that has been inevitable
[17:43:45] <cradek> sure, that's no problem.
[17:43:46] <jmkasunich> and I think we accepted that we were gonna have to do it for proper kins support
[17:44:09] <jmkasunich> the first round will pick up the configs changes without major breakage (I hope)
[17:44:26] <skunkworks259> you guys are awsome.
[17:44:30] <skunkworks259> awesome
[17:44:30] <jmkasunich> when we start fixing teleop, well, teleop is already broken, so who cares?
[17:45:03] <jmkasunich> if jogging and/or jogwheels switches to using the TP, well, that might be painful
[17:45:15] <jmkasunich> although joint jogging probably won't change, will it?
[17:45:27] <jmkasunich> hmm
[17:45:39] <jmkasunich> right now there is a emcmot command called JOG_INCR
[17:45:46] <cradek> I don't see any other way to jog joints than what we have
[17:45:59] <jmkasunich> I guess that one command's actions would change depending on whether you are in joint or world mode
[17:46:12] <cradek> we may not need incremental joint jog. what meaning does it really have?
[17:46:24] <jmkasunich> (I'd almost rather have two commands, JOG_INCR_CARTESEAN and JOG_INCR_JOINT
[17:46:47] <jmkasunich> dunno, but there are also JOG_ABS and JOG_CONT, the same issues apply to them
[17:47:28] <jmkasunich> another BIG thing that I want to do for non-triv machine (joint mode in general really)
[17:47:34] <jmkasunich> I want user specified joint names
[17:47:38] <jmkasunich> not 01234
[17:48:21] <jmkasunich> in the ini, I want [JOINT_0]NAME = saddle [JOINT_1]NAME = table [JOINT_2]NAME = quill
[17:48:24] <cradek> that sounds tedious more than hard
[17:48:35] <jmkasunich> or shoulder, elbow, wrist, or whatever
[17:48:39] <jepler> that reminds me of my newest terrible idea: "halcmd rename". 'halcmd rename ddt.0 dxdt' would rename all HAL items beginning with ddt.0 to dxdt, so that afterwords you'd have dxdt.in, dxdt.out (parameters) and the function dxdt.
[17:48:52] <jmkasunich> ick
[17:49:05] <jmkasunich> how about alias instead?
[17:49:20] <cradek> jepler: maybe you're just hungry.
[17:49:36] <jmkasunich> (don't destroy the original names, just add aliases)
[17:49:40] <cradek> tangent tangent
[17:49:40] <jepler> that's harder, I think
[17:49:51] <jepler> sorry, I tangented
[17:49:51] <jmkasunich> anyway, we digress
[17:49:51] <cradek> sorry, that's rude
[17:49:55] <roltek_> why would you want to rename them
[17:50:17] <jmkasunich> ease of tinkering
[17:50:21] <cradek> because which one is joint 4?
[17:50:34] <roltek_> depending on what kind of machine they will change
[17:50:36] <cradek> oh it's "nod"
[17:50:39] <cradek> yes that's the point
[17:50:41] <rayh> Just wants to write obscene versions of common .hal files.
[17:50:57] <cradek> bbl, lunch
[17:51:18] <jmkasunich> one problem with my joint names issue is for the GUI
[17:51:37] <jmkasunich> when in joint mode, I'd like the coordinates to be displayed with the proper names
[17:51:44] <jmkasunich> but most guis allow one character only
[17:53:20] <roltek_> why not x,y,z,a
[17:53:34] <jmkasunich> those aren't joints, they are cartesean axes
[17:53:47] <jmkasunich> if you are running a robot, the joints are elbow, wrist, shoulder, etc
[17:54:13] <jmkasunich> trivial kinematics machine have made us sloppy, because we use the same names for things that are NOT always the same
[17:54:21] <jmkasunich> table and saddle are NOT the same as X and Y
[17:54:39] <jmkasunich> for example, suppose you have a motor on both quill and knee - which one is Z?
[17:55:14] <jmkasunich> thats what kinematics is all about - defining the connections between XYZABCUVW and actual moving parts of the machine
[17:55:27] <roltek_> kearney's did it z and z prime
[17:55:31] <jmkasunich> so I want to use the names of actual moving parts of the machine
[17:55:54] <jmkasunich> if the names are defined in the inifile, you can make it like a kearney if you want
[17:56:01] <jmkasunich> z' doesn't work for a scara robot
[17:56:08] <roltek_> true
[17:56:24] <jmkasunich> * jmkasunich gets food
[19:08:36] <skunkworks259> complain complain complain
[19:08:47] <jepler> skunkworks259: yeah you're a real whiner
[19:08:48] <jepler> er, what?
[19:08:56] <skunkworks259> ;)
[19:11:06] <skunkworks259> wait - I don't complain too much - do I?
[19:11:14] <CIA-20> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/components/timedelay.c: change 'on_delay' to 'on-delay', etc, to be consistent with HAL naming conventions
[19:14:10] <CIA-20> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/components/timedelay.c: fix comments - seconds, not milliseconds
[19:17:05] <jepler> finally got around to confirming that the position jump doesn't exist when I turn off the screw compensation file for that axis
[19:17:58] <jmkasunich> I'll have to look into that - I thought the screw comp was filtered thru an accel and vel limit, but maybe not
[19:18:37] <cradek> if it is filtered like that, won't you leave the path?
[19:18:55] <jmkasunich> what path?
[19:19:02] <cradek> the desired trajectory
[19:19:23] <jmkasunich> during normal moves, comp is changing _very_ slowly
[19:19:33] <jepler> except at reversals
[19:19:57] <jmkasunich> during reversals, its just like backlash comp - you want to obey limits, not stall the motor
[19:20:08] <cradek> I see
[19:20:59] <jmkasunich> hmm, according to the code, comp does go thru accel and vel limit
[19:21:52] <cradek> maybe it's just homing/index?
[19:22:33] <jmkasunich> control.c approx line 2320 calcs screw comp - thats one branch of an if, the other branch (2340) uses 1/2 the backlash value instead, then 2351 - 2467 applys the limits
[19:22:37] <jmkasunich> that code runs all the time
[19:22:48] <jmkasunich> index is another matter - that does cause jumps
[19:22:59] <jmkasunich> but I don
[19:23:09] <jmkasunich> don't think jepler is using index
[19:23:12] <jepler> I don't think I'm using home-to-index ..
[19:23:17] <cradek> oh sorry
[19:23:22] <cradek> * cradek <- slow
[19:23:55] <jepler> jmkasunich: do you think that the function name for timedelta should also be changed? It's currently "process_delays".
[19:24:08] <jmkasunich> I don't even know what timedelta does
[19:24:11] <jepler> er
[19:24:15] <jepler> I meant timedelay
[19:25:02] <jmkasunich> you mean change _ to - ?
[19:25:35] <jepler> or call it 'timedelta' like the component
[19:26:21] <jmkasunich> oh, I didn't realise it was ONLY "process_delays"
[19:26:41] <jmkasunich> I was thinking "timedelay.process_delays", like "stepgen.make_pulses"
[19:26:47] <jepler> that's how I read the source; I didn't actually run it
[19:26:56] <jepler> retval = hal_export_funct("process_delays", process_delays, delay_array, 1, 0, comp_id);
[19:27:02] <jmkasunich> yep, looking now
[19:27:28] <jmkasunich> I don't think it automatically prepends the component name
[19:27:56] <jmkasunich> this is also one of those modules that deviates from convention by having one function that updates all the delays
[19:28:19] <jmkasunich> icky
[19:28:34] <jmkasunich> should rewrite it as a comp - we'd get a manpage, and it would be more consistent
[19:28:46] <jepler> I'm working on the manpage now, but I could change horses midstream..
[19:29:08] <jmkasunich> I was hoping to shame maddash into doing the manpage
[19:29:35] <jmkasunich> but somehow I doubt he'd do it
[19:30:04] <jmkasunich> this is one of those "is there justification for changing it" things
[19:31:45] <jepler> you already made one incompatible change for any users of this component .. might as well make two at once.
[19:31:55] <jmkasunich> true
[19:32:03] <jmkasunich> make it right, so we don't change it again
[19:32:37] <jmkasunich> loadrt timedelay count=n, function name "timedelay.n", etc, all that comes pretty much free with comp, right?
[19:33:46] <jepler> I doubt that having multiple functions is useful in this case..
[19:33:55] <jepler> * jepler waffles about what to do
[19:34:17] <jmkasunich> thats why standards are so nice
[19:34:29] <jmkasunich> if everything has one function per instance, you don't have anything to waffle over
[19:35:50] <jmkasunich> I still have dreams of someday figuring out what order to run functions automatically based on inputs and outputs and what feeds what
[19:35:58] <jmkasunich> one function per instance will make that simpler
[19:43:13] <jepler> OK, so what's the documentation for the 'elapsed' parameter? Or should I simply drop it?
[19:43:27] <jepler> I am having trouble putting it into words
[19:44:20] <jmkasunich> I think its more of a debug param
[19:44:29] <jepler> OK
[19:45:00] <jmkasunich> "current value of the timer (mostly for debug)" would be a suitable description I think
[19:53:26] <jepler> hmph. not a very useful error message.
[19:53:27] <jepler> hal/components/timedelay.comp|37| error: invalid storage class for function 'get_data_size'
[19:53:53] <jepler> (actual error: missing close brace in the 'function _')
[19:53:59] <jmkasunich> heh
[20:01:56] <jepler> http://emergent.unpy.net/files/sandbox/timedelay.9.html (from the .comp I have been writing .. haven't tested it yet)
[20:02:46] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: add author declaration
[20:03:24] <jmkasunich> "based _on_ works"
[20:03:34] <jepler> thanks
[20:03:38] <jmkasunich> looks good to me
[20:03:39] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/comp.lyx: document the author declaration
[20:12:54] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/comp.lyx: typo
[20:20:37] <jepler> yech, the pins in 'timedelay' are prefixed 'delay', not 'timedelay'.
[20:22:54] <jmkasunich> oops
[20:23:27] <jmkasunich> why'd that happen?
[20:25:11] <jepler> in the .c, I mean
[20:25:35] <jmkasunich> oh
[20:25:50] <jmkasunich> yet another incompatibility that will be going away with the comp version
[20:26:25] <jmkasunich> that's what you are doing, right?
[20:26:32] <jepler> yes
[20:26:38] <jmkasunich> cool
[20:26:41] <jepler> actually right now I'm trying to write a test for the existing one
[20:33:48] <jepler> hm, what am I doing wrong here? I'm trying to get a 2Hz pwmgen with a 50% duty cycle but I'm not getting the duty cycle I wanted.
http://emergent.unpy.net/files/sandbox/pwmgen-output.png (gnuplot of halsampler capture)
[20:33:56] <jepler> setp pwmgen.0.pwm-freq 2
[20:33:56] <jepler> setp pwmgen.0.value 0.5
[20:33:56] <jepler> setp pwmgen.0.scale 1
[20:33:56] <jepler> setp pwmgen.0.enable 1
[20:34:33] <jepler> oh, maybe I don't want type=0, or else I want value 0.0 (mid scale)
[20:36:03] <jmkasunich> hmm, what you wrote seems reasonable
[20:36:05] <jepler> no that's not it
[20:36:17] <jmkasunich> I doubt its been tested at two Hz
[20:36:31] <jmkasunich> try changing the frequency (only) to say 20 Hz and see if it gets better
[20:36:39] <jmkasunich> something might be overflowing
[20:43:55] <jepler> setp pwmgen.0.pwm-freq 20
[20:43:58] <jepler> now I get only '0'
[20:44:50] <jmkasunich> hmm
[20:45:05] <jmkasunich> what frequency is sampler running at?
[20:45:18] <jmkasunich> servo or base?
[20:45:25] <skunkworks259> umm - isn't the pwm-freq in 1/hz?
[20:45:41] <jmkasunich> I'm pretty sure its Hz
[20:45:44] <skunkworks259> ok
[20:45:50] <jepler> the manpage says ..
[20:45:50] <jepler> pwmgen.N.pwm-freq float rw
[20:45:51] <jepler> PWM frequency in Hz.
[20:45:58] <skunkworks259> ok
[20:46:04] <jepler> only one thread: loadrt threads name1=thread period1=7812500
[20:46:14] <jepler> (that should be 1/128 second unless I screwed something up)
[20:46:17] <jmkasunich> 7mS thread?
[20:46:52] <jmkasunich> I bet something is over or underflowing
[20:46:57] <jmkasunich> I'll take a look in a bit
[20:47:05] <jepler> I am sure my case is .. a bit pathological
[20:47:22] <jepler> I will skip using pwmgen for this, because it's not the component I really wanted to test
[20:47:48] <jepler> bbl
[20:50:46] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/tests/timedelay.0/ (result test.hal): test of timedelay component
[21:09:24] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/tests/timedelay.0/ (expected result): whoops, 'result' should have been 'expected'
[21:09:55] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/tests/timedelay.0/expected: whoops again -- correcte expected results
[21:33:00] <jepler> boy I'm really disturbed by how I have to write this .comp to match the results from the old timedelay.c
[21:33:06] <jepler> old: if (*(thisdelay->in) == 0) {
[21:33:12] <jepler> new: if(timer > on_delay) {
[21:33:22] <jepler> errrr
[21:33:29] <jepler> I meant to paste this line:
[21:33:29] <jepler> if (thisdelay->timer >= thisdelay->off_delay) {
[21:33:37] <jepler> the old uses >=, the new uses > to get the same result
[21:40:14] <jepler> ah, I see
[21:40:20] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/tests/timedelay.0/test.hal: making the -delays a half-period bigger (e.g., 4.5N) makes the test more immune to slightly different rounding because N+N+N+N is clearly below it and N+N+N+N+N is clearly above it
[21:40:37] <jepler> seems that the slightly different way that the period was converted to float mattered..
[21:49:57] <jepler> huh, weird behavior from 'cvs up dirname/' (look how the output from the two commands differs):
http://pastebin.ca/840449
[21:50:53] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/src/hal/components/ (timedelay.comp timedelay.c): replace timedelay with a .comp version, so that we get uniform naming and automatic documentation
[21:50:54] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/tests/timedelay.0/test.hal: replace timedelay with a .comp version, so that we get uniform naming and automatic documentation
[21:53:45] <CIA-20> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) non-realtime (2.6.12-10-386) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot1_log.txt
[21:55:45] <jepler> jmkasunich: looks like you'll need to force a clean rebuild ?
[21:56:12] <jepler> make: *** No rule to make target `hal/components/timedelay.c', needed by `depends/rthal/components/timedelay.d'. Stop.
[21:56:19] <jepler> or maybe I'm missing a part of the commit .. hold on
[21:57:26] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/src/Makefile: finish removing old timedelay.c module
[21:59:49] <CIA-20> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) non-realtime (2.6.12-10-386) * 10emc2head/: build PASSED
[21:59:57] <jepler> yay
[22:00:42] <jmkasunich> was making measurements, sorry
[22:00:47] <jmkasunich> looks like you solved it anyway
[22:01:08] <jepler> I was too clever by half when it came to choosing the numbers in my test program
[22:02:26] <jepler> but now I've been half again as clever (is that a total of 2.25 clevers, or just 2.0?), my test program passes
[22:03:42] <jmkasunich> I have numbers squirting out my ears
[22:04:12] <jmkasunich> measured screw error at 121 places, going both directions, to get the periodic error on this screw
[22:04:45] <jmkasunich> plus 22 places going both directions (which I want to repeat at least once more) to get the non-periodic error
[22:05:08] <jepler> sounds like a blast
[22:05:38] <jmkasunich> I have about a 0.001 sinewave, once per rev of the screw
[22:05:48] <SWPadnos> that seems pretty reasonable
[22:05:52] <jmkasunich> less in one direction than the other, maybe 0.0007 the other way
[22:06:13] <jmkasunich> another thou or so of non-periodic error, and about 7 thou of backlash
[22:06:27] <SWPadnos> hmmm. that's a less reasonable stack-up
[22:06:31] <jmkasunich> yeah
[22:06:48] <jmkasunich> I'm gonna look into how we do comp - and what the real limits on number of points are
[22:07:17] <SWPadnos> my recollection is that there's a fixed-size array or something like that
[22:07:19] <jmkasunich> there are 110 turns of the screw from end to end, so with the existing 256 (I think) point limit, I can only do 2 points per turn
[22:07:30] <SWPadnos> but I may be totally wrong about that by now :)
[22:07:41] <jmkasunich> I think you are (partly) right
[22:08:08] <jmkasunich> its a 256 element array, of which you can use as little as you wish - so you could have a three point curve, or a 255 point one,but not a 500 point one
[22:08:38] <SWPadnos> sure
[22:08:39] <jmkasunich> I'd like about 440 points, so I can do four per screw rev
[22:08:55] <SWPadnos> or add a periodic correction as a separate factor
[22:09:05] <jmkasunich> I've been thinking about that
[22:09:24] <SWPadnos> not so wasy to get right, unless you have accurate mechanical homing
[22:09:29] <jmkasunich> more elegant, but a bigger task to do and to document
[22:09:30] <SWPadnos> s/wasy/easy/
[22:09:37] <SWPadnos> yep
[22:09:49] <jepler> because if you're off by a small fraction of a rotation, the whole periodic correction does more harm than good?
[22:09:52] <jmkasunich> my home switch repeatability is about 0.001 or better, and a screw turn is 0.100, so thats only 1%
[22:09:56] <SWPadnos> yes
[22:10:25] <jmkasunich> even being off by 10x that would still not be "more harm than good"
[22:10:47] <SWPadnos> no, you'd jusy have a vector sum of errors
[22:10:49] <SWPadnos> gah
[22:10:50] <SWPadnos> just
[22:10:58] <SWPadnos> the actual error plus the offset correction
[22:11:12] <jmkasunich> right
[22:12:24] <jmkasunich> I think I'm gonna re-take the very first set of periodic points - they look different than all the others, suspiciously so
[22:12:32] <jmkasunich> whats another 22 numbers
[22:12:40] <SWPadnos> nothing, of course
[22:12:47] <SWPadnos> it's for the greater good, after all
[22:12:51] <jmkasunich> heh
[22:13:23] <jmkasunich> this is the cross-slide in lathe mode, so 0.0001 error is twice that in diameter
[22:13:29] <jmkasunich> matters if I'm doing a critical fit
[22:19:40] <alex_joni> greetings & best wishes from 2008 :P
[22:19:46] <jepler> hi alex_joni and thank you
[22:19:50] <cradek> for anything critical I get close (.002) and then touch-off with the micrometer measurement
[22:20:17] <jepler> like in so many things, the US is behind. but we'll catch up in the next 24 hours or so, I think.
[22:20:38] <alex_joni> :P I'm sure you will
[22:23:16] <cradek> then I leave that setting - I generally have a tiny G54 offset (not enough to bother CSS etc)
[22:24:41] <jepler> is it your lathe "Z" that has a home switch?
[22:24:48] <cradek> no it's X
[22:24:54] <cradek> the important one
[22:25:41] <jmkasunich> right, the important one
[22:25:59] <cradek> really have to have that for CSS
[22:26:10] <jmkasunich> I'll definitely be touching off with the mic, because I don't trust the home switch enough for precision work
[22:26:12] <cradek> and you have to use TLO, can't just be lazy and touch off
[22:26:16] <jepler> huh I was sure I remembered the homing going right up against the chuck
[22:26:21] <jepler> or am I remembering the nist-lathe?
[22:26:23] <jmkasunich> I do trust it to keep the comp data matched up to the screw
[22:26:40] <cradek> nist had all six switches I think
[22:26:47] <cradek> mine has only one
[22:27:52] <jepler> hm we don't have very many bugfixes in 2.2 but we do have a few
[22:27:58] <jepler> I wonder if we should do a new release early in 2008
[22:28:04] <jepler> anybody aware of outstanding issues?
[22:28:50] <jepler> oh wait, it's time for me to go home
[22:28:53] <jepler> happy new year, everyone
[22:29:18] <jmkasunich> happy new year (a few hours early, but what the heck)
[22:35:50] <SWPadnos> harpy gnu deer
[22:40:11] <jmkasunich> hmm, each entry in the screw comp table is a double and four floats
[22:40:22] <jmkasunich> 24 bytes
[22:42:34] <cradek> jepler: andy lee's problem is not resolved; I think it's real (and serious)
[22:42:57] <jmkasunich> what problem is that?
[22:43:18] <cradek> some parts of the program (arcs) being skipped
[22:43:30] <jmkasunich> oh
[22:43:33] <cradek> jepler and I have tried but failed to reproduce it
[22:43:47] <jmkasunich> is he mailing you privately? I haven't seen anything in a few days
[22:44:35] <cradek> it's probably my turn - he sent his config to me privately
[22:45:31] <jmkasunich> and even with his exact config you can't replicate it?
[22:46:05] <cradek> nope
[22:46:25] <jmkasunich> I assume it doesn't happen (for him) when running sim?
[22:46:40] <cradek> it only happens to him sometimes, it seems related to what offsets are set
[22:47:00] <cradek> unfortunately it only rarely happens to him
[22:47:13] <jmkasunich> so the next time it does, he should immediately save his var file
[22:47:33] <cradek> I think he did - that is what he sent me.
[22:47:54] <jmkasunich> then that should include his offsets
[22:48:06] <cradek> yes I know :-)
[22:48:12] <jmkasunich> and he should be able to make it happen again and again by loading the same var file
[22:49:09] <jmkasunich> failure of it to repeat when he reuses the same varfile to me is evidence against the "depends on offsets" theory
[22:49:58] <jmkasunich> is this the one where the prevue looks find but the machine (and backplot) ignore the curves?
[22:50:08] <cradek> I admit I have been busy with my projects and haven't spent enough time digging into it.
[22:50:15] <cradek> yes
[22:51:22] <jmkasunich> well, if you can't replicate it, you're gonna have a tough time looking into it
[22:51:51] <jmkasunich> seems like (unfortunately) the burden is on him to come up with a repeatable case
[22:53:39] <jmkasunich> do you think its axis related (and thus were talking to jepler) or could it be anywhere?
[22:54:57] <cradek> no it's in emc
[22:55:20] <cradek> jepler has a way of finding stuff, that's all
[23:59:02] <christel> [Global Notice] From all of us in #freenode-newyears to all of you out there; the best wishes for 2008! Happy GNU^WNew Year, hope it brings you all you wish for..
