robEllenberg
commented
8 years ago This looks reproducible in simulation using your example code. The reason this occurs is because the 2.7 trajectory planner allows blending between synced motions. Here's a comparison of the axis accelerations with and without your dwell:
Without the dwell (with over-acceleration in the X axis):
With the dwell, only Z axis acceleration:
The cause of this difference is that the 2.7 TP allows blending between normal feed moves (G1, G2, etc) and position-synced moves (G33). This results in a small blend arc (as you observed).
Looking into this a little further, I found that (as expected) the 2.6 TP does not allow blending when starting a G33 move. However, it does allow blending at the end of a G33 move. This G-code snippet shows the behavior in the axis sim config. In 2.6, there will be an exact stop after N5, but there will be a blend between N6 and N7.
N1 G20 G64 G8 G18
N2 M3 S500
N3 G0 X2.0 Z0
N4 G0 X1.1 Z0.1
N5 G1 X1.0 Z0.0 F200
N6 G33 K0.1 X1.0 Z-1.0
N7 G1 X1.1 Z-1.1 F200
N8 G0 X2.0
N9 G0 Z0
N10 M5
N11 M2
So, from the G-code example, the 2.6 TP applies the following rules when blending with position-sync enabled:
- transition from G1 to G33 (exact stop)
- transition between two G33 motions (use path setting)
- transition from G33 to G1 (use path setting)
I have a fix for this in a hotfix branch based on the latest 2.7. Unfortunately, there is a more subtle issue that may arise as a edge case. Take the following G-code example, which follows a zig-zag path in spindle-sync:
G20 G64 G8 G18 M3 S100 G0 X1.1 Z0.1 G1 X1.0 Z0.0 F200 G33 K0.1 X1.0 Z-1.0 G33 K0.1 X0.75 Z-1.5 G33 K0.1 X0.75 Z-2.0 G1 X1.1 Z-2.1 F200 G0 X2.0 M5 M2
Between the bolded lines, even though the feed is very slow, the blend arcs created are quite large:
The arcs are large because the TP has no knowledge of the planned spindle speed for the position-sync motions. Instead, it uses the maximum possible velocity for the segment. We could fix this by preventing arc-blends entirely during spindle-synchronized motion, but still allowing parabolic blends. With that change, we'd have stock 2.6 behavior for all position sync motions.
Another, slightly more involved approach, would be to pass the planned spindle speed to the TP using something like state tags. Knowing the desired spindle speed lets us predict the target velocity, and size blend arcs to match (instead of assuming the worst).
@SebKuzminsky @cradek What do you think of either of these fixes?
cradek
samcoinc
joekline9
andypugh
c-morley
Here are the steps I follow to reproduce the issue:
G20 G64 G8 G18 M3 S400 G0 x.5 z.21 G1 x.490 z.2 /G4 P.01 ( need pause or G0 above for ver 2.7 TP) G33 k.086 x.500 z-.550 G0 x.510 G0 z.21 m5 m2
This is what I expected to happen:
This is what happened instead:
G1 moves toward G33 start point makes a radius then 'Z' over accelerates then slows. After the over accel it slows to proper rate for the remainder of G33 move.
It worked properly before this:
In previous versions or with old (Pre 2.7) TP
Information about my hardware and software:
Machine 1: Using version 2.7.4 Ubuntu Lucid with new TP, Mesa 5i20 & servo card Machine 2: Using version 2.7.4 Debian Wheezy with new TP, Mesa 5i25/7i77