Applying acceleration to MPG Target? Is this possible?

[mmurray70]

Hi Tom do you think theres anyway we could modify the MPG program so that the target accelerated smoothly instead of moving in 0.010" steps?

Im fairly pleased with my MPG program but I do alot of manual squaring blocks and I still get a very slight pulsing noise on 0.010 increments. This is a fairly minor detail i know, but i love to have things perfect and I've spend hours and hours trying to chase away this last little bit of noise but always seem to come to a dead end. Been picking at this off and on for months.

The last thing ive been doing is trying to do is break the move in half (0.005 move) and apply the second 0.005 move at estimated midpoint based on time between changes. Its getting a little complicated and thought I just ask if you think there might be an easier soloution. If we could accelerate the target smoothly without steps, or with smaller steps somehow i bet it would work awesome.

Similar Threads:

• Target practice ?
• Applying Comp. in G91

[samco]

Linuxcnc uses an integer low pass filter to help this problem.

ILOWPASS

Sam

[mmurray70]

Thats interesting Sam, I wish i had slightly more smoothing somehow.

Tom, I may have found part of the reason im struggling with this. Seems like my MPG encoder phases are not exactly 90 degrees apart. I had my init file print the time between changes and while turning at a constant speed it is constantly returning a high and low repeating pattern. In other words when turning at constant speed im getting two close pulses, then a pause, then two close pulses and so on. So in reality instead of doing 0.010 steps, its more like 0.020 steps. Maybe not a full 0.020 but you see what im saying.

I separated the Target variable tonight into two variables tonight. Target now records MPG requested position, and a "SmoothTarget" is used for the actual movements. I tried a few different ways of getting SmoothTarget to gradually take on the value of Target but another dead end. No improvement in performance, probably made things worse. Any suggestions?

[TomKerekes]

Hi samco,

Thanks! But that should actually be what we are already doing if I understand it correctly. The MPG code normally uses the MoveExp(axis, position, tau) command which is an exponential movement to the specified target with a specified time constant tau. In your experience is the LinuxCNC MPG motion completely smooth for big steps?

Hi mmurray,

Hmmm interesting question. It seems to me the fundamental problem is that it is impossible to know ahead of time what the operator is going to do. The operator first tells us to move only 0.010 so the motion proceeds based on that. Then the operator may or may not at some random time commands to move 0.020 instead (or back to 0). Its hard to be responsive to these changes without introducing some Jerk.

With the Lowpass/MoveExp approach the velocity will attempt to change instantly to be proportional to the new distance to the target. MoveExp is smart enough to gradually ramp the velocity to the desired new velocity based on the Acceleration Limit set for the axis. But that still results in infinite Jerk. We might try cascading low pass filters. Each one will smooth the next derivative. So:

No filters: Step change in Position - Infinite Velocity, Acceleration, Jerk
1 Filter - Continuous Position - Step Change in Velocity - Infinite Acceleration, Jerk (MoveExp what we have now)
2 Filters - Continuous Position and Velocity - Step Change in Acceleration - Infinite Jerk
3 Filters - Continuous Position, Velocity, and Acceleration - Step Change in Jerk (Finite)

So adding 2 more filters would be needed to limit Jerk. Unfortunately each filter will add lag and make the MPG less responsive.

Here is an Excel Simulation showing an example of 2 steps run through 3 filters. Each Filter was set at Tau = 20milliseconds. The original and each Filter output is plotted. Notice each is successively smoother but has more lag.


This plot is the Acceleration that occurs after each filter. The Brown is what we have now with an infinite acceleration spike. The MoveExp will limit it to the max allowed for the axis, but will still be a fairly large shock.

Adding one more filter gives the Gray Plot that looks much better, but still has a step change in acceleration (infinite Jerk).

Finally the third Yellow plot has continuous acceleration and so finite Jerk


The two additional Filters can be implemented as shown below. Target1 is now like the original Target, Target2 is that filtered, and Target is that filtered and sent to MoveExp:

		Target1 += Change1 * Factor;
		Target2 = Target2 * K1 + Target1 * K1M;
		Target  = Target  * K2 + Target2 * K2M;
		MoveExp(Axis,Target,TAU);  // note: contains a WaitNextTimeSlice

The K1 and KM1 constant coefficients combine like 99% of the previous filtered value and 1% of new value to do the low pass filtering (smoothing). Those need to be computed based on the sample rate and desired time constant (Tau).

		K1 = exp(-2*TIMEBASE/TAU1);  // filter coefficients
		K2 = exp(-2*TIMEBASE/TAU2);
		K1M = 1.0 - K1;
		K2M = 1.0 - K2;

And all the filters need to be initialized when motion begins.

I've attached the original MPGServiceSmoothHardwareEnc.c modified to include the two new filters - untested. I'm not sure what version/method you have been using.

Please give it a try when you have time. You might try adjusting the 3 Tau values to find a balance between smoothness and responsiveness/lag.

Regards

[mmurray70]

Tom, you are amazing! I should have asked for help sooner. I used your code with a few changes and have it working awesome now. No pulsing at all now and Tau values can be made super small which gives an instant response! This is by far better then any of the other MPG programs.

The changes I had to make were: Im not using hardware encoder so i changed it to suit the normal mpg program. K1M,K2M are not declared. And I didnt try it exactly as you had it, but im pretty sure it wouldnt work the way it was as the new target would only be calculated if there was a change, and i believe it needs to be constantly recalculated. So i changed this code:

if (Change1) // did we move?
	{
		if (!InMotion) Target = Target1 = Target2 = chan[Axis].Dest;
		Target1 += Change1 * Factor;
		Target2 = Target2 * K1 + Target1 * K1M;
		Target  = Target  * K2 + Target2 * K2M;
		MoveExp(Axis,Target,TAU);  // note: contains a WaitNextTimeSlice
		LastChangeTime = Time_sec();
		InMotion=TRUE;
	}
	else
	{
		WaitNextTimeSlice();
	}

To this code:

if (Change1) // did we move?
		{						
			if (!InMotion) Target = Target1 = Target2 = chan[Axis].Dest;
			Target1 += Change1 * Factor;
			LastChangeTime = Time_sec();
			InMotion=TRUE;			
		}		

		if (InMotion) 							// If moving
		{		
			Target2 = Target2 * K1 + Target1 * K1M;
			Target  = Target  * K2 + Target2 * K2M;	
			MoveExp(Axis,Target,TAU); 

			CheckDistToStop(ch0);						// Check distance to stop from adjustsoftlimits.c
			CheckDistToStop(ch1);						// Check distance to stop from adjustsoftlimits.c
			CheckDistToStop(ch2);						// Check distance to stop from adjustsoftlimits.c
		}
		else
		{
		WaitNextTimeSlice();
		}

Everything appears to be working great now. I left my checks to stop in there, not sure if they are needed in the latest version or not, but its still working well for me so dont want to risk changing it. I attached the code im using, but my machine uses weird switches and ballscrews so everything couldn't be defined at top of program. Might not be the best program to use as an example. Would be nice for new users to have two new generic MPG programs (for hardware encoder and without) that uses these new filters, really works alot better. Thanks again for all the help!

[TomKerekes]

HI mmurray,

Thanks for making my day and fixing my bugs. Glad it is working well.

Regards

[mmurray70]

Just a follow up, I've used my machine several times since changing to these filters and everything works perfect. No surprises. Super smooth and instant response with these filters now. Huge improvement from all the other mpg programs.

I updated the origional code Tom posted with the changes I made and am attaching this file. I havent tested this exact file as my MPG does not use a hardware encoder, but it should be good. If anybody tries this please confirm it works ok with no errors.