scurve trajectory planner

Just for information. How and where should we report issues and questions?

Is this thread the right one (or one of the older/other ones)?

I understand all pins and parameters with one exception. Can you give me a short overview about hal_blend_speed? I dont get curvature vs. gcode... First of all I dont know the meaning of the word curvature (ouch)

@Julian,

Hal blend speed is a special feature, Mr. Lcvette requested this feature a while ago.
Blend speed can be used to tune a machine to it's inertia limits.

The blend is the fillet (rounding) between 2 trimmed (shortened) gcode lines (segments). Given the G64 P[..] value.
The blend speed is a factor value "0-1".
The blend speed is used to tell the planner how to behave at the blends, focussing on blend speed.
Curvature is the ammount off roundness of a arc or circle. It is related to the radius.
Based on curvature -> radius, the blend speed is calculated by mathematics.

-> hal_blend_speed
minimal value : 0.0
maximal value : 1.0

Example :
hal_blend_speed 0.0 = use blend speed based on curvature only. (safest way of running the machine, lowest output speed)
hal_blend_speed 0.5 = use 50% speed based on curvature, use 50% speed based on gcode feed.
hal_blend_speed 1.0 = use gcode feed only. (can become risky, machine may run beyond inertia limits, highest output speed)

On youtube there is a video, where you can see the difference at runtime on a real cnc machine.
Later on in the video the hal_blend_speed is set to 1.0 at time 5:51
video link

Then you can for example tune your machine to a hal_blend_speed : 0.85
This then you can edit in the source code and recompile. Then it becomes a startup value.
fill in blend speed here.

O_o

o_O

Grotius you're a madlad

I'm pretty sure you can just send this to a university and they'll send you back a math degree diploma

I've been away from the game for quite a while as I was finishing school myself, but I'll put this to work in the near future

For awareness:

The scurve planner has some behaviour changes around:
motion.feed-hold
motion.adaptove-feed

Under the standard planner per documentation the effects of these pins can be enable or disabled through the use of M53 and M52 respectively.  These M codes are not supported under scurve.  The effects of these pins are always active.

If this departure from current behaviour is material and of concern then we would be interested to understand what the "real world" down sides are to this implementation.

Thanks - James.
 

Joco wrote:

For awareness:

The scurve planner has some behaviour changes around:
motion.feed-hold
motion.adaptove-feed

Under the standard planner per documentation the effects of these pins can be enable or disabled through the use of M53 and M52 respectively.  These M codes are not supported under scurve.  The effects of these pins are always active.

If this departure from current behaviour is material and of concern then we would be interested to understand what the "real world" down sides are to this implementation.

Thanks - James.

 

I've never used a feed-hold disable function; I suspect it's a legacy feature intended for machines run by operators who are not 'allowed' to really manipulate the controls.  Or the programmer sees a feature to be cut where feed-hold would lead to issues (drill/tool rubbing and work-hardening the part) and turns off feed hold for that program segment.

Neither have I used adaptive-feed, but I could imagine a situation where the programmer or operator would like to turn it off/on.  Perhaps using block-skip in the program for segments (roughing, maybe?) where adaptive feed is appropriate but not fully proven out.

Adaptive feed and feed hold are core to how plasmac for plasma machines operates.   However it does not use the gcode on/off capabilities that I have seen.

feed-hold issued during a tapping cycle could be catastrophic as it just stops xyz motion and does nothing to spindle.   Feed-inhibit would be appropriate then as it alllows synch motion as used in tapping to complete.

Adaptive feed along with external offsets allows for some cool cut recovery operations on a plasma or probably any jet cutting machine (e.g. Laser or water jet)

tommylight wrote:

At the risk of repeating myself:
Grotius is like a heat seeking missile, he locks on to something and does not stop!
Thank you Grotius.

In this case, the missile orbited earth at least 15 times and probably once around Mars before hitting the Scurve target!

I am in awe with Grotius's tenacity over many years on this!

Joco wrote:

Adaptive feed and feed hold are core to how plasmac for plasma machines operates.   However it does not use the gcode on/off capabilities that I have seen.

feed-hold issued during a tapping cycle could be catastrophic as it just stops xyz motion and does nothing to spindle.   Feed-inhibit would be appropriate then as it alllows synch motion as used in tapping to complete.

Adaptive feed along with external offsets allows for some cool cut recovery operations on a plasma or probably any jet cutting machine (e.g. Laser or water jet)
 

I was under the impression that LCNC already disables feed-hold in the background during tapping or other spindle-synchronized movements.  I think activating feed-hold has no effect until the tool is back at the retract plane.  Which is why I didn't think adding feed-hold disable feature to the s-curve Tp was necessary.

But I could see a use for adaptive feed enable/disable during g-code.  Hope I didn't give the impression I didn't think it was useful.
 

Don’t make that assumption re feedhold. And tapping. The planner is taking things direct from the Hal pin. Not from the lcnc motmod module.

it needs to be explicitly tested. Unless someone has done so already and can confirm what the behaviour is.