G33 issue with Ver 2.7 TP

[joekline9]

Here are the steps I follow to reproduce the issue:

1. Run the G code below on Lathe.

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

1. If I have a G1 move leading into a G33 it makes a radius then 'Z' over accelerates then slows.
2. I can use G0 or put G4P.01 before G33 then OK. Only happens with spndl speed over 200~ rpm

This is what I expected to happen:

 feed to the G33 starting point then accel to K value.

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

• I am using this AXIS user interface (GUI)

[robEllenberg]

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:

1. transition from G1 to G33 (exact stop)
2. transition between two G33 motions (use path setting)
3. 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]

I think it would probably be good in 2.7 to have a 2.6-style blend at the end of a spindle-sync move, only because that sounds simple and easy to get right in the stable branch, and it's known to give good results for thread pullouts. Not stopping at the end of the synced move is important, as I tried to explain here.

[robEllenberg]

@cradek Your explanation makes sense, and my hotfix branch should now be updated to reflect 2.6 behavior.

Do you know if there is any demand for position-synced motion along complex paths? If not, we can solve the large blend arc issue by restricting position-sync motions to use parabolic blends. It will result in a slightly longer lead-in motion, however, since the acceleration will be cut in half.

[samcoinc]

Does tolerance effect the blending on spindle synced motion? (g64Px.xxx).. If you wanted the path to follow better (or try to) could you just specify it?

[cradek]

I think synced motion along a complex path is extremely rare, but it has been used. The longer lead-in you mention is more important, but I think it would be fine; I have not ever heard someone say they could not manage a lead-in because of limited space. I guess the nature of threads is that one end is exposed...

[joekline9]

I have cut multiple taper threads that look like a big sheet metal screw and of course end taper on pipe threads.
I don't think we need any blend (G33 to G33) or G33 to G1 in feed per rev mode.
You just don't resync after the first G33. The PID will handle slight accel changes.
You may have to blend if the angle differences are more than 30 degrees or so.

[joekline9]

As far as leadin goes. Some cnc lathes like to run in rev (M4) when threading. You then must start the thread in a groove and feed Z+. In this case leadin should be short as possible. I'd say less than 2 or 3 mm at 400 to 500 RPM.

[robEllenberg]

I have an experimental branch here that will fix this issue, and improve blending performance with G33 motion:

https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/nominal-vel-during-sync

See #164 for details on the performance improvement

[andypugh]

Is this the same as #704 ?

My proposal for 704 is to document the behaviour. I don't think it makes sense to pause between two spindle-synched moves,

What is the best way to force synch-to-index between two consecutive G33 moves?
I will try to test whether a dummy G0 or G1 exits G33 "mode"

[c-morley]

I wonder if there is a way to detect the motion queue was emptied and waiting since the last spindle sync - indicating there has been a pause in movement while threading - an error. But I agree it's weird to try to do continuous threading with multi lines in MDI. Chris

…

________________________________ From: andypugh <notifications@github.com> Sent: April 3, 2020 11:11 AM To: LinuxCNC/linuxcnc <linuxcnc@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [LinuxCNC/linuxcnc] G33 issue with Ver 2.7 TP (#68) Is this the same as #704<#704> ? My proposal for 704 is to document the behaviour. I don't think it makes sense to pause between two spindle-synched moves, What is the best way to force synch-to-index between two consecutive G33 moves? I will try to test whether a dummy G0 or G1 exits G33 "mode" — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#68 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABYGWNJMGAGPUJK2EWYFCYLRKW74LANCNFSM4CGPVNKQ>.

[robEllenberg]

I'm not sure if this is the same issue, but it should definitely not happen regardless of what the user does. Position synch always stops at the end of a move unless it's immediately followed by another. Interp wraps every call to a synched move with a start / stop synch command, and it's only when they're queued in succession that stop / start cancel out and it doesn't drop out of synch. This is definitely a TP bug.

…

On Fri, Apr 3, 2020, 7:23 AM c-morley ***@***.***> wrote: I wonder if there is a way to detect the motion queue was emptied and waiting since the last spindle sync - indicating there has been a pause in movement while threading - an error. But I agree it's weird to try to do continuous threading with multi lines in MDI. Chris ________________________________ From: andypugh ***@***.***> Sent: April 3, 2020 11:11 AM To: LinuxCNC/linuxcnc ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [LinuxCNC/linuxcnc] G33 issue with Ver 2.7 TP (#68) Is this the same as #704<#704> ? My proposal for 704 is to document the behaviour. I don't think it makes sense to pause between two spindle-synched moves, What is the best way to force synch-to-index between two consecutive G33 moves? I will try to test whether a dummy G0 or G1 exits G33 "mode" — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub< #68 (comment)>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ABYGWNJMGAGPUJK2EWYFCYLRKW74LANCNFSM4CGPVNKQ >. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJHUPDFE5OQ5KOI24H23XTRKXBMZANCNFSM4CGPVNKQ> .

[andypugh]

What is the status of this now?
Does b3fa297 help or hinder?

[robEllenberg]

What is the status of this now?
Does b3fa297 help or hinder?

I don't think it fully addresses the original issue (blend between G1 and G33), but it is a necessary fix for 2.7 (The latest 2.7 branch as of this morning still showed #704 behavior).

[andypugh]

Hopefully fixed by #890