Changing Transition Feed rate on Parallel Toolpaths

[Anonymous]

Hello,

Does anyone know how to change the transition feed rate at the end of a pass using the parallel tool path? I am doing some 3D contouring work, with a .010" step over at 50 ipm. The problem i have is that once the tool finishes a pass, it executes a quick arc movement to get to the next stepover pass. This creates a huge acceleration at the end of the pass since the tool has to stop on a dime, move over .010" and accelerate up to full speed. On my machine this creates small gouges in the part at the transitions, and can even lead to control instability at higher feed rates. Ideally, i would like to be able to reduce the feed rate going into and through a transition sort of like feed optimization does going into a sharp corner. This would substantially reduce the acceleration requirements and allow the control to better cope with the changing inertia.

Thanks

[Steinwerks]

Change your Lead-Out feedrate. If that doesn't work in and of itself, change both lead feedrates.

[Anonymous]

Thanks for the quick response. I've tried changing the lead in and lead out feed rates, however this only affects the feed rate entering and leaving the operation. It doesn't seem like fusion has any option to adjust the transition feed rate, so this may be something that needs to be fixed in a post processor.

[Steinwerks]

I see what you mean now, very curious.

It does have a parameter: onParameter('movement:transition', 50) but it is not in the Compare & Edit dialogue. For now yes, it does look like a post edit sort of fix but it might be more complicated than first appears. Perhaps an override multiplier entered as a user variable so you have some control besides just the cutting feedrate.

[xander.luciano]

Interesting for sure.

This idea came up at AU this year and after some discussion we didn't come to an agreement on how it would be implemented or how it would work.

I had a few ideas on how to implement it though and it's all post processor based. Tell me what you think of my ideas and if you like it, I can (try to) add it your post processor to test out.

Smoothed Lead In Transitions

Basic Version - Increases feedrate from lead in/out feedrate to cut feedrate by incrementally increasing feedrate over a specified distance

- Parameters:
    > Distance - How far should we travel before reaching cut feedrate?

    > Steps - How many times do we increase the feedrate during that distance?

Example: From 10 to 120ipm over .500 inches with 10 increments. 

= .050" step size with an increase of 12 IPM per step.

0.000" to 0.050" @ 10 IPM

0.050" to 0.100" @ 22 IPM

0.100" to 0.150" @ 34 IPM

...

0.450" to 0.500" @ 120 IPM

Basic 2 - Specify the size of the steps, and feedrate increase per step.

Basic 3 - Specify the (max) size of the steps, and the distance to incrase speed over.

 - Same idea as above, but with different parameters

Constant Acceleration - Increases feedrate at a specified acceleration over any distance neccassary at the given step distance
- Parameters:

    > Acceleration - Acceleration of tool in Incher per minute per minute

    > Step Size - How far do we go before increasing speed

The math for this one is a lot more involved, but I think you'd get the idea.

Additional thoughts: All parameters can be set and adjusted by using a manual NC operation inside Fusion and keywords such as making a comment that says: "mode:basic1;dist:.500;step:10;"

Not the best looking or more user friendly, but something like that.

-------------------------------------------------------------------------------------------------------------

Challenges and Issues

 - The first issue is that this could potentially make the probably worse by causing the machine to jerk more at each interval step, causing more gouging.

 - Another issue that if the step size is too small, you won't actually be able to ramp up because the controller could end up with data starvation.
 - The last issue I see if that this may not be the best way to fix gouging. Changing lead ins and out may work better, and also be simpler. You may be able to reduce gouging by making the lead and cut feedrate closer in speed so that the change in feedrate is not that drastic. 

On the post processor side, there's a few challenges also. the easiest situation is if the feed toolpath is a single straight line that can be easily subdivided. This will rarely be the case though, and it's more like the first movement will be an arc. task of slicing up an arc into multiple segments is more challenging than a straight line, and may interfere with feed optimization if enabled. 

Additionally, CNC machines are tuned using PID loops to be able to accurately position, jog, move, without over / under shooting or oscillating. It is possible to reduce the accelerations from some controllers, but I wouldn't recommend it unless you know what you're doing and what you are looking for. 

If machine manufacturers thought an optional ramp up speed gcode command would improve their machines, I'd sure they would have added it. Makes me wonder why machines don't have this option. 

All in all, it's an interesting idea, but there's a lot to consider and think about, and it may not even end up being worth it. I would't even know what numbers to suggest using.

Curious as to what you guys think about this idea,

- Xander Luciano

[xander.luciano]

@Steinwerks Just an FYI the line you are talking about is referring to a linking transition movement, not so much a transition speed. 

1238: onParameter('movement:lead_in', 1000)
1239: onParameter('movement:cutting', 1000)
1240: onParameter('movement:lead_out', 1000)
1241: onParameter('movement:transition', 1000)
1242: onParameter('movement:direct', 1000)
1243: onParameter('movement:helix_ramp', 333.33299999999997)
1244: onParameter('movement:profile_ramp', 333.33299999999997)
1245: onParameter('movement:zigzag_ramp', 333.33299999999997)
1246: onParameter('movement:ramp', 333.33299999999997)
1247: onParameter('movement:plunge', 333.33299999999997)
1248: onParameter('movement:predrill', 1000)
1249: onParameter('movement:extended', 1000)
1250: onParameter('movement:reduced', 0)
1251: onParameter('movement:finish_cutting', 1000)

Which are just integer values that you can check with 'onMovement()' to get the current movement type in the post processor. 

303: onMovement(MOVEMENT_LEAD_IN /*lead in*/)
303: onLinear(...)
304: onLinear(...)
305: onMovement(MOVEMENT_CUTTING /*cutting*/)
305: onLinear(...)
306: onMovement(MOVEMENT_LEAD_OUT /*lead out*/)
306: onLinear(...)
307: onMovement(MOVEMENT_RAPID /*rapid*/)
307: onRapid(...)
308: onRapid(...)
309: onSectionEnd()

I'm not even aware of any controllers support feedrate transitions since everything is controlled through PID loops, acceleration rate, and jerk rate values (jerk being the derivative of acceleration). 

Best,

- Xander Luciano

[matty.fuller]

I am having a similar problem with ironing out the kinks in my approach/post - I have gantry machines (Biesse Rover) so there is quite a lot of mass to move when it steps over, and it often shudders quite badly, which can affect parts and is also not great for the machine. I have a few things I had planned to work through to resolve it:

I often run parallel finishing ops in Y only, to avoid moving the whole gantry constantly and dragging the kevlar curtains over the part more than necessary. This means that while cutting the X motors don't run, but then when linking they need to move the whole gantry by 1mm, which even at a very slow feedrate is seemingly a tough acceleration/deceleration condition. Something I plan to experiment with is running the passes at a non-square angle, so that the X motors are constantly moving a bit as well - they will still need to change direction at some point, but hopefully the interpolation of that linking arc will smooth it out a bit. A similar option is to experiment/compare spiral operations instead to compensate for the instability.

Another option is that the machine's control has a G28 command that instructs it to ramp acceleration/deceleration for non-tangent moves, proportional to their length. A bit of testing so far indicates that it doesn't really work for us with a complex toolpath like you get out of Fusion - I am already having issues with data starving and inserting a G28 seems to exacerbate that a lott, plus the arcs in linking moves will often be solved as tangential anyway. Probably will look into it further when time allows.

As @xander.luciano covered the other options I would next look at are probably post processor based ways of smoothing the feedrate, or programming approaches that provide a toolpath which better suits the machine's mass/inertia. I have definitely been able to get it running smoothly for hours with parallel ops in Y, and my hunch is that in our case it has more to do with data starving and how the PLCs cope with different types/volumes of instructions - I would prefer to have it resolved in the code so that the machine doesn't have to do extra calculation work during machining.

Very much a topic I am interested in, as the solution affects the quality/speed/reliability that we can deliver, plus wear on the machine & tooling.

[Steinwerks]

---

@xander.luciano wrote:

@Steinwerks Just an FYI the line you are talking about is referring to a linking transition movement, not so much a transition speed. 

1238: onParameter('movement:lead_in', 1000)
1239: onParameter('movement:cutting', 1000)
1240: onParameter('movement:lead_out', 1000)
1241: onParameter('movement:transition', 1000)
1242: onParameter('movement:direct', 1000)
1243: onParameter('movement:helix_ramp', 333.33299999999997)
1244: onParameter('movement:profile_ramp', 333.33299999999997)
1245: onParameter('movement:zigzag_ramp', 333.33299999999997)
1246: onParameter('movement:ramp', 333.33299999999997)
1247: onParameter('movement:plunge', 333.33299999999997)
1248: onParameter('movement:predrill', 1000)
1249: onParameter('movement:extended', 1000)
1250: onParameter('movement:reduced', 0)
1251: onParameter('movement:finish_cutting', 1000)

Which are just integer values that you can check with 'onMovement()' to get the current movement type in the post processor. 

303: onMovement(MOVEMENT_LEAD_IN /*lead in*/)
303: onLinear(...)
304: onLinear(...)
305: onMovement(MOVEMENT_CUTTING /*cutting*/)
305: onLinear(...)
306: onMovement(MOVEMENT_LEAD_OUT /*lead out*/)
306: onLinear(...)
307: onMovement(MOVEMENT_RAPID /*rapid*/)
307: onRapid(...)
308: onRapid(...)
309: onSectionEnd()

I'm not even aware of any controllers support feedrate transitions since everything is controlled through PID loops, acceleration rate, and jerk rate values (jerk being the derivative of acceleration). 

Best,

- Xander Luciano

---

My point was rather that since the feedrate is read expressly from the posted code separate from the MOVEMENT_CUTTING it can be altered. I tried a few things but it just ignored them which I blame on my lack of knowledge in JavaScript.

FWIW many MTB's handle acceleration and deceleration rates, and some have many settings (Fanuc has 10 levels of G5.1 altered by Q and/or R values, but only if you/your MTB has paid for the option, Fadal Format 1 uses G08 to turn off exact stop mode, and G09 to cancel the G08, Haas has G187 with three P modes and what they call "corner rounding" settings defined by E values which affect acceleration rates that are defined in the parameters, Brother has up to I believe nine M-codes to control accuracy and high-speed functionality, and these are also purchased options, etc.).

Edit: I forgot to add that different MTB's do different things with the same controls too. Buy a Makino vs a Mori, one has the Pro control, the other might have MAPPS, and underneath is Fanuc in both cases but the operation and options will be quite different. Enough to drive someone crazy! 

I for one would only wish to be able to control the transition feedrate. Anything else is going to be a function of specific machine kinematics and even between the same builder and same model they can vary since they are so dependent on mechanical conditions. Now theoretically (and in a perfect world) the transition is in a non-contact move so shouldn't affect surface finish but of course this is not always the case.

Having the CAM change feedrates in a series of tiny moves would be maddening and I suspect some machines will simply attempt to shudder themselves to death doing so, and simply never achieve the desired result.

[Anonymous]

Thank you all for the great replies. My machine has a Centroid control, which incorporates smoothing that works quite well when activated. I just wish there were a way to extend the feed optimization to the transition movements in CAM. This would be a more robust solution in my opinion, since it does not require the operator to turn on the smoothing, or manually insert the smoothing command into the G code. All were really after here is to be able to slow the feed rate in advance of abrupt changes in direction, to lessen the acceleration required to execute the move.

[dreyfusduke]

Has anyone come up with a solution for this?   It really is bad for us CNC router people or any machine that has a heavy gantry.    It may be ok for more expensive servo controlled machinery, but it's really making people like myself, and other router users, to look at other cam software packages.   Some routers are capable of cutting at 600ipm pretty easily, but we need to be able to choose the transition speeds.   As you can see in my attached photo, it jumps back to the "set" federate just BEFORE making the transition.   I wish it would not do this.

[scottmoyse]

---

@dreyfusduke wrote:

Has anyone come up with a solution for this?   It really is bad for us CNC router people or any machine that has a heavy gantry.    It may be ok for more expensive servo controlled machinery, but it's really making people like myself, and other router users, to look at other cam software packages.   Some routers are capable of cutting at 600ipm pretty easily, but we need to be able to choose the transition speeds.   As you can see in my attached photo, it jumps back to the "set" federate just BEFORE making the transition.   I wish it would not do this.

---

Can you share your file that generated the toolpath in your image please?

[Anonymous]

Did anything  ever come of this discussion? We regularly hit this problem with Fusion's Parallel Toolpath code. The only way round it, is to slow the whole toolpath down, which is a shame because Parallel paths are one of the fastest. Our machine has a rock-solid, but heavy gantry and we regularly have to either slow things way down in parallel paths or take the his and use the contour paths instead.

[Anonymous]

Any progress in solving this issue? 

Should it be posted in IdeaStation?

The only way I see for now is to manualy change Feedrate speed for Transition moves in generated .tap file (I'm using mach3mill postprocessor). That is annoying.

[Anonymous]

I stumbled on this post while looking for why Fusion seemingly ignores the "feed optimization" section (at the bottom of the Passes tab) for parallel toolpaths.  These settings work fine in Trace toolpaths... why not Parallel?  I want the machine to slow down BEFORE it comes to a direction change, not just for transition moves.