PVALimiter

PVALimiter shapes a position command so the motion it produces respects a position range, a velocity limit and an acceleration limit all at once. It outputs a matching position, velocity and acceleration, so whatever follows it gets a consistent set.

Its most useful behaviour is at the position limits. Instead of clamping the position — which arrives as a wall and demands an impossible deceleration — it works out, every cycle, the fastest it could be going and still stop in time, and holds the velocity below that. The axis decelerates into the limit and arrives at zero speed.

Deprecated — scheduled for removal. PvajLimiter is the only setpoint limiter that may be used for new work. It bounds the setpoint in jerk as well as position, velocity and acceleration, and its position guarantee holds with no tolerance where this block’s holds to about 1e-9. This block is kept only until the last machine is off it, and will then be deleted.

It is not a drop-in swap. The replacement has no input filter, so omega, beta and enablePVAInputs have no counterpart. Feed it the position setpoint directly and supply the derivatives on its own inputDot and inputDDot leaves, each behind its own switch. See PvajLimiter for the parameter reference.

flowchart LR
    i1(["input — position reference"]) --> B["PVALimiter"]
    i2(["inputDot — velocity reference"]) --> B
    i3(["inputDDot — acceleration reference"]) --> B
    i4(["disable"]) --> B
    B --> o1(["output — limited position"])
    B --> o2(["outputDot — limited velocity"])
    B --> o3(["outputDDot — limited acceleration"])
    B --> o4(["currentMaxVel — allowed velocity now"])
    B --> o5(["currentMinVel"])
    B --> o6(["pLimActive"])
    B --> o7(["vLimActive"])
    B --> o8(["aLimActive"])
    B --> o9(["state"])
    B --> o10(["inputFilt, inputFiltDot, inputFiltDDot"])
    B --> o11(["isEnabled"])

Approaching a limit, the allowed velocity is $\sqrt{2 \times \text{distance} \times \texttt{maxBrakingAcceleration}}$ — so at 0.1 m from the limit with a braking limit of 10, the axis may travel at 1.4 m/s. omega and beta set how hard the block chases the input: higher omega tracks more tightly, and beta 4 is heavily damped so it does not overshoot.

Keep maxBrakingAcceleration at or below maxAcceleration. The block sizes its approach speed on the braking figure but can only ever deliver the acceleration figure. Setting braking higher promises a stop the block cannot perform, and the axis overshoots the limit.

Every instance logs a warning at startup with default settings. omega ships at infinity, meaning “as fast as possible”, and the block corrects it to what the task rate allows — and says so in the log. It is expected.

Signals

Inputs

Outputs

Parameters

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

Setup

1. Set lowerLimit and upperLimit to the axis’s real travel.

2. Set maxVelocity and maxAcceleration from the machine.

3. Set maxBrakingAcceleration equal to or below maxAcceleration. Equal is the normal choice.

4. Leave omega alone. It corrects itself at startup and logs that it did.

5. Leave beta at 4 and enablePVAInputs false for a first pass.

6. Set enable true. Command a small move well inside the limits and confirm output follows input closely with all three flags false.

7. Command a fast move and watch vLimActive and aLimActive go true in turn.

8. Command a move that runs into a position limit. Watch currentMaxVel fall as the axis approaches, and confirm the axis arrives at the limit with outputDot at zero.

   Step 8 drives the axis into its travel limit deliberately. Do it at low speed first, and confirm the deceleration is inside what the machine can take before repeating it at full speed.

Tuning

1. Set the three machine limits first — position, velocity, acceleration. They are properties of the hardware.
2. Keep braking at or below acceleration, per Setup step 3. This is the one parameter relationship the block does not check and it is the one that causes overshoot.
3. Leave omega at its default unless the output visibly lags the input during ordinary moves. It is already as fast as the task rate allows.
4. Lower beta only if the block is too slow to catch a fast input. Below about 1 it starts to overshoot, which for a limiter is the wrong direction.
5. Use enablePVAInputs when your source already produces a consistent position, velocity and acceleration — a setpoint generator, say. It lets the block follow without having to infer the derivatives, so it tracks much more closely. Do not switch it at runtime.
6. Watch currentMaxVel during a limit approach. It is the envelope, and it tells you directly whether maxBrakingAcceleration is set sensibly: a larger value gives a steeper, later deceleration.
7. If you need jerk limited as well, this block does not do it — use a PVAJ limiter.

Read the allowed speed at any distance off the curve for your braking setting.

A starting point for an axis with 1 m of travel, 1 m/s and 10 m/s² on a 1 ms task:

enable                 = true
lowerLimit             = -0.5
upperLimit             = 0.5
maxVelocity            = 1.0
maxAcceleration        = 10.0
maxBrakingAcceleration = 10.0
beta                   = 4.0
enablePLim             = true
enablePVAInputs        = false

Limits and errors

The block logs a warning whenever it corrects omega or beta — which with the default settings happens once at startup for every instance. Every other failure above shows as a value on a trace, not as a message.

Verified against motorcortex-control3 3.32.1 (340db23).