Back
[02:25:16] <cradek> hi jmk
[02:25:30] <cradek> are your parts done?
[02:26:34] <jmkasunich> no
[02:26:47] <jmkasunich> had to go to the grocery tonight
[02:26:51] <jmkasunich> just getting started
[02:27:00] <cradek> darn
[02:27:11] <cradek> I just made a pcb for my 4th axis stepper driver
[02:27:14] <jmkasunich> the blocks are done (except for repairing the hole with the broken tap
[02:27:28] <jmkasunich> milled it?
[02:27:38] <cradek> yes
[02:27:44] <cradek> same as the existing 3
[02:27:53] <cradek> I think I even have tre parts to populate it
[02:27:56] <cradek> the
[02:28:10] <jmkasunich> I talked to Matt Shaver today
[02:28:34] <jmkasunich> he's pretty sure he can get the encoder equipped sherline from Fred P and ship it to you
[02:28:50] <cradek> that would be super slick
[02:29:02] <jmkasunich> he'll know in a day or so
[02:29:03] <cradek> will he be going to fest?
[02:29:07] <jmkasunich> yeah
[02:29:15] <jmkasunich> he'd pick it up there and return it to fred
[02:29:41] <cradek> I also ordered that encoder today
[02:30:00] <cradek> and I ran the threading test on my mill (emulated spindle)
[02:30:22] <cradek> there is some oscillation in the tracking, which I think means we have to use PID (I think I have what's equivalent to P only)
[02:30:50] <jmkasunich> oscillation in the output from the motion controller?
[02:31:07] <cradek> hang on a sec, I'll do a plot
[02:32:44] <cradek> http://timeguy.com/cradek-files/emc/ringing.png
[02:33:08] <cradek> it's not bad but I can hear it in the stepper
[02:33:18] <jmkasunich> what are the traces
[02:33:24] <jmkasunich> bottom is spindle pos
[02:33:34] <jmkasunich> 2nd from bottom Z pos?
[02:33:38] <cradek> green is velocity, the red below it is X(Z) pos
[02:33:42] <cradek> yes
[02:33:43] <jmkasunich> top?
[02:33:56] <cradek> top is the 'sync the spindle' output
[02:33:59] <jmkasunich> ok
[02:34:09] <cradek> but you can clearly see the problem in the green
[02:34:13] <jmkasunich> yes
[02:34:33] <jmkasunich> are you applying accel limits to the green?
[02:34:37] <cradek> so I think ... maybe ... I should output to hal the position error at each cycle, and hal can do pid?
[02:34:45] <cradek> yes the green is always within constraints
[02:35:14] <cradek> my mill has pretty high accel
[02:35:41] <jmkasunich> thats why then - the green obeys constraints, but the spindle pos you are matching goes from zero to full speed instantly (when the index arrives)
[02:35:59] <jmkasunich> so as you are accelling in velocity, you are falling behind in position
[02:36:08] <cradek> exactly
[02:36:28] <cradek> but it catches up - you want it to spike over the final target velocity
[02:36:34] <jmkasunich> PID would be a messy wayt to do it
[02:37:07] <jmkasunich> I have no understanding of the code, so what I'm about to propose may be impossible...
[02:37:08] <cradek> I expect the vel spike at the beginning, but I didn't expect the continued ringing
[02:37:14] <jmkasunich> you know your accel limit
[02:37:32] <jmkasunich> you know your spindle speed, and therefore the target axis speed
[02:37:37] <cradek> nothing's impossible, just some things are hard :-)
[02:37:53] <jmkasunich> therefore you can compute the required accel time
[02:38:01] <jmkasunich> and distance
[02:38:10] <cradek> so start early?
[02:38:15] <jmkasunich> yeah
[02:38:33] <jmkasunich> that gets messy tho
[02:38:42] <cradek> well you only sort of know the spindle speed... I don't want to assume it's constant
[02:38:55] <jmkasunich> it is pretty constant
[02:39:10] <jmkasunich> enough to probably reduce the overshoot by an order of magnitude or more
[02:39:21] <cradek> it might dip considerably as soon as you touch the tool to the work
[02:40:26] <cradek> I guess I could sample the spindle speed as I'm waiting for the move to start
[02:40:27] <jmkasunich> by that time you better be velocity matched anyway - what I'm talking about is just to deal with the initial accel
[02:40:37] <cradek> ok I see
[02:40:47] <jmkasunich> actually, another approach might be nicer
[02:41:17] <jmkasunich> I assume even tho the spindle pos is a sawtooth, prior to the beginning of the move you treat it as zero?
[02:41:44] <jmkasunich> zero pos, zero vel, then when the index arrives it accels to actual spindle speed instantly and the axis needs to track that
[02:41:48] <cradek> I only poll it, waiting for it to reset
[02:42:09] <cradek> well there's a goal position, I try to get there, limited by constraints
[02:42:14] <jmkasunich> are you polling the postion, or the index enable bit?
[02:42:30] <cradek> just the position
[02:42:36] <jmkasunich> oh, you still have the inverter in the HAL config, so you can't poll the enable
[02:42:42] <jmkasunich> that should probably change
[02:42:56] <jmkasunich> now that you have a hal pin in the motion controller, index enable should connect direct to it
[02:43:05] <jmkasunich> and it can be bidirectional
[02:43:34] <jmkasunich> read at the beginning of the control code
[02:43:58] <jmkasunich> if true, no index has arrived (and the last time around, you requested a reset on index)
[02:44:31] <jmkasunich> if false, an index has arrived since last time, you can decide whether to request another (set it true again) or not (set/leave it false)
[02:44:53] <cradek> I don't understand what that inverter is doing currently
[02:45:24] <cradek> yes that sounds like a better way of watching for index...
[02:45:33] <jmkasunich> nothing, except ensureing that the pin gets written every servo period (to override the "bidirectional" nature of "index-enable")
[02:46:00] <jmkasunich> for the original demo that NOT was good, now you _want_ the bidirectional nature
[02:46:24] <cradek> ah ok
[02:47:01] <jmkasunich> you'll have to change the pin from WR to RD_WR (or whatever that is)
[02:47:15] <jmkasunich> and probably change the name to reflect the inversion of its meaning
[02:47:20] <jmkasunich> its no longer true when in sync
[02:47:30] <jmkasunich> its now true when resetting
[02:50:59] <cradek> can we back up a sec
[02:51:06] <cradek> I'm looking at this plot still
[02:51:07] <jmkasunich> sure
[02:51:29] <cradek> I agree that we can avoid the initial vel spike by starting at the right time (early)
[02:51:41] <cradek> I don't understand why it continues to oscillate after that
[02:51:56] <jmkasunich> the constant amplitude part?
[02:51:59] <cradek> yes
[02:52:05] <jmkasunich> might be granularity of the spindle encoder
[02:52:10] <cradek> it should catch up (since it can go faster than the necessary velocity)
[02:52:13] <jmkasunich> can you walk me thru the source
[02:52:17] <jmkasunich> tp.c, right?
[02:52:20] <cradek> yes
[02:52:46] <cradek> line 623
[02:53:16] <cradek> (don't laugh at how simple this is)
[02:53:18] <jmkasunich> oops, need a cvs up
[02:54:14] <jmkasunich> ok, (line 623 was blank ;-)
[02:54:20] <skunkworks> just a bit of info - the threading on turbocnc only used one pulse per rev.
[02:54:36] <skunkworks> (I think that is a little to crude?
[02:54:46] <jmkasunich> yes
[02:54:49] <cradek> seems like your threads could turn out pretty bad...
[02:54:54] <jmkasunich> ok cradek, I'm there
[02:55:09] <jmkasunich> uu_per_rev is basically the K value?
[02:56:11] <cradek> yes
[02:56:31] <jmkasunich> and tc->progress is what, the distance moved so far in this line?
[02:56:34] <cradek> tc->progress is also in uu (segment length)
[02:56:38] <cradek> yes
[02:57:03] <cradek> don't tell anyone how easy this is - they won't think of me as a miracle worker anymore
[02:57:04] <jmkasunich> both of these are tangent to the actual move, whether it is X, Y, Z, or some combination, right?
[02:57:16] <cradek> uu_per_rev comes right from the user
[02:57:25] <cradek> tc->progress is along the segment length, even if it's an arc
[02:57:27] <jmkasunich> right, the K in G33
[02:57:57] <cradek> so right, direction doesn't matter (although the interp might limit us)
[02:58:17] <jmkasunich> reqvel is the velocity needed to correct the error in one cycle
[02:58:42] <jmkasunich> you don't allow it to go backwards (line 627)
[02:59:18] <jmkasunich> but in general you also won't be able to reach reqvel instantly
[02:59:24] <jmkasunich> where is the accel limit applied?
[02:59:38] <cradek> later in tcRunCycle
[03:00:05] <cradek> tc->reqvel is just that - a request - usually comes from the F word
[03:01:33] <jmkasunich> do you know current_vel at line 623 (current_vel from the previous pass thru the code)?
[03:02:28] <cradek> yes
[03:02:32] <jmkasunich> ok
[03:02:35] <cradek> it's in the tc
[03:02:51] <cradek> so we could even do simple PID (PI?) here
[03:03:04] <cradek> I think
[03:03:07] <jmkasunich> line 624 is basically calculating a target position (spindleRevs * uu_per_rev)
[03:03:16] <cradek> yes
[03:03:47] <jmkasunich> for readibility, split that out - compute the target pos into a variable, then calc the error
[03:04:05] <jmkasunich> but before you calc the error, add a correction to the target pos based on speed mismatch
[03:05:07] <jmkasunich> time_to_match_speed = speed_error / accel_limit
[03:05:32] <cradek> you're typing into the wrong window :-)
[03:05:34] <jmkasunich> distance_to_match_speed = spindle_spd * uu_per_rev * time_to_match_speed
[03:06:21] <jmkasunich> I don't have time to climb the learning curve for the TP and test and etc, so I'm just throwing ideas at you
[03:07:07] <jmkasunich> I have no idea if that will actually work, it might be unstable or something
[03:07:24] <jmkasunich> and it relies on you knowing spindle speed
[03:07:34] <cradek> yeah that's a little tough
[03:07:40] <jmkasunich> any knowledge of spindle speed is limited by the encoder resolution
[03:07:41] <cradek> I guess you have the current and last counts, and cycle time
[03:08:07] <jmkasunich> what speed are you "running" the spindle at for these tests?
[03:08:11] <jmkasunich> and what is the PPR?
[03:08:18] <cradek> s300
[03:08:31] <jmkasunich> 5 revs/sec
[03:08:34] <cradek> setp sim-encoder.0.ppr 120
[03:08:42] <jmkasunich> (duh, I could have counted it off the scope screen)
[03:09:04] <jmkasunich> so 5 revs/sec * 120 ppr * 4 counts/pulse = 2400 counts/sec
[03:09:22] <cradek> traj cycletime is 10msec
[03:09:24] <jmkasunich> so in some servo periods, you will advance by 2 counts, in others by 3
[03:09:35] <jmkasunich> ok, sometimes 24, other times 25
[03:09:47] <jmkasunich> bet that is the cause of the steady state bounce
[03:10:01] <cradek> ah
[03:10:23] <cradek> it's true I didn't see it when I was turning at 1rev/sec
[03:10:24] <jmkasunich> oops
[03:10:41] <jmkasunich> 2400 means it will always be 24
[03:11:01] <jmkasunich> although the period isn't exactly 10mS
[03:12:16] <jmkasunich> anyway, you see the granularity issue, if not at 300 RPM = 2400 Hz, then definitely at 301RPM = 2408Hz
[03:12:37] <cradek> yeah
[03:12:47] <cradek> not sure what to do about it though (other than ignore it?)
[03:12:50] <jmkasunich> at low speed or low res it gets worse
[03:12:52] <SWP_Away> SWP_Away is now known as SWPadnos
[03:13:06] <cradek> any running-average scheme is going to surely make it worse (and much more complex)
[03:13:25] <SWPadnos> there's a possibility, in the encoder read routine
[03:13:29] <jmkasunich> the latter might be true, not sure about the former
[03:13:55] <SWPadnos> the encoder checker needs to be fast, so it may not be good to load it with velocity calcs
[03:14:11] <jmkasunich> SWP: what?
[03:14:22] <jmkasunich> the code we're discussing runs at the traj rate
[03:14:42] <SWPadnos> I understand - I'm thinking of how to have a "velocity" output that doesn't bounce around
[03:15:05] <jmkasunich> that can certainly be done in the SW based encoder counter (and I've thought about doing it)
[03:15:11] <SWPadnos> yep
[03:15:14] <jmkasunich> but it doesn't help the STG, PPMC, etc
[03:15:21] <SWPadnos> true
[03:15:41] <SWPadnos> it could in the m5i20, once I get an FPGA designed for it
[03:15:47] <jmkasunich> heh
[03:16:07] <jmkasunich> it is tempting to add a velocity output pin to all HAL encoder drivers
[03:16:16] <jmkasunich> and code it to use the best possible velocity measurement
[03:16:25] <cradek> maybe if this little wiggle doesn't interfere with our goal of cutting threads (and I suspect it doesn't) we should just move on and come back to it later if it proves to be a problem
[03:16:34] <jmkasunich> might just be (new_cnt - old_cnt)/period
[03:16:41] <jmkasunich> but it could be better
[03:17:23] <SWPadnos> in the SW encoder driver, you can count the number of interrupts between encoder pulses
[03:17:39] <SWPadnos> that gives you a pulse rate, which is proportional to speed
[03:17:52] <jmkasunich> yeah, instead of delta_cnts/period, it can be delta_cnts/delta_time
[03:18:07] <SWPadnos> if the current count exceeds the old count, recalculate every cycle
[03:18:23] <jmkasunich> you know the timing of the edges to better accuracy (the base period in the SW counter, and possibly the FPGA clock with m5i20)
[03:18:27] <SWPadnos> since the speed can't be as fast as it was, or you'd have already gotten a "step"
[03:18:32] <SWPadnos> yes
[03:19:06] <jmkasunich> (at a former employer I designed speed meters for paper machines ;-)
[03:19:11] <SWPadnos> in the TP, it would be reasonable to average over 2 or 3 periods
[03:19:21] <SWPadnos> I recall - they're still selling the same thing, no?
[03:19:25] <jmkasunich> yes
[03:19:44] <SWPadnos> for lots of dough
[03:20:06] <jmkasunich> so, we have one problem - acceling to match the spindle speed
[03:20:37] <jmkasunich> another problem (more complex IMO) is multiple synchronized moves in succession
[03:20:51] <jmkasunich> infeed, thread, pullout, for example
[03:21:07] <cradek> I should work on that next...
[03:21:35] <jmkasunich> yeah, that may well require restructuring some things
[03:21:36] <cradek> I'm not sure g33 even supports moving in a diagonal
[03:21:44] <cradek> sure, a bit
[03:21:50] <jmkasunich> could make the accel problem either easier or harder, can't tell yet
[03:22:04] <SWPadnos> g33 should support XYZ moves
[03:22:10] <jmkasunich> I suppose we're stuck with G33
[03:22:12] <jmkasunich> I
[03:22:12] <cradek> SWPadnos: ok good
[03:22:21] <cradek> trying now...
[03:22:25] <SWPadnos> tapered threads would require XZ
[03:22:32] <jmkasunich> I'd rather have g-codes that map to the canonicals sync-on and sync-off
[03:22:55] <jmkasunich> issue a "on" code, then G1, G2, or G3 with Fwords for the feed per rev
[03:23:00] <cradek> jmkasunich: me too, but that's where I have nfc what cam packages expect, and it's probably important to guess what they do
[03:23:11] <cradek> yeah that's exactly what I intended to write at first
[03:23:24] <SWPadnos> I think it should be a single block, and the TP or interp needs to figure it out
[03:23:27] <cradek> it would be nice to have arcs
[03:23:37] <SWPadnos> I'm pretty sure this is what's expected
[03:23:52] <jmkasunich> SWP: what should be a single block? an entire threading pass?
[03:24:02] <SWPadnos> no, the synch duration
[03:24:10] <SWPadnos> G33 this / G33 that etc.
[03:24:13] <cradek> I just did a synced XZ move and it worked fine
[03:24:20] <SWPadnos> cool
[03:25:10] <SWPadnos> actually, it could be modal, but it would be in the same group as G0 / G1 / G2, so any of those would cancel it
[03:25:41] <jmkasunich> so G0 <initialpos> then G33 <infeed move>K<infeed rate> then G33 <threading move> K <pitch> then G33 <outfeedmove> K <outfeed rate> then G0 <start of next pass>
[03:26:00] <SWPadnos> I think so
[03:26:15] <cradek> I can do that, SMOP
[03:26:17] <jmkasunich> SWP: grouping it with 0123 means you'd never be able to specify an arc
[03:26:25] <SWPadnos> that is true
[03:26:39] <jmkasunich> thats why I liked the "turn it on, specify several moves, turn it off" model
[03:26:44] <cradek> I'd like to have arcs for in/outfeed
[03:26:48] <jmkasunich> yes
[03:26:56] <cradek> jmkasunich: there's no reason why a canned cycle can't do that under the covers
[03:27:02] <cradek> we can make them as elegant as we want
[03:27:17] <cradek> we just have to preserve the simplest G33 interface so it does what people expect
[03:27:18] <jmkasunich> tangent arcs means you maintain constant feedrate, don't have to worry about blending
[03:27:40] <cradek> heh, well sort of
[03:28:01] <cradek> I wish they worked that well
[03:28:09] <jmkasunich> what does the TP do now for tangent line-arc or arc-line or arc-arc?
[03:28:29] <cradek> it blends them with sort-of-parabolas
[03:28:47] <jmkasunich> if they are tangent, there should be no blending
[03:29:17] <cradek> I agree, but you asked me what it does now
[03:29:21] <jmkasunich> heh
[03:29:48] <cradek> there's still an abrupt accel change that you have to deal with - it's not quite as simple as you say
[03:30:09] <jmkasunich> abrupt accel change = jerk
[03:30:11] <jmkasunich> and thats allowed
[03:30:17] <cradek> yes
[03:30:22] <jmkasunich> (not ideal, but allowed)
[03:30:27] <jmkasunich> as long as the accel is cross-track
[03:30:53] <jmkasunich> if two segments are tangent, and have the same speed, there should be zero tangential acceleration during the blend
[03:31:00] <cradek> well I'll worked on multiple synced moves next
[03:31:09] <jmkasunich> if there is, thats a problem (and it will screw up threading)
[03:31:57] <cradek> I'm trying to picture what you mean
[03:32:06] <cradek> tangential segments = colinear?
[03:32:27] <jmkasunich> picture a oval racetrack - two straights, two curves (constant radius curves)
[03:32:34] <cradek> ok
[03:32:53] <jmkasunich> as you go from straight to curve, you feel force throwing you to the outside - that is "cross track" accel and is OK
[03:33:11] <cradek> right
[03:33:17] <jmkasunich> if you find yourself pressed into the seatback or nose-to-steering-wheel, then you had tangential accel/decel, thats bad
[03:33:23] <cradek> because you are acceling to the center of the track
[03:33:32] <cradek> ok, I see what you mean
[03:33:55] <cradek> I'm not sure what we have now. It's probably not perfect
[03:33:57] <jmkasunich> that one thing I wondered about as you were doing the TP stuff with all those nice axis plots
[03:34:17] <jmkasunich> the plots give absolutely no info about tangential accel/decel
[03:34:28] <cradek> that's true
[03:34:53] <jmkasunich> it would be interesting to set up a "racetrack" in a 4-5 line program
[03:34:56] <jmkasunich> and scope it
[03:35:39] <cradek> I think any arc blending is worse than the line-line
[03:36:05] <cradek> I bet your racetrack plot won't be as good as you wish.
[03:36:16] <jmkasunich> I was afraid you might say that
[03:36:30] <jmkasunich> and that will affect threading
[03:36:36] <cradek> not if we don't use arcs
[03:37:08] <jmkasunich> what you have now (call it threading v1.0) will work if you start and end in a groove (or off the end of the part)
[03:37:32] <cradek> sure
[03:37:48] <jmkasunich> but a pullout move, whether a tangent arc or a non-tangent line, will probably include a change in linear speed, meaning a change in thread pitch
[03:38:56] <cradek> if you cut at k1 and you want to pull out at 45 degrees, you'll have to program k sqrt(2) or k 1/sqrt(2) or whatever it is
[03:39:04] <jmkasunich> yes
[03:39:16] <cradek> I think that's fine
[03:39:25] <cradek> the canned cycle will do it for you
[03:39:40] <jmkasunich> and even if you do that, I'm not sure you'll get constant velocity on the Z axis, because the blending code might have tangential accel
[03:40:45] <jmkasunich> I dunno, maybe it would be ok
[03:40:48] <cradek> 2nd derivative of a parabola is a constant, I think that means no tangential accel
[03:40:52] <jmkasunich> only way to know is to try it I guess
[03:40:55] <cradek> * cradek waves his hands
[03:41:58] <jmkasunich> we need a HAL component that takes X,Y,Z and returns the magnitude of the vector
[03:42:26] <jmkasunich> then you can feed it the three velocities, and the magnitude is the tangential velocity
[03:42:40] <cradek> that would be interesting
[03:42:43] <jmkasunich> it should be (and probalby is) constant during arcs
[03:43:01] <cradek> yes I'm sure it is (not near the ends)
[03:43:08] <jmkasunich> it should be (but might not be) constant during blends between segments with the same F word
[03:43:56] <cradek> I think it's very close to constant in that case
[03:44:06] <jmkasunich> I know of one case where it can't be
[03:44:09] <jmkasunich> a reversal move
[03:44:19] <cradek> sure
[03:44:43] <jmkasunich> and I bet it is non-constant for a tight bend (say 170 degrees)
[03:45:13] <SWPadnos> there should be some tangential acceleration for any two moves with the same F word, but not the same direction
[03:45:15] <cradek> that would depend greatly on how you have tolerance set
[03:45:31] <SWPadnos> since the F word is the vector sum of all axis vels
[03:45:48] <jmkasunich> SWP - not in the ideal case
[03:46:04] <cradek> I think jmk is right
[03:46:11] <SWPadnos> of course, in the ideal case, there's infinite accel ;)
[03:46:26] <jmkasunich> if you take two non-tangent lines (that meet at some angle) you can draw a constant radius arc that connects them
[03:46:33] <cradek> no you don't need infinite accel to maintain tangent velocity
[03:46:51] <jmkasunich> the radius of the arc determines the accel, and its all sideways, none tangential
[03:47:16] <jmkasunich> the tighter you try to make the corner the more accel you need
[03:47:19] <SWPadnos> ah, I see. go ahead, I'll have another useless interruption later :)
[03:47:36] <cradek> so in these blended moves you would want/expect the tangential accel to stay near 0?
[03:48:07] <jmkasunich> if the turn is large (like 170 degrees) and the required radius is also large (limited accel), you can have a case where the arc starts a LONG way from the point where the two lines intersect
[03:48:21] <cradek> right
[03:48:24] <jmkasunich> credek: if possible yes
[03:48:38] <cradek> ok, just trying to picture what it would look like
[03:48:54] <jmkasunich> imagine drawing a toolpath with straight lines in a cad package
[03:49:09] <jmkasunich> then use the "draw fillet" command to draw fillets at every bend
[03:49:21] <jmkasunich> fillet radius is fixed, based on F word and accel limit of the machine
[03:49:37] <jmkasunich> (I'm assuming F word is constant through the whole thing)
[03:49:39] <cradek> got it
[03:49:51] <jmkasunich> you can get in trouble if segments are short
[03:50:02] <jmkasunich> simply _can't_ draw the arcs
[03:50:18] <cradek> you'll have abrupt changes in accel at the line-arc transitions (and infinite jerk) but the tangential accel is 0 everywhere
[03:50:27] <jmkasunich> right
[03:50:43] <cradek> yeah we should figure out a way to plot that
[03:50:52] <cradek> would be interesting but I don't know if it'll lead to any improvement
[03:51:17] <jmkasunich> its basically another approach to doing a TP
[03:51:40] <cradek> right
[03:52:08] <cradek> but I bet arcs make bad blends. they don't get as near the endpoints as parabolas.
[03:52:18] <cradek> depends what you want I guess
[03:52:51] <jmkasunich> I bet they do, if you limit both the arc and the parabola to the same max accel
[03:52:58] <tomp_> cuz they have radius, they are prone to 1 unit errors at least
[03:53:05] <cradek> ok next I'm going to work on multiple synced commands in a row.
[03:53:11] <cradek> this is all a sidetrack I want to avoid
[03:53:16] <jmkasunich> ok
[03:53:28] <jmkasunich> I also need to avoid a sidetrack, the lathe awaits
[03:53:32] <skunkworks> I've got it - it all makes sense. Oops - lost it again. time for bed. Night everyone.
[03:53:37] <cradek> hope you're almost done with those
[03:53:40] <cradek> so you can get back to emc
[03:54:03] <jmkasunich> I haven't made one chip yet tonight
[03:54:17] <jmkasunich> I should be back for real friday night
[03:54:23] <cradek> ok
[03:54:30] <cradek> maybe I'll have this going by then.
[03:54:38] <jmkasunich> and away for work travel monday thru wednesday ;-(
[03:54:47] <cradek> at least you have a weekend.
[03:55:02] <cradek> skunkworks: goodnight
[03:58:44] <cradek> ok back to work on my board - see everyone later
[03:58:56] <SWPadnos> see ya
[04:53:28] <SWPadnos> SWPadnos is now known as SWP_Away
[13:21:04] <alex_joni> hi ray
[13:30:02] <rayh> Hi Alex. Sorry I was away writing email.
[13:30:16] <rayh> I see quite a few additions to sf since yesterday.
[13:32:54] <rayh> I'll put this on top so I can see changes.
[13:45:58] <alex_joni> what additions do you mean?
[13:46:38] <rayh> I saw bits of config and bits of tp.
[13:47:38] <rayh> I plan to have the axis variable gui finished today.
[15:26:05] <rayh> I'm in a bit of a crisis with handling axis calibration. Can I bounce a few ideas off you'se guys.
[15:27:13] <cradek> rayh: if you think it will help to talk to a stepper guy, I'm all ears
[15:27:30] <SWP_Away> SWP_Away is now known as SWPadnos
[15:27:48] <rayh> K. It's not a stepper v servo issue. It's a tickle issue.
[15:28:15] <rayh> tickle's array does not order events in or out.
[15:29:04] <rayh> I can build array elements like "configarray(axis, inivar,halcmd)
[15:29:28] <rayh> sorry "configarray(axis,inivar,halcmd)
[15:29:51] <rayh> and store value in it.
[15:30:11] <jepler> If you want to get the elements of an array in some order, you have to write something like [lsort [array names configarray]]
[15:30:17] <rayh> but when I build the display, it is in nearly random order.
[15:30:45] <jepler> you can use lsort -command to define your own ordering, or use the flags like -ascii, -integer, or -real if they're appropriate for this case (my gut says not)
[15:30:46] <cradek> * cradek leaves this to the guys who know tcl
[15:30:49] <rayh> Right and to get it in the order of the halcmd commands that built it I'd have to add an order variable.
[15:31:12] <jepler> If keeping the order is important, then you may want to use a Tcl list, not an array.
[15:31:24] <rayh> That is what I was thinking.
[15:31:58] <rayh> If I make a single list with elements like {axis,inivar,halcmd}
[15:32:39] <rayh> can I use regexp to find the halcmd within each element
[15:32:50] <jepler> Well, you could make the elements lists themselves
[15:32:55] <rayh> or would I have to foreach element $list.
[15:33:07] <rayh> I'm all eyes
[15:33:09] <jepler> you could create an element with the command [list $axis $inivar $halcmd]
[15:33:21] <jepler> and then get the halcmd element out with [lindex $whatever 2]
[15:33:34] <rayh> Sure.
[15:33:35] <jepler> that works even if halcmd (or any of the others) contain spaces or commas
[15:33:55] <rayh> Right good thinking.
[15:34:32] <jepler> but if you want to say "find me the halcmd(s) associated with a given axis", yes, you have to use something like 'foreach'
[15:34:37] <rayh> The heart of my confusion is finding the right element in the whole list using only one of the variables within
[15:34:50] <rayh> okay that answers it.
[15:35:19] <rayh> looks a klunky and hammer handed as hell but what can you do when your abilities are as limited as mine or tcl's.
[15:35:45] <rayh> Thanks
[15:35:53] <jepler> I hope I was able to help at least a little bit.
[15:36:15] <rayh> You bet. You clarified all my wonderings.
[15:37:30] <rayh> Looks like an array with the inivar as the arrayName and all the stuff as the value.
[15:37:51] <rayh> That way I can lookup quickly
[15:38:18] <rayh> * rayh goes off to play
[15:38:49] <alex_joni> * alex_joni goes home
[15:38:52] <alex_joni> food time :D
[15:40:28] <jepler> I wonder if "savannah" (
http://savannah.nongnu.org/) is any more reliable than sourceforge.
[15:41:13] <rayh> We discussed savannah and a couple other repositories when we moved the stuff from NIST.
[15:41:29] <rayh> At that time, sf was the best of the lot.
[15:41:34] <jepler> I'm not so sure these days
[15:41:40] <rayh> Right.
[15:41:48] <cradek> I've seen savannah down for days/weeks too
[15:42:00] <cradek> but maybe only once?
[15:42:13] <jepler> There was "that one time" that savannah got hacked
[15:42:15] <rayh> Yea. Matt has/had a project there for a while.
[15:42:20] <cradek> jepler: right
[17:34:23] <alex_joni> hi guys
[17:53:10] <alex_joni> hrmm.. everyone hiding?
[18:24:44] <rayh> Hi alex
[19:10:45] <jepler> alex_joni: slow day
[19:53:50] <alex_joni> very slow ;)
[19:54:40] <SWPadnos> yep
[21:42:55] <rayh> Yes I'm moving like mole asses in january hereabouts.
[21:43:57] <alex_joni> only 2h between messages
[21:43:57] <alex_joni> :D
[21:46:33] <rayh> Hi Alex.
[21:46:43] <rayh> Now you know that I'm a slow coder.
[21:50:00] <alex_joni> no I meant talking in here
[21:50:07] <alex_joni> coding is allowed slow sometimes
[21:51:26] <rayh> always for me?
[21:52:43] <cradek> slow and steady wins the race
[21:55:54] <cradek> this reminds me - I suggested halcmd-type functionality be built into emcsh to avoid all the [exec] mess - but it seems like there was some objection I don't remember - does anyone remember what it was?
[21:57:02] <rayh> What of the existing commands would this change?
[21:57:31] <cradek> anything that's written in tcl and execs halcmd to talk to hal
[21:58:12] <rayh> Allright. Then none of the existing would be changed.
[21:58:41] <rayh> unless we want to bypass a current nml path.
[21:58:56] <cradek> oh existing emcsh commands? none
[21:59:04] <cradek> I didn't understand your question
[21:59:19] <rayh> np I probably wasn't real clear.
[22:00:19] <alex_joni> cradek: I objected to that, but not because I don't like it, but because you suggested it for halui
[22:00:26] <alex_joni> which I think is something else
[22:00:38] <cradek> I did?
[22:00:44] <cradek> I'm so confused
[22:00:48] <alex_joni> yeah, if I remember it correctly
[22:00:53] <alex_joni> this was a few days ago
