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