Back
[00:14:57] <CIA-20> EMC: 03jmkasunich 07v2_2_branch * 10emc2/src/hal/components/encoder.c: fix problem with negative values of velocity estimate - backport from TRUNK
[01:00:07] <cradek> BigJohnT: btw, you rock
[01:03:35] <jepler> yes indeed he does
[01:11:28] <jmkasunich> does fixing an obscure problem on a rarely used feature (velocity from encoder) warrent a changelog entry?
[01:17:28] <jepler> yes.
[01:18:41] <jmkasunich> I tend to forget changelog....
[01:21:50] <CIA-20> EMC: 03jmkasunich 07v2_2_branch * 10emc2/debian/changelog: fix problem with negative values of velocity estimate - backport from TRUNK
[01:25:38] <SWPadnos> don't forget the changelog on TRUNK (assuming there is one)
[01:26:55] <jepler> no
[01:27:08] <jepler> well, for the feature that is in TRUNK but not in 2.2 a changelog message is nice
[01:27:13] <jepler> but don't duplicate bugfix changelog messages
[01:27:38] <SWPadnos> like "* added interpolated position to encoder
[01:27:42] <SWPadnos> "
[01:27:59] <BigJohnT> hi guys, been out on the deck time to veg out now see you later
[01:28:05] <jepler> see you BigJohnT
[01:28:06] <SWPadnos> heh - see you
[01:28:15] <BigJohnT> have a good evening
[01:37:48] <CIA-20> EMC: 03jmkasunich 07TRUNK * 10emc2/debian/changelog: record recent changes
[01:40:07] <SWPadnos> heh - thanks :)
[01:47:33] <jmkasunich> working my way around to on-machine testing
[01:48:05] <jmkasunich> slowly
[01:48:35] <jmkasunich> btw, the interpolated output can (and should) be used for threading even with high ppr encoders
[01:49:01] <jmkasunich> imagine a 1KHz servo rate, and an encoder that is counting at 2,010 Hz
[01:49:19] <jepler> I had wondered about that
[01:49:20] <jmkasunich> you'll get 2 counts per period for 100 periods, then 3 counts per period, then 2 again
[01:49:42] <jmkasunich> during the 2 counts/period time, the counts are getting earlier and earlier in the period
[01:49:50] <jmkasunich> the interpolated output corrects for that
[01:51:05] <jmkasunich> if the base period is 30x the servo period (33uS) then the error due to that "beat frequency" will be 30 times smaller
[01:52:38] <fenn> not just threading but everything?
[01:52:46] <jmkasunich> no, not for position control
[01:52:57] <jmkasunich> the interpolation assumes that the speed is approximately constant
[01:53:15] <jmkasunich> which isn't true for position control or for rigid tapping where you reverse the spindle
[01:55:15] <jmkasunich> the non-interpolated output is always within +/- one count of the actual position
[01:55:32] <jmkasunich> the interpolated position can be much closer than that, IF the speed is not changing rapidly
[01:55:44] <jmkasunich> but if it is changing, it can be up to +/- two counts away
[02:00:00] <SWPadnos> I think that can only happen at low speed - like at a reversal
[02:00:14] <SWPadnos> (unless I missed something in the calculation)
[02:00:33] <jmkasunich> I think that is true
[02:00:49] <jmkasunich> but position control certainly involves operation around zero speed
[02:00:56] <SWPadnos> sure
[02:01:23] <SWPadnos> I believe there has to be a reversal between one count and the next for the interpolated position to be 2- counts off
[02:02:05] <jepler> pos-interp seems to systematically lead position
[02:02:12] <SWPadnos> yes
[02:02:29] <SWPadnos> it should put a ramp on the staircase you normally get
[02:03:10] <jepler> it leads by more than a few counts:
http://emergent.unpy.net/index.cgi-files/sandbox/encoder-position.png
[02:03:34] <jmkasunich> you sure both traces have zero at the same spot?
[02:03:40] <jepler> well maybe not
[02:04:00] <jepler> I set them to the same offset but I have no idea where their baselines are
[02:04:14] <jmkasunich> thats an annoyance about scope that I was noticing last night
[02:04:18] <SWPadnos> heh
[02:04:29] <jmkasunich> unless you drag the position sliders all the way up or down, its hard to get them exactly the same
[02:04:34] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/encoder-position2.png
[02:04:37] <jepler> oh look I was wrong
[02:04:43] <SWPadnos> yay! :)
[02:04:48] <jmkasunich> whew!
[02:05:10] <SWPadnos> those jaggies have got to go IMO :)
[02:05:26] <SWPadnos> (the halscope-induced ones, not the interp output)
[02:09:27] <jepler> at direction reversal:
http://emergent.unpy.net/index.cgi-files/sandbox/encoder-position3.png
[02:09:53] <jmkasunich> looks familar
[02:10:07] <SWPadnos> yep - that's about what I expected
[02:11:21] <jepler> so for threading you'd want pos-interp but for rigid tapping you wouldn't?
[02:11:29] <jmkasunich> right
[02:11:49] <jepler> sucks if you want to do both on the same machine
[02:12:04] <jmkasunich> if you had an un-quenchable desire to do tapping on a mill, but only had 8ppr. you could use it with a tension-compression tap holder
[02:12:13] <SWPadnos> I wonder if it would make sense to assume no motion when abs(vel) is < "some arbitrary value"
[02:12:30] <jmkasunich> another hard coded constant?
[02:12:38] <SWPadnos> at which point interpolated-pos would just be equivalent to pos
[02:12:58] <SWPadnos> possibly, or maybe based on the detected accel
[02:13:01] <jepler> this never gets more than one count away from the true value, right?
[02:13:10] <jmkasunich> two
[02:13:19] <SWPadnos> if vel < (oldvel - vel) then a reversal could be about to happen
[02:13:30] <SWPadnos> (plus some sign checking)
[02:13:58] <SWPadnos> hmmm - or something like that anyway
[02:50:18] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=469914#post469914
[06:18:48] <alex_jon1> alex_jon1 is now known as alex_joni
[12:00:44] <jepler> skunkworks: the answer is "no; program the setting you want in the prologue of each gcode file".
http://linuxcnc.org/docs/html/gcode_main.html#r8_4 The reset to G64 without P- should be noted on this list
http://linuxcnc.org/docs/html/gcode_main.html#M2--1 but it is not
[12:03:44] <BigJohnT> jepler: does the reset to G64 happen after M2 and M30?
[12:28:39] <jepler> BigJohnT: maybe I'm mistaken about that (I looked in the source code but don't see it), but in general M2 is intended to reset all modal codes to a default.
[12:30:42] <jepler> the advice to program desired modal codes at the beginning of each program is still good advice :-P
[12:37:04] <jepler> oh hm there is a real bug here
[12:38:17] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/g61-requested.png
[12:38:38] <jepler> load program; run; hit F2 F2; run. On that run, it's in G64 mode even though G61 is written in the program.
[12:42:47] <BigJohnT> jepler: ok thanks
[12:44:47] <jepler> http://sourceforge.net/tracker/index.php?func=detail&aid=2006736&group_id=6744&atid=106744
[12:45:12] <jepler> time to go to work
[12:46:17] <SWPadnos> there's no feed rate in the example code - I wonder if that matters
[12:46:53] <SWPadnos> yes, there is a setting in the ini file, it's something lke [EMC]RS274NGC_STARTUP_CODES
[12:47:43] <SWPadnos> I think it gets run only once when EMC starts up, though there was discussion of either running that at every program run or adding another ini setting which would be run that way
[12:48:06] <jepler> SWPadnos: I don't believe inRS274NGC_STARTUP_CODES; I'm not sure the way it works is useful
[12:48:33] <SWPadnos> it may not be, except that it can change (or ensure) default conditions at startup
[12:51:17] <alex_joni> SWPadnos: there should be RS274NGC_SYNCH_CODES too
[12:51:29] <alex_joni> for it to work like you proposed
[12:51:54] <SWPadnos> "should be" meaning it was imoplemented, or meaning that's what you would call it? :)
[12:51:58] <SWPadnos> -o
[12:52:11] <alex_joni> it wasn't implemented
[12:52:50] <alex_joni> something that gets run after M2 or in some other odd cases :D
[12:53:00] <alex_joni> but I don't want to think this through
[12:53:27] <SWPadnos> ok yeah - we discussed this a couple of years ago
[12:53:47] <alex_joni> we were probably right then
[12:53:52] <alex_joni> (lol)
[12:54:18] <SWPadnos> heh
[13:17:02] <lerman__> lerman__ is now known as lerman
[13:18:20] <alex_joni> nasty bug
[13:18:27] <alex_joni> jepler: nice fix
[13:50:44] <jepler> alex_joni: I'm glad I overcame my initial impulse to just ignore the report
[13:52:09] <alex_joni> how can you ignore your own report :)
[13:52:24] <jepler> the one on cnczone, I mean
[13:52:29] <alex_joni> the least you can do is argue with yourself a couple times ..
[13:52:34] <alex_joni> ahh.. that changes things
[13:52:47] <jepler> the sf report is pretty clear and hard to argue with
[13:53:53] <alex_joni> meh.. travelling again tomorrow
[13:54:48] <jepler> alex_joni: when was the last time you got a week at home?
[13:55:01] <jepler> I'm about to travel again but it's another vacation so I'm not complaining :)
[13:58:41] <alex_joni> hmm.. I'm not so sure I remember atm ;)
[13:58:46] <alex_joni> although I can't complain either..
[13:59:04] <alex_joni> last week was vacation, the week before was an exhibition (not much work..)
[13:59:37] <jepler> any idea whether you'll be around on the weekend of the 19th to work on a 2.2.6 release?
[13:59:51] <alex_joni> so far it looks like it
[13:59:57] <jepler> great
[14:00:16] <alex_joni> hope it doesn't change .. :)
[14:00:29] <jepler> I have an i386/8.04 machine now so I could build everything
[14:00:45] <jepler> but your assistance is so valuable
[14:00:59] <jepler> (i386 packages, website, sf, etc)
[14:01:57] <alex_joni> I need to do lots of IT stuff this weekend in our company
[14:02:05] <alex_joni> change a couple servers/racks, etc
[14:02:19] <jepler> oh what fun
[14:04:10] <jepler> I keep putting off upgrading Ingrid's office to 8.04 -- it's just 4 machines but I'm sure it'll eat up an entire weekend and there'll still be an emergency the next day
[14:04:13] <jepler> er, week
[14:04:53] <cradek> bill ran the in-place update on his laptop and reports that it worked perfectly
[14:04:56] <alex_joni> heh, yeah I know how that goes
[14:05:09] <alex_joni> cradek: oh great, maybe he wants to do a couple more
[14:05:11] <alex_joni> :P
[14:05:30] <jepler> cradek: I'm replacing the PCs at the same time or I'd be tempted to do that.
[14:05:40] <alex_joni> someone here should probably try an 6.06 update to 8.04 (the emc version I mean..)
[14:05:45] <alex_joni> and see how that goes
[14:10:02] <cradek> jepler: ouch
[14:15:25] <skunkworks_> jepler: thanks for looking at that bug.
[19:54:02] <cradek> we need wrapped rotaries ... too bad the usual way seems to suck so bad
[19:54:43] <jepler> because the hal motor position is still big after you hit the home button, I think things will still start to suck at +10000 revolutions
[19:55:06] <cradek> oh, hm
[19:56:39] <jepler> (at that position you have a precision of about 1/4 degree)
[20:01:38] <SWPadnos> I was just thinking that some HAL components should have a "zero" input
[20:01:47] <SWPadnos> like stepgen, for example
[20:02:49] <jepler> it should probably have a 'reset' input like encoder does
[20:03:14] <jepler> not sure how'd you use it from homing though
[20:03:28] <jepler> or whatever the name is for this purpose
[20:03:43] <SWPadnos> yeah - I'm not sure
[20:04:15] <SWPadnos> it seems that there should be a way (in HAL) of resetting any positioning components, which encoder and stepgen are
[20:04:38] <SWPadnos> PID is also, but it would "automatically" reset if both the command and feedback would reset at the same time
[22:02:05] <BigJohnT> * BigJohnT is off to the house, see you guys later
