What represents, or what should I expect from, a well tuned servo system?

Hi,
I have a 7i77 based system that has Granite Devices VSD-E amplifiers on it. The mill itself is a Hurco KMB-1.

I have had a devil of a time getting this thing tuned. I think my VSD-E tuning is OK. There isn't a facility in the GD software to do massive amounts of jogging to see how things are doing, but I think I'm OK there (although, I sure wish some in the South Bay Area could look and tell me if it is good! Takers?).

My problem is that I can't really get my system to not drift when I'm trying to tune the LinuxCNC implementation. I've disabled my X while I work on my Y. It basically just drifts about 0.1" in 35 seconds or so. In my machine view, my Z is better but I'm still not sure it is great. Instead of a constant drift, it "hovers" around a value and that may be acceptable (?). For instance, as I'm looking at it right now, it goes from 0.3969 to 0.3977, back and forth, endlessly. Although better than my constantly drifting Y (and X, if I had it enabled), I was expecting a rock hard value or possibly an oscillation around, say 0.0001 or so (these are all inches). Is that realistic? [on edit: regarding the Z axis, I changed my DEADBAND to 0.00002 and now it seems a be stable at the 0.0001" range]

If it helps, I've noticed that I need to introduce the following bias values into my HAL file:
X: BIAS = -0.0195325
Y: BIAS = 0.00975
Z: BIAS = 0.0684

Any ideas/help on identifying if this is a servo amplifier tuning or LinuxCNC tuning issue would be helpful and definitely appreciated!

Thanks.

Well, maybe that was kind of stupid! I had my DEADBAND at 5 because I thought that would help me tune better (pretty sure I read that somewhere). When I changed it to 0.00005, suddenly there is no more drift! That said, I'm not sure this is the way you tune your system. I get the feeling that I am not doing this correctly.

Have you read any of the tuning tutorials?
gnipsel.com/linuxcnc/tuning/servo.html

Hi Todd,
Indeed, I have. However, as with many things, the tutorials seem to give generalities that help once you have everything complete but leave questions when you are trying to go through the process. I'll give a few example. First, there isn't really an explanation of what is 'normal'. If I come up with really high values or really low values, I don't know if that is truly correct or because I've pushed an incorrect value one (or more) place that is causing the other values to be off. The multitude of different tuning parameters within the Granite is a perfect source to mess everything else up, for instance, if I did it wrong.

I don't regard any of this as rocket science. However, I fully recognize that my knowledge base is rather poor. I don't have any real experience to gain a feeling for what is right and what isn't.

Here is another thing that I'm seeing but that isn't covered in the tuning instructions... I've noticed that I can jog for a few inches at, say, speed X. Then, all of a sudden, my axis speeds up to speed 2X but is rough. It is kind of an oscillation every 0.1" or so; maybe a 'machine gun' type of sound/feel might be a better description. [edit: an interesting observation... If I stop the jog in the middle of machine gun mode, then the axis doesn't drift... hmmm]

And another experience... I can jog in the +Y direction, release the button and the axis stops. But if I jog in the -Y direction, then when I release the button, the axis continues to jog for another period of time. That period is very dependent upon how long I've held the jog button. Phrased differently, it is like the LinuxCNC counter is running at 2X the speed of the real axis. So, Linux CNC is at, say 50, but the actual position is 25; so, LinuxCNC continue to move the axis until it reaches 50. Where that disconnect comes from, or why it occurs in one direction only, however, is a complete mystery to me. To the best of my knowledge, none of that is covered in the tutorial.

I'll add another because I'm working with the machine right now... Using the tutorial as a reference, I'm trying to first find the proper P and FF1. I assume I want my I, D, FF0, and FF2 all to be 0 (didn't say, so just my assumption). Now, I've had my P at 0 and 200000 and nothing seems to really cause a difference in my jogging. I can't get an oscillation and the speed of the jog is about the same. The only thing that makes a big difference is FF1. If I set that high, the axis jogs like a bat out of hell, while 0 causes it to not move at all.

I have full faith that once this task is done, I'll go back and say, "you dummy... it was right here!" or "that was easy, you should have just adjusted the FF1." But reading a tutorial when you know little (which, ironically, is what tutorial are for in the first place) is sometimes less clear than we would have liked. Tutorials are tough things because, of course, the people that write them have already figured everything out. That, by the way, is not a slight on the author. It is a tough job. Been there, done that, myself.

Update on what I'm calling machine gun alley... I've setup a P, I, D of 500, 100, 0. Although machine gun sensations (MGS) happen all the time, I've noticed that they work in almost a moving band. That means, as I push the barrier of that band (say 3"), I can only move in reverse a maximum of the band width (3" in my example) before I get MGS again. I was wrong when I said that I didn't get this effect in both axis. I simply hadn't parameterized the experience well enough yet.

Another thing... And I suspect this is very significant... With the PID set as described, I can rapid jog into MGS land. When I release the jog button, however, Linuxcnc reverses the jog and calmly returns to a position somewhat back from where I had advanced and then is rock solid. I'm thinking that MGS is a result of my position getting so far ahead of the desired position that the axis does some funky oscillation. I don't know how Linuxcnc could be allowing the axis to move that far ahead of the desired position though.

I should also point out that I've tried to get this on HALSCOPE but haven't had much luck. The tuning tutorial shows HALSCOPE working with DC mode. However, this makes my position signals only visible within HALSCOPE in a very small range of physical movement. In fact, I can only get it while moving one direction and only for a very brief period of time. Frankly, I'm having trouble getting very meaningful data out of HALSCOPE, which is very unfortunate.

First, I would not use jogging to test tuning, it brings in another set of variables I would do manual moves via MDI

Second without halscope you really dont have much hope of tuning or getting help with tuning (or having the tuning tutorial make much sense)

If you use MDI moves its easier to keep the position trace on screen.
Also the position trace is not very important, the velocity and error traces are much more useful
and are 0 based.
If you want a position trace and its not convenient to move near 0 you can use halscopes offset option

another hint dont use any I or D at least with initial tuning

Cool. I'll give that a try. I must first determine how to use MDI to command the movement desired. I did a quick check and it looks like the easiest thing is to create two button that jog back and forth from one another's points. All of this does bring up one question off the top of my head, though.... If jogging isn't a good way to go (I'm assuming because the feeds are too high?) at what speed should I be configuring the axis move for my (new) MDI buttons? I can adjust it up or down with the override, I guess, but would you suggest something like 5IPM?

Incidentally, I did discover one thing during my initial tests... My Y axis index pulse must not be working. I should be going to the limit and then backing off to the index, but I just keep going and going (like the Energizer bunny). So, I have a gremlin to work out there. I looked for a pin or signal for the index pulse but only saw an 'enable'. That seemed a little odd to me but is not horrible for me to resolve. I can get out a logic probe. [edit: retract that... The index is working fine. The drift I had was hiding the fact that the back-off to the index was working just fine in reality. Whew! One thing solved!]

Halscope seemed to be more useful when I was tuning the Z axis. The Y is not going so well. I never see any oscillation at all, regardless of the speed.... But, hopefully your suggestion about using MDI will help there. Thank you.

Do you happen to have any ideas about the machine gun syndrome I was describing? I don't recall that on the Z axis. It is a little hard to describe in words. If it wasn't clear, I can scan/upload a drawing... The best way I can put it is that it is like a chip guard cover. There is a few inch movement where the guard doesn't move, but if you do move it, you obviously move the other end of the gap too. (geez, how do you describe that).... It is like the axis is physically moving faster than LinuxCNC believe it should. Strange.

Too high FF1 is a possible cause of major overshoot
I suspect you will have to post some halscope window captures
and your hal/ini files to determine exactly what is going wrong

Thanks.... I had been so preoccupied with things outside of the LinuxCNC UI that I didn't notice the MDI tab. I guess I can simply enter my command there. One negative, though, is that a G1 requires the axis to be homed. I can do that on my Y and Z but I've disabled my X so that I can work on getting one running at a time. I've considered removing any references to the X, but that seems like it is a good way to mess up my configurations. I guess I'll have to work with two un-tuned, live axis.

[edit: Yes, I see now that I don't need a button. The MDI tab has a nice history so I can simply go back and forth very easily. For my testing, I'm using [b]G1 F30 Y7[/b] and [b]G1 F30 Y7.5[/b], for the benefit of those reading this later. I dialed my X axis back so that it is probably horribly tuned, but it is stable so I don't have to monitor it. I hope to get some data to look at soon. Ironically, I need to figure out how to do a screen capture on a Linux box. LOL]

OK. I have been playing a little bit and I have realized something. I've seen this before but I am not sure how to make the setting for my initial tuning (that question in a bit). What I'm seeing is that my 'drift' isn't exactly ambiguous. In fact, If I have G commands that go back and forth between two endpoints that are 0.25" apart from one another, the axis will move almost completely towards one endpoint upon command and then remain solid. The other direction doesn't fare as well. In that case, the axis will go halfway to the point and then seemingly stop and drift. But it really is drifting to the other endpoint, and when it gets there (about a minute later), it is pretty solid.

This got me to thinking. I've seen some similar odd behavior that went away when I changed my DEADBAND to a small value (like 0.0002). But I recall reading that for tuning, I should have it set to something high, like 3. So, now I'm in a strange position. On the one side, it feels like I need the DEADBAND should be very tight, but that conflicts with people far more knowledgeable than myself.

If you can help me understand what I should do and where the error is in my thoughts, that would help a lot.