This Centroid setup is wrecking my machine!

[ashesman]

Part of the problem with your blue circle, is that Y is changing direction, so lash compensation is added to the move. That could account for the rapid accel/decel you are seeing at that point as the control tries to quickly remove the lash.

Yup, you are correct. Lash compensation is applied. It is around 100 steps in this case. I have tried adjusting lash accel up and down with no real change observed. It is applied at 1/8 the feed rate. I dont think it is not significant here compared to the accel requested by the g code movements.

[cncsnw]

I must be missing something. I see a Y axis reversal in the red-circled section, but not in the blue-circled section.

I fear that this inquiry is getting a little too far off in the weeds, when it sounds like you have found one or more straightforward problems with acceleration ramps when Smoothing is applied.

If you see measurable pauses in the acceleration of a one-axis move, then there is a bug that needs to be fixed.

If you see erratic acceleration in the transition of one diagonal line (two-axis move) to another diagonal line with the same direction, but a different feedrate; then there is a bug that needs to be fixed.

If the problem is demonstrable with straight-line moves, then there is no reason to muddy the waters talking about corners, curves, and short-vector programs.

Can you trim your test programs down to 20 lines or less each, that still exhibit the problem?

[ashesman]

I must be missing something. I see a Y axis reversal in the red-circled section, but not in the blue-circled section.

I am looking at the X axis only here. The red circle shows direction reversal. The blue shows almost no direction change but a big acceleration change

Can you trim your test programs down to 20 lines or less each, that still exhibit the problem?

I thought I had drilled it down to a handful of lines in the picture above. Easy enough to find those lines in the gcode. But I suppose I could strip the file out more. Might get some time on it over the weekend.

[cnckeith]

these are known good drives that are compatible with Centroid Hardware and software.
we can not reproduce this error on our deltas in our shop. i'll have the guys post our plots.
your issue looks like the drive is not programmed/tuned (delta tune and centroid delay tune) correctly.

did you reset the drive to factory defaults BEFORE setting the Centroid provided Delta parameters?

SOP on solving issues like this, to get to a baseline.

1.) reset the drive to factory defaults
2.) set the Delta parameters for use with Centroid using the delta software, do not copy over a .par file.
3.) Tune axis on the Delta software
4.) Delay tune on the Centroid software.

run your test.

[ashesman]

these are known good drives that are compatible with Centroid Hardware and software.
we can not reproduce this error on our deltas in our shop. i'll have the guys post our plots.
your issue looks like the drive is not programmed/tuned (delta tune and centroid delay tune) correctly.

I am not suggesting there is an issue with the drives or compatibility. The drives are working exceptionally well. They track perfectly. They are powerful and the moving part of the machine is light so they can respond to requested changes very quickly.

The part I am questioning is why the controller has steps in its pulse output when smoothing is on, and why it feels the need to accelerate and decelerate so hard between g code segments where minimal velocity change is required.

When the drives are driven by smooth control pulses the machine is amazing. But when they are driven by sharply varying control signals, well they just do what they are told.

I could dial everything back slow and run it like an old bridge port conversion. But I bought a controller that was supposed to be able to do high speed multi axis machining and I put it on a machine proven to be capable of it. Now I want to see those results. I still haven't matched the performance of the 30 year old mazak controller yet. I am getting close now. But I am not a close enough is good enough sort of person!

[cnckeith]

these are known good drives that are compatible with Centroid Hardware and software.
we can not reproduce this error on our deltas in our shop. i'll have the guys post our plots.
your issue looks like the drive is not programmed/tuned (delta tune and centroid delay tune) correctly.

I am not suggesting there is an issue with the drives or compatibility. The drives are working exceptionally well. They track perfectly. They are powerful and the moving part of the machine is light so they can respond to requested changes very quickly.

The part I am questioning is why the controller has steps in its pulse output when smoothing is on, and why it feels the need to accelerate and decelerate so hard between g code segments where minimal velocity change is required.

When the drives are driven by smooth control pulses the machine is amazing. But when they are driven by sharply varying control signals, well they just do what they are told.

I could dial everything back slow and run it like an old bridge port conversion. But I bought a controller that was supposed to be able to do high speed multi axis machining and I put it on a machine proven to be capable of it. Now I want to see those results. I still haven't matched the performance of the 30 year old mazak controller yet. I am getting close now. But I am not a close enough is good enough sort of person!

did you reset the drive to factory defaults BEFORE setting the Centroid provided Delta parameters?

[ashesman]

did you reset the drive to factory defaults BEFORE setting the Centroid provided Delta parameters?

The drives were brand new when I put the parameters in. I also checked them again the other day against the application note. The drive parameter file is attached in a previous post.

The drives are working perfectly IMO.

[adenchik]

Here's the plots Keith was referring to above.

[ashesman]

Here's the plots Keith was referring to above.

Not sure what the steps per revolution are on that machine so hard to compare. The acceleration period is over 200ms, so pretty gentle.

My drives look exactly like that if I do a step with the acceleration slowed right down.

I have had to take some time away from this project to do other stuff for a while. I have another controller to try on it but not sure if I have the patience to muck around wiring it up. I need to confirm if the acceleration profile can be adjusted on it before I waste my time.

I am still convinced there is something gammy going on with the centroid controller between g code transitions and those flat spots when smoothing is on. Sometimes it seems perfect, other times it doesn't. Little test programs seem to be ok, but bigger programs that are harder to show don't.

But I don't know how to convey this in a way that can prove an issue, and even if I did, I am not sure it will get resolved just for me.

[centroid467]

Turns per rev, steps per rev, and acceleration values are loaded from your reports. I set up the drive to use 30,000 steps per rev. That plot is from an MDI move: G1 X50 F1500. The main differences are that I have a single axis, different drive/motor (2kW 2k RPM), and different tuning as well because I have no load on the motor shaft. It's a bench setup through and through.


Personally, I'm approaching this with the mindset that if we can repeat this issue on our end then we will be able to find out the cause and fix it. I have the programmer assigned to improvements to smoothing (@adenchik) in on this as well. I can't say what priority it would have or anything regarding how long it would take but we would give it our best shot once we can replicate the issue and troubleshoot. I do not believe the drives are the issue but it is going to be extraordinarily difficult for us to troubleshoot this without being able to make the problem happen.

I'll run more aggressive accelerations and your gcode myself and see what happens.