tuning question.. :) so doing it the old fashioned way - I increased P until I get an oscillation. now at this point the following error is around .004. I increase D until the oscillation goes away. Now the following error is still around .004 - just looks like a smooth ramp up to .004 error than a ramp down. So.
I then am able to increase P. This actually starts to move the error to 0 and make the system stiffer.
I can increase the P to the point that the error while moving is at 0 with a little spike at the beginning and the end. Now if I increase I to help "stopping accurately" - Adding I seems to shift the whole errror up or down again.
[01:22:13] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/following.png
but what helps the stopping? see how 100ipm - which is the center section is right at 0 - but the stopped (both sides) seeme to wonder around a few tenths up or down.
still pretty good I think
it defiantly is better than the zn - as the zn when you would try to spin it one way - it would wind up and over shoot the other way. This feels pretty dead if that makes sense.
odd though as P=3850 I=3 D=21 and ff2 = .03
can you explain the plot?
which part is stopped and where is zero?
stopped is on each end. 100ipm is in the middle. accel and decel is the transition
is zero that line at the top?
that seems strange if so
zero is the line right in the middle of the scope screen.
so it has more error when stopped than when moving?
it wonders around +/- .0003
try increasing I (a lot) and see if you can get it to go to zero when stopped
I though so too
also, it's oscillating when stopped, maybe you have too much P
try using I to make it stiff instead of only P
If I increase I a lot - it start shifting the error while moving up or down.
* skunkworks is still learning
it's not an exact science (and I'm sure not an expert either)
if I decrease P the error at 100ipm increases. - moving up or down. like I am adding a dc offset. which doesn't make sense.
will adding I move it back to 0 error?
I guess I can try it. :)
yes I will reduce any long term errors
also, FF1 will move a steady state error that is proportional to the velocity
(looks like that's what you have)
so, might want to try FF1
ah - so it is like a dc offset - that is what I was thinking.
Yah - but steady state is +/- .0003 - it doesn't stay one side or the other of 0
depending on how it stopped
yeah I bet you'll have to nuke that with lots of I. I forgot that you have error when stopped, not when moving
What is that 100u/division - 100usec? Could that oscillation be the pwm pulses?
pwn is 19.mumble khz
when I start adding I - I get a odd overshoot at the start and the end and a diagonal-like line connecting them. Plus I get the wind up again.
I suck at this :)
I just hope it is easier with a linear mass attached ;)
btw - adding ff2 sure makes it sqeek
I don't think I can explain it better than that. it adds a squeaking sound to the motion
Is changing D like adjusting scope probe compensation, fixing over/undershoot?
that is the way I understand it - and how it looks
cradek: do you have your lathe hooked up?
thanks. looking forward to the day I can spend time playing with tuning.
skunkworks: except for a few wires
cradek: I was wondering how yours acted trying to spin the motor shaft.. Does it go past the starting point then return to the starting point?
(after you let go)
I can only describe I as adding "wind up"
yes if you hold it off the goal, I winds up so it pushes harder and harder, and if you suddenly let go it will overshoot briefly
so that is normal
yes that's how I works
(or what you want)
I think mine would settle back to the goal in 1/4 to 1/2 second
ok. I am sure it is a totally differnt beast when you have linear mass and friction.
among other things :)
yeah I bet it's much worse :-)
No - don't say that...
if your mass is balanced it seems like it's a nearly ideal system to tune...
you mean a flywheel?
don't you think?
no uneven drag of any kind
just about to call it a night
cradek: but no friction.. or dampening.
things are good here
* skunkworks is having fun
things are hot and humid here
well, not here in the basement, but here outside
just got back from an attempted sail - its hard to sail with no wind
now I have a 100ipm error of .0008 with a high I. I don't know what to adjust now to bring that down.
my stopped error is now very low
skunkworks, how high is P? You have any FF1?
no ff1 - P is 1050 right now
is this on the still on the pluto board?
(just a flywheel on the servo)
I'm pretty sure cradek needed FF1 and some FF2 to get things tight
still the error at 100ipm seems to be a steady .0008. I can't seem to do anything with it..
whats your encoder resolution?
before I added I - i could zero out the error by adding D but now I cannot.
input scale is 60860
are these long or short 100ipm moves?
is the error pretty constant over the whole move?
but it goes up to .0008 and stays there.
hmm, I should elimitate errors that just stay there
I think there is a code in the PID to cap I when the PID output is saturated
are you sure your not saturating?
this keeps I from winding up too much
yes - pid stays at about .3 of 26
does more I change anything?
makes it a bit more sqirley but doesn't change the 100ipm error
* skunkworks just doubled it.
* skunkworks is banging his head against the wall
I am sure I am doing something stupid.
I don't know the pluto setup very well, so I'm not sure what to suggest
did you try changing the servo thread rate?
yes - I lowered it to .5ms
what was the effect?
it lowered the following error by half if I remember right.
but I was still able to zero it out before I added I
well, for what it's worth, I had to run .2ms on my machine to get acceptable results
I don't understand how adding I could cause this, if anything, it should have helped
odd. it may just be me.
what do you mean?
that I don't know what I am doing
I think your results are pretty good for the HW you are using, I'm not sure anyone else has produced better results
* skunkworks was hoping for better. like you say - shouldn't it be correcting the steady state error to 0
I should do that
but you say increasing I isn't helping
nope - I get a nice flat line (with a bit of noise) right around .0008
seems like you have the encoder resolution to do better
no sign of decreasing.
can you increase the servo rate even more?
I found my error on short moves was due to overshoot, not lag
I don't now how much more I can - it is a printer port (epp)
a faster servo rate really helped with this
is your error lag or lead?
I don't know :)
EMC uses a trapezoidal velocity profile, so accel is bang/bang
real motors can't do this, so this leads to some error on accel/decel
having limited jerk would allow the motors to track the profile better
hmmm - adding -1 ff0 seems to decrease it
what does ff0 do?
ff0 is position feedforward - surely not what you want
ff0 is 0th order, it acts like a spring
I don't really see when you would ever use ff0, unless you had a spring or similar kind of counter weight
(I can actually zero it with ff0) ;)
what is your machine setup like?
it is the pluto_lathe in inches
I have to go to bed
maybe you have some type of offset issue and the move is too short for I to overcome it
night guys. I will try some more tomorrow
ff0 may just be acting like an offset if you are making the moves in the same place
that was abrupt - I bet there was an "outside force" at work there
yeah, know the feeling
does anyone know what that small lathe was that john prentice had in that video clip?
was it a modified myford?
cradek: are you still awake?
well, I shouldn't be
we found a large soft lump on one of our cats chest. have you run across something similar?
sorry - bit off topic.
something under the skin?
cradek: he has been a bit under the weather for a few days
like an inch or bigger
hmm, that's big
no I haven't seen that
ok - going to the vet anyways tomorrow. thanks
I've seen smaller lumps, one the vet cut out with ... a hole cutter type thing
ok - this is berry - he has not wanted to go out for a few days - thought it was odd.
hope it's nothing. tell him hi for me and to get better
maybe he's just smart - it's pretty hot outside lately.
:) I hope so..
oh well - enough worrying. time to get some sleep. Thanks agian.
following error wouldn't be different between a jog and commanded motion - would it?
both jog and commanded motion should follow a similar motion profile with the same acceleration, but they might have different max velocities
darn. Still trying to figure out why I get a .0008 following error during a jog that doesn't decrease.
grasping at staws.
doesn't occur during an X1 move with the same F?
I can get the 100ipm following error to 0 if I am just doing P and D but once I add I then the error goes up to .0008 and stays there. nothing - other than ff0 seems to effect it.
jepler: have not tested that yet. That is why I was asking this morning.
I am really still learning.
jepler: side question. Have you ever found a large soft lump on any of your kitties?
I saw you asking last night -- I'd head straight to the vet too, in your place
well he goes in at 8:30 this morning
is the .0008 error an overshoot or an undershoot? or is it always to the same side e.g., +X regardless of the move direction?
I am not 100% sure.. I will do more investigating tonight. (I was only scoping ferror) Even the autotune has the error.
I was looking thru the hal file for any oddness and made sure there wasn't any backlash comp - not that it should do that.
I am pretty sure if I decreased/increased the servo period it would also decrease/increase the following error.
what makes you say that?
when I was first playing with it - the folloing error at 100ipm was halfed when I went from a period of 1ms to .5ms
I suppose none of this is making sense ;)
I don't think it would do the same to the steady-state error
incidentally, .0008 is the distance travelled in .5ms at 100ipm
that makes sense - I was actually planning to do that math today.. thansk
so what does that mean?
imagine you're in the cruise phase of one of these 100ipm moves, so you are going along at .0008 in/.5ms
so at time T, emc commands 1 inch and at time T+.5ms, emc commands 1.0008 inch
but at T+.5ms the feedback it reads is basically the result of the movement commanded at time T
perhaps getting a following error equal to distance moved per servo cycle is "perfect" tuning
So I should not worry about it? and it really isn't an issue? I mean - if I am worrying about .0008 at 100ipm you should call me les?
or perhaps you have your servo thread wired wrong -- make sure pluto-servo.read is at the beginning and pluto-servo.write is at the end
well no - it isn't
what's the order you have now?
let me paste bin it.
[12:52:16] <skunkworks> http://pastebin.ca/591832
there are ddts and such below the write
if that matters
no I don't think so -- the important order is read .. motion .. pid .. write
I don't think the ddts are for anything but scoping the velocity and so forth
what's the "limit1" for?
this is the lathe_pluto hal file.. it is for the spindle stuff
jepler: I bet what you said is why ff1=1 works
cradek: skunkworks said he was using ff0 though
well he's making a mistake :-)
right - that was right at the end of the night. I was adding negative ff0 and it was moving the error at 100ipm down to 0
ff0 might appear to fix it at one spot
ff1 should fix it everywhere
but I never actually jogged it in the opposite direction either.
maybe it would have doubled it in the opposite dir
I tried ff1 and it didn't seem to be doing anything. but that is just my recolection
ff0 is relative to the position, so if you're at 10 (inches) you'll have 10x the "correction" as at 1
ff1 should be able to fix steady state error during a move (velocity proportional). It won't fix steady error at a stop, which is what you started with
I think ff1=1 works (when pid scaling is right) for exactly the reason jepler said
right - well - I can try to play with ff1 again tonight.
iirc I'm using ff1=1 on the lathe
yes you are
gotta run... back later
adding a bunch of I seemed to fix the error at stop
you mean, when using ff0 you also had to increase "I" a lot to get rid of errors while not moving?
sorry - no
before I was messing with any of the ff's
but adding lots of I caused the 100ipm error to go to .0008
before I it would drift between +/- .0003 when stopped.
hey jeff, already at work?
yep -- it's nearly 9AM
right.. I'm still in bed at that hour *blush*
in theory, I start work at 7AM
in practice, I usually make it in before 7:30
anyways.. I just came back from lunch .. we had a small celebration today
17 years since the company started
ah .. congrats
alex_joni: how long have you been there?
hmm.. officially, about 7 years or so
but unofficially longer
it's my dads company.. so I was pretty often here to help out
IT stuff back then
nowadays I keep forgetting what I do :P
* skunkworks turned 34 today.
still young.. :)
although a bit older than me :P
* alex_joni turned 27 last month
I always forget that skunkworks is older than me
he sure doesn't sound like 34 usually :P
;) I feel that I have not grown up yet
Well - berry has a fever - with is good as 'cancer' wouldn't normally cause a fever. But the vet said the lump 'feels' odd and as berry is an fiv kitty they are going to run a some tests.
yuck, I hate tests.
so do cats
berry is pretty layed back. He wonders around the office rolling onto his back and sniffing..
'show my belly barron' is one of his many nick names.. That might be tmi
la la la la la la la la - I'm not listening
there is 'Barron Von Boscowitz' 'officer Howen McDowel' and 'Jasmin' - she's a party girl.
they when to extract fluid from the lump and puss came out. that is good.
so he is going into surgery to remove it.
puss in boots?
* alex_joni wondered that too
hmmm. it may be time for a mozilla restart - it's getting slow, and it's using ~500M of ram
I wonder if there's a correllation there
Na - it is all in your head
must - bookmark - pages
umm - that doesn't look good. brb seems a bit long..
well - that took a bit :)
indeed. it didn't go as planned
I decided to close Acrobat, and saw tha WinAmp was the only app still running, so I figured I'd log out and back in
that's when the computer rebooted
this is a relatively slow machine, so I decided to do some errands while it was counting RAM :)
having spent way too long on it -- gtk/gnome autogenerated API documentation is really not very good documentation -- I've established that using an antialiased gnome canvas for the display part of halscope makes performance WAY too low
and there are terrible rendering bugs in the gnome canvas anyway
(which I can't get to happen again to get a screenshot :()
screenshot while it's behaving: http://emergent.unpy.net/files/sandbox/halscope-gnome-aa.png
jepler: I have a question on roll.. why does it pre-fetch - then roll for a while - then trigger. Do I have a setting wrong?
skunkworks: no, that's how it ends up working. usually you'll want to set the capture position to the very end and set the trigger so that it will never trigger
ah - ok.
SWPadnos_ is now known as SWPadnos
jepler: wow, the AA looks very nice
yeah it would be nice if the performance didn't suffer
(and it didn't require a whole bunch more libraries than emc does already!)
(though maybe they're all required by libgnomeprint already)
we already use them all, I guess
they're already present on an ubuntu system, that's for sure
and we already pull in many of them for print in classicladder
jmkasunich: I'm trying to use ppmc to read a jogwheel on stuart's machine, but the ppmc doesn't let you turn off x4 mode. it looks messy to add. any thoughts about how to do it well?
or, should I make a div or divmod component instead