Set up using AMC AB15A100 drives, brushed DC motor Prototrak Plus with Encoders

Todd, Many thanks! The attached pic is best today, channel 2 is 10m/div all others are 200m/div. Is the slope of the starting ramp angle, ok. When will it be time to re-set .ini file, the MAX_Acceleration or something like that?

Many thanks!
 

FF1 doesn't really work like that. Once you find the right amount for how your drive/motor is calibrated adding more will be detrimental.

Maybe a description of what the different PID constants do.
FF1, is simply telling the drive this is what speed we are trying to command and the FF1 term is just a scaling factor of that command. So if a 2v analog command makes your motor move the machine at 60ipm and Linuxcnc's PID output scale is such that 1v=15ipm (10v=150ipm) then your FF1 should be set to =2.0. If on the other hand Linuxcnc's output scale is so 1v=60ipm, then the right setting for FF1=0.5. This way when a move is commanded the PID doesn't have to only rely on the somewhat unstable other PID terms to get the job done. In a perfect world FF1 would be all you would need. But if for what ever reason a move doesn't move the exact speed commanded (which is always the case) the other PID terms correct for it.

The P term is an amount multiplied times the error and the product of that is added to the output command. So if there is a big error the P will add a large amount to the output command. If the error is small it will only add a little.

I is similar to P but adds in a time factor, so if there has been an error for a while and P just isn't getting it done, I adds in the amount of time times the error and I term. This sounds great but can wind up and cause huge overshoots and instability. Generally I isn't very helpful in a position loop (the I and D in the servo drive usually have this covered.)

D adds an amount that is the D term multiplied by the derivitive of the error. The end result is that D kind of works like a shock absorber and tries to slow down changes in the error. (generally it isn't real helpful unless things are tuned close to right. P and D are kind of in a balancing act if one or the other are too far out of their respective ranges the result is instability. For example this much D only works well with that much P. Increasing one or the other can cause things to fall apart. Generally higher D can allow higher P, the trick is finding the balance and that can be very difficult, the higher you go the smaller the window of what works becomes.

I like to tune FF1 by first adding enough P to get some stable movement that is about 60-90% of the commanded move (with FF1=0.) Then add FF1 enough FF1 to get the cruse speed nearly perfect (as close as you can get it.) After setting the right FF1 you should not need to readjust the FF1 again. Then adjust FF2 to improve the acceleration phase.

Once those are set, increase the P as much as you can without causing instability. Increasing P will make the axis stiffer and rigid and resistant to outside forces.

Todd, thanks!! After review of your last post, I followed closely your suggestion, this trace is best so far. I was not able to get the "cruse" completely flat. Tried using some FF2, to help at the start. The "x" axes has a very small amount of movement to the left, about a 1/8 turn, every 2 or 3 seconds.

Many thanks!
 

I think you could try increasing the acceleration in the ini file and see if it can keep up. What was it set to before we slowed it down?

FF1 is probably pretty close to right maybe a touch more. FF2 may need some more fine tuning, but it is hard to see right now. Time to add more P and try to minimize the following errors.

Instead of looking at the pin "axis.0.f-error" use "pid.x.error" and increase the gain on the error trace so we can see it better. You should be able to get the error so it stays less than 0.001" or better (0.0002" would be doing really good but could be possible).

Todd, many thanks! I tried some I, D,

If the X axis is drifting with any amount of P active, that would be indicative of there being a real problem with your encoder signal. If it is only drifting when P=0 that would be considered normal and nothing to worry about.

While the X motor is turning, is the DRO in Linuxcnc moving? If the motor is moving, but the DRO is not then that is a big problem. Either electrical noise is causing false encoder counts, or hiding true counts. This must be corrected.

Yes, that last trace looks a lot better. Increase the gain on the error trace so we can see the error more clearly. (Also switch from axis.0.f-error to pid.x.error.) You are to the point where looking at the error is your primary feedback for what adjustments need to be made. but you need to increase the gain scale significantly to see it. (Try 1m/div or 500u/div.)

Todd, thanks!! The attached pic has channel 2 is "pid.x.error" with units set to 1m/div, all other channels units are 200m/div. As you see I have moved the start/datum line low on screen, but next units were to tall for screen.

Thanks!

Edit: The small movement of the motor is .005" on the dial, it happens at the end of trace, seems to be searching, maybe, if I F2 it will stop & not start by its self.
The channel 2 trace, pid.x.error, this trace I am to flatten it out to match the other traces? The .ini file is "max_acceleration" set to 1.2.

Many thanks!
 

Todd, Thanks! The attached pic has the small motor motion trace, when the small movement was happing, I pushed the start button, will this help to understand why? This trace channel 3 & 4 units are 20m/div; channel 1, 10 p/div; channel 2, 500u/div. I try to fill screen with traces, channel 1 has very low or no trace.

Many thanks!

That looks really weird. I have no clue what is going on there.

Can you add another channel to halscope monitoring the pin "hm2_5i25.0.7i77.0.1.analogout0"?

It almost looks like somehow a ghost of the siggen test is still sending it's signal to the analog output. But I don't see how that could be possible.