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