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

Todd, Thanks! The attached pics are of the low "D" at .1 & .2. The spike is larger, the best may have been last post. Units on ch2 are 200u/div. in the newer pics, there maybe a pic with the 500u/div in the older set, so beware.

Many thanks.

Edit: Over the weekend I can work on the "Y" axes tuning, or should I revisit this "X" axes & find-tune the x traces? Leave FF1 set (to what value?) & only use the "P" & some "D", to tune trace?

Many thanks!
 

Todd, Thanks! This is a trace with units set; channel 1 & 4 =200m/div: channel 3 & 5 =500m/div & channel 2 shows on screen. This keeps FF1 = 1.0, the trace does not come down to the "zero" datum, but close.

All suggestions welcomed, many thanks!

I don't understand why you changed FF1 back to 1?

If you had FF1 set right the peak errors would be less than 0.001, but with FF1=1 the peak error is nearly 0.0025.

I think some D would also be beneficial.

Todd, thank you! Over the weekend I worked both axes, set MAX_Acceleration on "Y" from 10.0 to 1.2, to match "X" axes. I have no excuse for FF1, as you see the attached pic I have tweaked again to keep ch 2 (pid.x.error, units are 200u/div!) centered on zero. How do you reference the trace and figure the "peak error" value?

Many thanks!

You should try increasing the acceleration a bit. Try 2 or 2.5 instead of 1.2. You should at least explore what the acceleration limit is now that it is mostly tuned.

In Hal scope if you click on the trace you want to find the peak of, (in this case the blue pid.x.error). Then after you've clicked on it, when you move the mouse left or right you can see a small dot that moves with the mouse on the trace. Move your mouse so the dot is on the place where you want to read the value and at the bottom of the Halscpe screen there will be a line of number that will look something like.The number in parenthesis following the f is the distance in seconds of the sample point highlighted by the dot on the screen from the trigger event. The number after the equal sign is the value of the sampled hal pin at that point in time. (So if you are highlighting the peak that is the peak value.) And the number in parenthesis with the ddt is the slope or rate of change at that point on the trace (the time derivative.)

But I was just looking at the gain scale and counting hash lines to estimate the peak value from your image. In the last trace you posted 200u is the error scale. 200u = 0.0002. The peak is about 3.5 lines up so 3.5 * 0.0002 = 0.0007 inches for your peak error.

Todd, thanks! I changed the .ini file from 1.2 to 2.5 on "x" axes. Should I try more acceleration? I don't see much change, all settings are identical. I used your suggestion to move pointer to get measurement, (was not able to get pic with mouse pointing at the hi point in the trace, but this is the trace. Even at .0007" is total of .0015" deviation (hi to low) in the part.Many thanks!Edit: .ini file did not save, redo.

Todd, Thanks! The pointer at the top of the 1st spike in the last trace (units ch2, 500u/div) posted, reads or goes like this: f (.384)=.00263 (.00682).
I see the difference, it like 2x, should I try other settings?

Many thanks!

A little FF2 can help with the error spike at the beginning of the acceleration a bit. And I thought that P=600 didn't have too much oscillation and overall smaller error.

Todd, thanks, the motors at P=800 are not noisy. This is trace at P 800 & 600, on the P600 trace if I use too much FF2 the 1st part of ch2 (pid.x.error) trace will go below the "zero" line. This trace is on the low side, to keep it centered all the way vs. 1st part is under "zero" & then goes to the + side.
many thanks!

Ok, now 0.14 is a little bit too much FF2. See how almost the entire acceleration phase has a negative error (below zero). Also a little more FF1 might be needed because most of the cruse has a positive error. But otherwise the P=800 looks like a nice improvement.

And setting the deadband = 0.00005 (about 1.5 encoder counts) would be a good idea.