Back
[01:37:57] <jmkasunich> SWPadnos: around?
[01:38:58] <jmkasunich> I finally stopped procrastinating and started looking at the code
[01:39:09] <jmkasunich> the more I look at it, the less I like "interpolate mode"
[01:39:21] <jmkasunich> I think I'd rather provide an "interpolated position" pin
[02:56:41] <SWPadnos> OK, that has my vote
[02:57:43] <jmkasunich> I hate hard-coded constants
[02:57:58] <jmkasunich> encoder has one
[02:58:24] <jmkasunich> "if no counts in the last 100mSec, then force velocity output to zero"
[02:58:45] <SWPadnos> hmmm
[02:58:50] <jmkasunich> that was done because otherwise when the shaft stops, the velocity slowly tails off
[02:58:56] <SWPadnos> that could be a param instead
[02:59:14] <jmkasunich> it is calculated as "what would the velocity be if the next count arrived a nS from now"
[03:00:17] <jmkasunich> no counts in 100mS = "damn near stopped" when you have a high PPR encoder
[03:00:20] <jmkasunich> not so when you have 1 ppr
[03:00:57] <jmkasunich> one very neat thing - remember I was talking about the interpolation being done by integrating the velocity output?
[03:01:46] <jmkasunich> Instead I'm doing "interp_pos = regular_pos + (time_since_last_count * velocity_output)
[03:02:12] <SWPadnos> heh - sounds easy :)
[03:02:25] <jmkasunich> that has the convenient result of freezing the position at last_count + 1 count when no counts are recieved
[03:02:39] <jmkasunich> (because the velocity starts dropping when the expected count doesn't arrive on time)
[03:02:58] <SWPadnos> hmmm. that could give some backwards motion I think
[03:03:16] <SWPadnos> no, it'll just stop
[03:03:19] <jmkasunich> right
[03:04:16] <jmkasunich> it works very nicely with a constant speed (duh)
[03:04:25] <jmkasunich> trying a sinusoidal speed now
[03:04:32] <jmkasunich> (using sim-encoder, not on real hardware yet)
[03:06:51] <jmkasunich> actually works reasonably well
[03:07:19] <jmkasunich> when decelerating, the interpolated output reaches +1 step, then pauses till the count occurs and the non-interp output catches up
[03:07:37] <jmkasunich> when accelerating, the interpolated output jumps to catch up with the non-interp output when the count occurrs
[03:08:27] <SWPadnos> I guess one could filter externally if the "glitches" are troublesome
[03:08:49] <jmkasunich> the glitches are proportional to the accel/decel of the spindle
[03:08:53] <SWPadnos> yep
[03:09:02] <jmkasunich> which if more than a few percent is gonna be hopeless for threading anyway
[03:09:26] <jmkasunich> oops, found a problem
[03:10:02] <jmkasunich> I found a case where the interpolated output gets more than one count away from the non-interp one
[03:10:21] <jmkasunich> the negative peak of a sinusoidal velocity profile
[03:10:49] <SWPadnos> is the plus sign causing trouble?
[03:10:53] <SWPadnos> or is vel signed?
[03:11:00] <SWPadnos> (or both? :) )
[03:11:06] <jmkasunich> vel should be signed, looking at it now
[03:13:58] <jmkasunich> looks like I found a bug in the velocity estimator
[03:14:22] <jmkasunich> it decays when the count doesn't arrive when expected, if it is positive
[03:14:25] <jmkasunich> but not if its negative
[03:14:59] <SWPadnos> it sounded like a plus sign error
[03:16:27] <jmkasunich> duh:
[03:16:28] <jmkasunich> /* not to long, estimate vel if a count arrived now */
[03:16:28] <jmkasunich> vel = ( cntr->scale ) / (delta_time * 1e-9);
[03:16:28] <jmkasunich> /* use lesser of estimate and previous value */
[03:16:28] <jmkasunich> if ( vel < *(cntr->vel) ) {
[03:16:28] <jmkasunich> *(cntr->vel) = vel;
[03:16:31] <jmkasunich> }
[03:16:39] <jmkasunich> "lesser" needs to be based on magnitude
[03:16:51] <SWPadnos> or direction even
[03:17:38] <jmkasunich> both
[03:17:47] <SWPadnos> right!
[03:17:50] <SWPadnos> I must be tired
[03:17:59] <jmkasunich> to make it worse, cntr->scale can be signed....
[03:18:06] <SWPadnos> true
[03:18:37] <SWPadnos> theoretically, both will be calculated from the same scale value (though that's not guaranteed)
[03:19:12] <jmkasunich> the velocity that is actually calculated from time between pulses always has the right sign - regardless of direction of rotation or scale
[03:19:37] <jmkasunich> but the "limit" based on "time since last count" has the sign of scale only
[03:19:49] <jmkasunich> the limit should probably be exactly that - a magnitude limit
[03:28:15] <jmkasunich> working better now
[03:31:20] <jmkasunich> heh, with this component you could do semi-rigid tapping with a low PPR encoder
[03:31:31] <SWPadnos> cool
[03:31:44] <SWPadnos> flaccid tapping, I think someone said :)
[03:31:45] <jmkasunich> you'd need a tension-compression holder with aproximately 2 counts of travel
[03:32:45] <jmkasunich> if your encoder was 4 counts/rev, and you are tapping 20 tpi, you'd need (2counts/ 4cpr)*(1/20tpi) of travel
[03:33:04] <SWPadnos> .025
[03:33:26] <jmkasunich> its basically always within one count of the integer counted position
[03:33:44] <jmkasunich> which is in turn always within one count of the real (infinite resolution) position
[03:35:05] <jmkasunich> I need to build a more complex test setup - I want to start exercising the index pins
[03:35:33] <jmkasunich> still dunno what I'm gonna do about that hard-coded constant
[03:35:38] <jmkasunich> I've changed it to one second for now
[03:36:17] <SWPadnos> ouch
[03:36:24] <jmkasunich> ?
[03:36:30] <SWPadnos> 1 second is a long time
[03:37:13] <jmkasunich> depends on what you are using the velocity term for
[03:37:36] <jmkasunich> suppose you have 1ppr, and you ramp down from 1000 RPM to 0
[03:37:58] <jmkasunich> quickly - say over just 1 second
[03:38:39] <jmkasunich> the velocity output will tail off from whatever the vel was over the last full rev, to 60 RPM after one second, then drop to zero
[03:39:24] <SWPadnos> err
[03:40:07] <SWPadnos> ah, the example is stopping just before the next count arrives?
[03:40:11] <jmkasunich> yeah
[03:40:30] <jmkasunich> well, you could be stopping just after the last count arrived
[03:41:05] <jmkasunich> the encoder counter has no way of knowing which case actually happened (or if you stopped at all, you might just be crawling along at 0.1 RPM)
[03:41:38] <jmkasunich> actually you could be crawling at 50 RPM
[03:41:48] <jmkasunich> thats still less than one count per second
[03:42:19] <SWPadnos> the sampler would be going much faster than 1 Hz though
[03:42:38] <jmkasunich> what sampler? you mean the encoder counter code?
[03:42:42] <SWPadnos> yes
[03:42:43] <jmkasunich> sample rate doesn't matter
[03:42:59] <SWPadnos> ok - it's bed time :)
[03:43:04] <jmkasunich> if there is only 1 ppr, you can sample at a MHz and you still won't know anything till that one pulse rolls around
[03:43:10] <SWPadnos> I just got why 1/sec matters :)
[03:43:39] <jmkasunich> its tempting to remove that timeout completely
[03:44:03] <jmkasunich> but that would require changing some other stuff - right now the time delta is limited to 2^31 nanoseconds
[04:16:35] <jmkasunich> SWPadnos: still there, or did you go to bed?
[04:16:46] <SWPadnos> I'm half here
[04:17:05] <jmkasunich> I'm trying to define "reasonable" test conditions
[04:17:40] <jmkasunich> right now I'm running 1ppr, 300 RPM nominal, varying +/- 30 RPM at a 1Hz rate
[04:18:06] <SWPadnos> sinusoidal variation
[04:18:07] <jmkasunich> starting a threading pass every 5 seconds
[04:18:08] <SWPadnos> ?
[04:18:10] <jmkasunich> yes
[04:18:16] <SWPadnos> try sawtooth
[04:18:16] <cradek> reasonable test conditions = cut some threads?
[04:18:37] <jmkasunich> its midnight - I'm running sim at the moment
[04:18:42] <SWPadnos> that's only reasonable if you're hooked to hardware :)
[04:19:03] <jmkasunich> I can do that tomorrow, but it will be hard to control spindle load and slowdown
[04:19:26] <jmkasunich> my spindle is pretty robust, unless you slip the belts
[04:20:14] <cradek> mine's also probably too good to work badly
[04:20:21] <jmkasunich> heh
[04:20:26] <cradek> you really need the little tormach one :-)
[04:20:48] <jmkasunich> well, I'm sure SWPadnos can do that eventually
[04:21:08] <SWPadnos> heh - eventually
[04:21:27] <SWPadnos> I'm thinking about visiting them when it's time to give their PC back
[04:21:49] <SWPadnos> but I don't know when that will be
[04:22:04] <jmkasunich> I'm gonna post a halscope screenshot, just a sec
[04:23:24] <jmkasunich> http://jmkasunich.com/pics/interpolated-encoder.png
[04:23:41] <jmkasunich> the sinewave is the speed, 300+/-30 RPM
[04:23:53] <jmkasunich> the green square is the "encoder" signal
[04:24:10] <jmkasunich> red is the uninterpolated encoder position
[04:24:25] <jmkasunich> light blue is the interpolated position
[04:24:50] <cradek> looks very promising
[04:24:52] <jmkasunich> the vertical drop on the left (both blue and red do the same thing) is the "reset on index" at the start of a threading pass
[04:25:06] <SWPadnos> it looks pretty good so far. I think the real tests will be very low speeds and actual cutting
[04:26:00] <jmkasunich> I'll have to make a modified config for my machine
[04:26:09] <jmkasunich> one encoder counter counting the full res of the encoder
[04:26:17] <jmkasunich> another connected only to the index pulse
[04:26:33] <jmkasunich> connect first one, then the other, to EMC
[04:26:46] <jmkasunich> and compare in halscope the position feedbacks from both
[04:27:41] <jmkasunich> something tells me I'm gonna use up a fair amount of bar testing this
[04:30:46] <SWPadnos> keep cutting the same thread - you'll see errors if anything comes off the stock
[04:30:52] <SWPadnos> (at least for a little while)
[04:30:55] <jmkasunich> I switched the speed disturbance from a sine to a sawtooth (probably more realistic - drop when it starts cutting, slowly recover
[04:31:04] <SWPadnos> yep, that was my thought
[04:31:16] <jmkasunich> if I keep cutting the same thread, the load on the spindle will be zero
[04:31:23] <jmkasunich> no speed variations
[04:31:34] <SWPadnos> truwe
[04:31:37] <SWPadnos> -w
[04:33:46] <SWPadnos> ok, bedtime for real now. good night
[04:33:51] <jmkasunich> goodnight
[04:34:02] <jmkasunich> I'm about to commit this, if you want to play with it yourself tomorrow
[04:34:14] <jmkasunich> I'll do more testing, but probably not till evening
[04:37:53] <CIA-20> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/components/encoder.c: fix problem with velocity estimator (when output is negative), add interpolated position for low ppr encoders (only works when speed is relatively constant - lathe threading, not position control or rigid tapping)
[13:00:39] <CIA-20> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/ladder/classic_ladder.lyx: Fixed various things and added S32 input and output to table in classicladder
[13:00:56] <CIA-20> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Master_Integrator.lyx: Fixed various things and added S32 input and output to table in classicladder
[13:01:11] <CIA-20> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/motion/ (pid_theory.lyx tweaking_steppers.lyx): Fixed various things and added S32 input and output to table in classicladder
[13:01:27] <CIA-20> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/Master_Integrator.lyx: Fixed same as 2.2.x
[13:01:28] <CIA-20> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ladder/classic_ladder.lyx: Fixed same as 2.2.x
[13:01:29] <CIA-20> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/motion/ (pid_theory.lyx tweaking_steppers.lyx): Fixed same as 2.2.x
[13:13:02] <CIA-20> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ladder/classic_ladder.lyx: Opps missed one in TRUNK, now they are the same.
[14:08:14] <Roguish_> Roguish_ is now known as Roguish
[14:25:06] <CIA-20> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ini_config.lyx: Fixed odd color of some entries in the contents
[14:27:13] <jepler> jmkasunich: does the velocity estimation fix apply to 2.2?
[14:43:31] <skunkworks> jepler: touchoff friday was my fault.. the puma config defaulted to machine coordinates.
[14:44:46] <jepler> "touchoff friday"
[14:44:52] <jepler> hi skunkworks
[14:46:16] <skunkworks> morning. '*the problem I was having with touchoff friday' :)
[14:48:04] <jmkasunich> jepler: yes, I suspect it does
[14:48:14] <jmkasunich> I'm about to go out for a while, I'll backport it this evening
[14:48:49] <jepler> jmkasunich: thank you
[14:54:04] <CIA-20> EMC: 03jepler 07TRUNK * 10emc2/src/hal/components/ilowpass.comp: new component
[14:54:25] <CIA-20> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/config/ini_config.lyx: Fixed odd color of some entries in the contents
[15:22:36] <BigJohnT> hi alex
[15:25:47] <alex_joni> hi BigJohnT
[15:47:02] <BigJohnT> I'm getting this error during make
[15:47:04] <BigJohnT> hal/classicladder/drawing.c: In function ‘DrawCurrentElementEdited’:
[15:47:06] <BigJohnT> hal/classicladder/drawing.c:960: warning: ISO C90 forbids mixed declarations and code
[15:47:20] <BigJohnT> on a fresh download of TRUNK
[16:46:36] <jepler> BigJohnT: "warning:" means that the problem indicated is not an error
[16:47:27] <jepler> BigJohnT: it just means that the compiler doesn't approve of that line of code. In this case, it's warning that the code would cause problems for a compiler that only conforms to the 1990 C language standard, not the 1999 standard.
[16:57:58] <BigJohnT> jepler: thanks, didn't know if it was important or not
[17:01:26] <lerman> In the commercial world I came from, that would be considered an error. Either the code should be changed or the makefile that invokes the compiler in a way that the warning is generated should be changed.
[17:09:38] <alex_joni> lerman: right
[21:17:21] <CIA-20> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/ (Master_Integrator.lyx Master_User.lyx): Fixed contents so it shows up in the index
[22:17:43] <CIA-20> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ini_homing.lyx: Fixed contents so it shows up in the index
[22:17:52] <CIA-20> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Master_Integrator.lyx Master_User.lyx): Fixed contents so it shows up in the index
[22:57:08] <Guest430> Guest430 is now known as skunkworks
