Home / Insights / Multi-Segment Trajectory Control: Moving the Loop Inside the Drive

Technical note

Multi-Segment Trajectory Control: Moving the Loop Inside the Drive

Multi-segment trajectory control is a standard feature across the 48 V DC drive range: a sequence of moves is defined in the drive's dictionary and executed inside the drive, rather than commanded one segment at a time from the host. This note explains what actually changes when the sequencing moves into the drive, where the honest boundary lies between a function integration and a replacement for a machine controller, and how I would structure a sequence for a process that has contact events in it.

What multi-segment control actually is

Multi-segment trajectory control is a mode in which a sequence of moves is defined in advance and executed inside the drive, instead of being sent one move at a time from the host. The sequence lives in the drive's parameter dictionary — the documentation for it is a dictionary operation guide in its own right — and the drive runs the segments back to back under its own timing. The difference from a host that issues one command per move is not the shape of the move; it is where the timing decision is made. When the host sends a move and waits for the drive to report completion before sending the next one, the pause between segments is bounded by the host's task scheduling and its bus latency. When the drive owns the sequence, the transition from one segment to the next happens on the drive's own clock, in the same context as the loops that execute the move.

Why it changes timing and repeatability

That distinction shows up in throughput and in repeatability. A production index doing short moves — a pick, a place, a bond cycle step, a probe retract — spends a surprising share of its time in the gaps between moves, and the gaps are where host latency lives. Moving the sequencing into the drive removes the host from the timing path for those transitions. It also removes a class of variation: the same sequence produces the same timing on every part, because the same firmware does the same thing each time, rather than a controller that may or may not be busy. Multi-segment trajectory control is in the standard feature set across the range, on all four bus types — EtherCAT, CANopen, Modbus and pulse/direction — so it is not a premium option you have to negotiate for. That is worth stating plainly, because a great many suppliers would treat it as one.

The honest boundary: integration, not replacement

Here is the boundary I try to keep clear when this comes up, because the phrase it is all in the drive invites the wrong conclusion. Multi-segment control is a function integration, not a hardware replacement. It does not give you a machine controller. You still need something to decide what happens: which segment to run, when to run it, what to do when a part is missing, when a sensor reports the part as bad, or when an operator intervenes. On an EtherCAT machine that logic lives in the PLC or motion controller; on a pulse/direction machine it lives in the controller that emits the pulses. What changes is that the drive no longer has to be asked permission for every segment of a movement it already knows how to make. If your machine genuinely needs a separate motion controller, you still need one. If your machine needs a drive that can execute a defined sequence without being re-commanded segment by segment, this is what you are buying, and it is a smaller and clearer claim than it is often made out to be.

Sequences and contact events

The interesting combination is multi-segment control with the force functions, because most processes that are gentle are sequences: approach fast, decelerate, contact, hold, retract. The UF and DS software lists include a probe function for contact detection and force feedback, and force control with contact force typically around 10 grams and roughly ±1 gram variation, with the high-performance -P version offering finer force resolution. When the drive executes the sequence, the detection and the force feedback happen inside the same execution context as the motion, which is the condition you want for a repeatable contact. I have covered the loop side of this in more detail in the note on why 48 V DC changes force control, and the market comparison is in why the 10 g figure is not a differentiator.

Structuring a sequence for a real process

When I help a customer structure one, the pattern is usually four or five segments rather than a long list: a fast approach to a safe distance above the part; a controlled approach at the speed where contact force stays inside the process window; a dwell at contact while the force feedback confirms the landing; and a retract at a speed the process can tolerate. The parameters that need judgement are the deceleration into the contact segment and the dwell, because they are where the contact force is actually set, not the approach speed. I would also plan what happens if contact is never detected — the probe function and the timeout behaviour need to be agreed before the machine runs in production, not debugged during commissioning.

Four questions the manual has to settle

Before specifying multi-segment control, four questions come up that I cannot answer from a datasheet and that the documentation has to settle: how many segments the dictionary holds and how they are written, whether the segment set can be changed while the axis is running or only while it is stationary, what the drive does with the remaining segments when one is interrupted by a bus fault or another fault condition, and how the internal segment timing behaves relative to the position loop update. These are real engineering answers rather than marketing ones, and they are exactly the questions that decide whether a sequence feels predictable in production. If you want the dictionary operation guide, it is in the document library, and the software feature lists per bus type are on the model parameters page.

Where it shows up in practice

It is worth saying where I see multi-segment control used most, because it informs the expectations. On a ZR stage the sequence is the natural unit of work — a Z move, a rotation, a settle, a return — and the dual-axis ZR unit, GM1-E48xxN-2D-ZR, executes it. On die-attach and pick-and-place machines the sequence is a cycle with several contact events in it, and the multi-axis EtherCAT unit, GM1-E48xxN-6D-MT6, carries several axes of that work over one bus. The multi-segment function is available on single-axis products as well; the multi-axis hardware is a separate choice. Keeping those two things separate is the specification mistake I see most often, and it is worth fixing at the quotation stage rather than at the firmware stage.

Key takeaways

• Multi-segment trajectory control is standard across the range on all four bus types: the sequence is defined in the drive and executed on the drive's own clock.
• It is a function integration, not a replacement for a machine controller — the logic that decides what happens next still lives in your PLC or controller.
• The segments that need engineering judgement are the deceleration into contact and the dwell, because those set the contact force.

Common questions

Does multi-segment trajectory control let me drop my external controller?

No, and I would not want it to be read that way. It is a function integration: the drive executes a defined sequence without being re-commanded segment by segment, but the decision logic — which sequence, what to do on a missing part, what to do on an operator intervention — still belongs to your controller.

Is multi-segment trajectory control available on every bus type?

Yes. It is in the standard software feature set across the range on EtherCAT, CANopen, Modbus and pulse/direction variants, so it is a configuration choice rather than a negotiated option.

How is the sequence defined?

In the drive's parameter dictionary, with a dedicated dictionary operation guide for it. The guide and the per-bus software feature lists are in the document library, and it is worth reading the guide before designing the sequence, since segment count, write timing and behaviour after an interruption are all decided there.