SetpointGenerator

SetpointGenerator turns a step change in a target into a smooth profiled move. Write a new number to input and the output travels there while respecting velocity, acceleration and jerk limits — and publishes the matching velocity and acceleration as it goes, so a feedforward path can use them.

The move time is computed, not configured. You give it the limits; it works out the fastest move that respects them.

flowchart LR
    i1(["input — the target value"]) --> B["SetpointGenerator"]
    i2(["timeScaleFactor"]) --> B
    i3(["timeScaleFactorDot"]) --> B
    B --> o1(["output — profiled position"])
    B --> o2(["outputDot — velocity"])
    B --> o3(["outputDDot — acceleration"])
    B --> o4(["done"])
    B --> o5(["numTargets — how many are queued"])

timeScaleFactor stretches the profile’s clock while it runs — 0.5 makes the move take twice as long at half the velocity and a quarter of the acceleration. That is what a jog-override wheel needs. timeScaleFactorDot lets the override itself be turned smoothly.

All three limits default to 0, and a generator with a zero limit refuses every target. Nothing moves, an error is logged once, and no output changes to tell you why. Set maxVel, maxAcc and maxJerk before anything else.

An unachievable target is discarded, not clamped. The generator keeps the previous target and carries on. That is the safe failure, but it is silent apart from that one log line.

Signals

Inputs

Outputs

Parameters

All are persistent and survive a controller restart. No parameters exist below this block.

Setup

1. Set maxVel, maxAcc and maxJerk first. They default to 0, and a generator with a zero limit refuses every target you give it.

2. Leave faderType at 0 for a first pass — the quintic profile is the gentler of the two.

3. Have your application seed the generator at the machine’s current position before enabling anything downstream, so the first move does not start from zero.

4. Write a small target to input and watch output travel there. Confirm done goes false at the start and true at the end.

   Step 4 moves the machine. The generator will use the full velocity and acceleration you configured, immediately. Start with a small target and limits well below the machine’s capability.

5. Check outputDot peaks at or below maxVel, and outputDDot at or below maxAcc.

6. Write a second target while the first move is running and watch numTargets. The moves queue rather than replacing each other.

Tuning

1. Set the three limits from the machine, not from the move you want. They are what the mechanics can take.
2. Choose the profile shape from what the machine minds more. Quintic is smoother and slower; jerk-limited reaches the limits and holds them, so it is faster for the same numbers.
3. Time a move and compare it against what the limits imply. If it is slower than expected, the quintic shape is the reason — switch to jerk-limited.
4. Use delayTime when several axes should start together after a common trigger.
5. Use timeScaleFactor for a speed override. Ramp it with timeScaleFactorDot rather than stepping it, or the move’s velocity jumps.
6. Raise maxTargets if your application streams targets faster than the moves complete. Watch numTargets to see whether the queue is filling.
7. Nothing here needs re-checking after a task-rate change — but note the block captures the task period once at startup, so if the rate changes while running, restart the controller.

Read how much of the move is spent at constant speed off the straight section in the middle.

A starting point for an axis that may move at 0.5 units per second:

maxVel                = 0.5
maxAcc                = 5.0
maxJerk               = 50.0
faderType             = 0
delayTime             = 0.0
maxTargets            = 10

Limits and errors

The block logs one error when the limit set first becomes invalid. Every other condition above shows as a value on a trace, or not at all.

Verified against motorcortex-control3 3.30.0 (bc348fd).