Choosing a motion controller for a high-speed SMT machine

[ORIS ORIS]

Hello everyone,

I would like to share my experience and start a discussion about choosing the optimal motion controller for a high-speed SMT machine. Over the past few months, I have performed extensive instrumental and live testing on three different platforms, and the results are quite controversial.

First, a brief overview of my machine:
- Dual-nozzle head.
- Panasonic Minas A6 AC servos on X, Y, and Z axes.
- HIWIN 15mm linear rails.
- 1620 C3-grade ballscrews (20mm pitch).
- Linear speeds up to 2 m/s on X and Y.
- High-speed vacuum and blow-off solenoid valves mounted directly on the head (pick/place execution takes about 3 ms).
- Camera: 1500 FPS (320x240 resolution) with a 4.5 microsecond exposure time. Total time for capture + computer vision recognition is just 1.7 ms. Zero settling time required.

-  Coaxial light for the top camera and a high-power strobe (15,000 lumens) for the bottom camera.
- Real-world throughput: 5000+ CPH using 2 nozzles with bottom vision.

Platform 1:  Smoothieboard   v1
Originally, the machine ran on Smoothieboard v1 with a specialized CNC firmware build . In OpenPnP, I used GcodeAsyncDriver with Simulated3rdOrderControl. The measured latency between the end of motion (M400) and the start of the next move (cold start) was only 3 ms. This setup worked flawlessly for 4 years of continuous production. It provides incredibly fast and smooth motion. The only bottleneck is the 100 kHz step rate limit and very limited MCU resources for the motion planner when running at high speeds and resolution.

Platform 2: Duet 3 6HC (RepRapFirmware)
This is an amazing hardware platform with a great ecosystem, superb homing routines, live tuning, and an excellent web interface. The motion is flawlessly smooth. However, it has a massive drawback for a high-speed SMT machine: there is a constant real-world cold start latency of about 35 ms before the start of every new motion (after M400). This completely kills the advantage of a fast camera and fast valves. You can read more about this in my thread on the Duet forum: https://forum.duet3d.com/topic/39323/severe-latency-on-m400-under-openpnp-control. The developers managed to lower the bare firmware lag to 25 ms, but with planner overhead, the real latency remains around 35-40 ms. It is a fantastic choice for regular machines, but not for ultra-fast applications.

Platform 3: grblHAL on STM32H7
The measured cold start latency between motions (after M400) is excellent—only 4 ms. However, the OpenPnP plugin feels poorly optimized. I had to manually modify the source code to accept millisecond G4 dwells and to stop the planner from freezing the buffer at the junction of segments when M204 is passed. In live testing, Simulated3rdOrderControl performs terribly; the motion is sometimes jerky, and the latency increases. Raw ConstantAcceleration mode is fast, almost like Smoothie, but the motion is extremely harsh. Any attempt to lower acceleration to smooth it out results in a massive drop in throughput. The native grblHAL 3rd order acceleration (jerk control) performs better than Simulated3rdOrderControl in terms of speed, but worse than ConstantAcceleration. Instrumental analysis of STEP pulses and live tests show that the algorithm is unoptimized. However, grblHAL is the first controller on which I managed to test Full3rdOrderControl by injecting M201.3 (Jerk) into every motion block, but it still couldn't beat Smoothie in terms of speed-to-smoothness ratio.

I have also prepared a short video demonstrating the differences in motion performance of the tested controllers   https://www.youtube.com/watch?v=5fS3RE_dxLU

My question to the community: What are your thoughts on this?
One potential option is Smoothieboard v2, but I am very concerned about the presence of an RTOS in it, which might introduce Duet-like latencies and ruin the performance. Is the old Smoothie v1 really the only optimal choice left for a high-speed SMT machine?

Looking forward to your thoughts .

[simpl...@tuta.io]

> Is the old Smoothie v1 really the only optimal choice left for a high-speed SMT machine?

That's an interesting question.

I also started out many, many years ago with a smoothieboard and a belt machine with ELP cameras and barely managed more than 2.5 kcph using OpenPnP 1.0. 

What bothered me most was the vibration of the entire mechanism, as there were practically no affordable fast full jerk control motion available in the DIY sector back then (2017/2018).

Long before Markmaker implemented the "Jerk-Choppering" i set about implementing the G-code commands using a good microcontroller (Arm M7) and asic pulse generators (TMC4361A) for each axis. These generate clean 7-segment motion profiles with full jerk control - a very expensive but reliable approach. 

A simple G-code with all the necessary axes is processed in real time (via 100Mbit LAN; USB isn't suitable for harsh environments), the pulse trains are sent to the servos (and to all steppers on the head-controller via CAN-FD 6MBit) and the use of M400 is unnecessary, as the feedback ("ok") only occurs after the complete G-code has really finished. Handling i/o-ports, including feedback, takes a roundtime of a fraction of a millisecond using LWIP (without RTOS of course). This is not super fast, but sufficient for 6 kcph on a 4-nozzle machine, even with 20mm ball screws and also thanks to my self-built fly-by-vision, where images are processed with OpenCV in the sub-millisecond range on a host with an old i5 notebook cpu. But wait and see what my new diy machine can do with parallel picking of 6 components simultaneously... 

What I'm trying to say is that sending elaborately fragmented G-code segments for clean jerk control might not even be necessary if a motion controller can handle it, or even better, if you leave it to the servo drive, since almost all network-enabled servo drives can be fed with yerk-controlled motion commands – EtherCAT would be the ideal solution.

And although processing "asynchronous" G-code instruction chains can be advantageous for slow machines with e.g. slow feeders, i see no point in doing so when fast components are used. It also works "synchronously" with a motioncontroller command buffer size of only one single line.

If you take your time and don't get distracted by the 3D printer motion controllers, then developing a custom motion controller specifically for the PnP application is no problem, except perhaps for the cost...

[ORIS ORIS]

Developing my own controller is not in my plans — I would prefer to use an off-the-shelf solution.

The issue is not even the speed of the command interface, but rather the latency between receiving a command and the start of its execution.

As testing has shown, the actual command data transfer itself is far from being the bottleneck.

I am simply surprised that a 100 MHz microcontroller shows better results compared to its 500 MHz counterparts.

понедельник, 17 августа 2026 г. в 01:35:05 UTC+3, simpl...@tuta.io:

[simpl...@tuta.io]

you mean 120MHz (LPC1769), right?

porting smoothieware to a faster mcu should be no problem

Aug 17, 2026, 01:04 by lobo...@yandex.ru:

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/5d15204c-4c69-42a6-9514-4876b734d475n%40googlegroups.com.

[ORIS ORIS]

Yes, LPC1769 — that's the one. 

As for porting Smoothieware to a faster MCU — I'm sure it's doable, but that's a bit beyond my current skill set. I'll leave that task to those more qualified :)

понедельник, 17 августа 2026 г. в 02:45:31 UTC+3, simpl...@tuta.io:

[vespaman]

Hi lobo...@yandex.ru,

Interesting, and very significant whatching your video! 
As someone using smoothieware v1 on a charmhigh mainboard, I have no experience of the others in your test.

How are you measuring the 3ms on your smoothie (completely on your smoothie board, or using the OpenPnP log etc)?

 -  Micael

[ORIS ORIS]

Hi  Micael . Thanks! I'm glad you found the video interesting.

As for the measurement method — I connect the board via UART and use a logic analyzer to capture the exact timing between the end of the last bit of the motion command transmission and the first STEP pulse on the axis driver. That gives me a direct hardware-level latency reading.

A simpler way to get a rough estimate is to send a short sequence like G1 X10 M400 G1 X20 and measure the pause between the two bursts of STEP pulses on the analyzer. That pause includes the latency I'm interested in.

And if you don't have a logic analyzer handy, OpenPnP diagnostics also show both the calculated motion time and the actual elapsed time. If you run a test pattern with multiple segments, you can divide the total difference by the number of segments to get an average per-segment latency. It's less precise, but it gives you a good ballpark figure.

понедельник, 17 августа 2026 г. в 10:53:32 UTC+3, micael....@gmail.com:

[ThePoll100]

Hey, where can I watch this video?

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/ebf25da1-7b31-4b81-9de2-845fa71111ean%40googlegroups.com.

[ORIS ORIS]

https://www.youtube.com/watch?v=5fS3RE_dxLU

понедельник, 17 августа 2026 г. в 12:34:44 UTC+3, mat...@gmail.com:

[Jarosław Karwik]

Hi,

There is one more possible way - rarely used.

LinuxCNC ( https://linuxcnc.org/ )

You would need extra hardware, maybe even EtherCAT capable motor drivers - but it has potential to cut the most of the latency caused by extra controller.

But it is hard and rocky way.....

There was a topic on forum how to integrate it to OpenPnp 

[vespaman]

måndag 17 augusti 2026 kl. 11:14:52 UTC+2 skrev lobo...@yandex.ru:

Hi  Micael . Thanks! I'm glad you found the video interesting.

As for the measurement method — I connect the board via UART and use a logic analyzer to capture the exact timing between the end of the last bit of the motion command transmission and the first STEP pulse on the axis driver. That gives me a direct hardware-level latency reading.

Understood. So my next question would be how you measured on the Duet. Reason for asking is if USB is involved in the measured time. You probably know this, but USB is a well known time-sucker for this kind of application.
I'd be surprised if RTOS adds any significant overhead - indeed, I would have thought the opposite with a carefully designed software.

 
Unfortunately, I cannot hook up anything to my machine right now (electronics is inside the machine, and hard to get at), but even 3ms sounds a bit high. My board is clocked at 160MHz though (it is a STM32, with my own serial code @ 4Mbit/s), so it might not be a usable comparison.

It is an interesting test though, and I'll be sure to test this the next time I have it open. I'm always chasing ms.

 -  Micael

[ORIS ORIS]

I spent a huge amount of time working with Duet. My main latency measurement methods are exactly the same: measuring the pause between the end of the motion command transmission via UART and the very first STEP pulse.

As for USB, I generally try to avoid using it. However, I did test USB, UART, and network connections on Duet. 

Both USB and UART showed the exact same lag (taking data transmission time into account), while the network connection introduced even more latency. 

Furthermore, I modified the Duet source code directly inside the planner to toggle GPIO pins so I could track specific scenarios using a logic analyzer.

All of this is covered in great detail in my thread on the Duet forum https://forum.duet3d.com/topic/39323/severe-latency-on-m400-under-openpnp-control.

Ultimately, though, the overall latency is clearly demonstrated by a simple test pattern of three movements in OpenPnP and by diagnosing the expected versus actual motion.

понедельник, 17 августа 2026 г. в 13:56:07 UTC+3, micael....@gmail.com:

[ORIS ORIS]

Hi, the idea of using LinuxCNC as a middleware layer actually crossed my mind before.

However, my knowledge in this specific area is quite limited, so I can't really estimate the scale and complexity of such an undertaking.

понедельник, 17 августа 2026 г. в 13:28:43 UTC+3, jarosla...@gmail.com:

[Jarosław Karwik]

Check here :

https://forum.linuxcnc.org/pnp/48799-openpnp-with-linuxcnc-via-linuxcncrsh?start=0

https://groups.google.com/g/openpnp/c/y9mnpG-YXOI

It should not be that much different then e.g, tunning Duet controller over TCPIP terminal ( well - sort of as LinuxCNC has its own challanges and learning curve)

[vespaman]

I spent a huge amount of time working with Duet. My main latency measurement methods are exactly the same: measuring the pause between the end of the motion command transmission via UART and the very first STEP pulse. 

 

Alright, that just shows how little knowledge I have about the Duet ecosystem -  I thought they where all just USB or network... :-)

Furthermore, I modified the Duet source code directly inside the planner to toggle GPIO pins so I could track specific scenarios using a logic analyzer.

All of this is covered in great detail in my thread on the Duet forum https://forum.duet3d.com/topic/39323/severe-latency-on-m400-under-openpnp-control.

This is good to know in the end - I actually was considering at one time, to port RepRap onto my controller board, or switch to Duet. (But in the end, I decided not to, since I have tweaked the smoothie code so much for my own needs)

 - Micael 

[ORIS ORIS]

Thanks, I read through both threads! Now I realize that I know absolutely nothing about this, and to be honest, I think this method is a bit of an overkill for my specific application.

понедельник, 17 августа 2026 г. в 21:25:37 UTC+3, jarosla...@gmail.com:

[ORIS ORIS]

Hello everyone,

I would like to share some intermediate benchmarking results regarding motion controller latency. For this test, I used an STM32F407VET6 MCU running on an MKS Monster8 V2 board. Instead of moving to alternative platforms, I decided to build upon the existing Smoothieware core. My custom firmware is based on the janm012012 / Smoothieware-CHMT fork, into which I backported advanced motion concepts from the markmaker / Smoothieware repository (feature/best-for-pnp branch), along with several low-level optimizations.

Key features implemented in this build:

1. Compiled with the maximum optimization level, stripped of all unnecessary modules (extruder, temperature control, panels, etc.) to keep the main loop completely lightweight.
2. Moved critical text parsing and step-generation routines directly into fast internal RAM execution.
3. Established a direct hardware TTL link to the host PC via an internal PCIe-to-UART card (WCH382), running at a stable 921,600 baud with full RTS/CTS hardware flow control.

Bandwidth Stress-Test Context:
To evaluate the absolute throughput limits of the MCU parser, I initially flooded the planner with a dense array of micro-segments using Simulated3rdOrderControl. At ~1 Mbps bandwidth, transmitting this extreme amount of textual commands physically requires 54 ms of pure cable transfer time. Naturally, this would introduce an immense 54ms+ startup latency before the axis actually starts moving.

To decouple the serial transfer bottleneck from the execution start, a minor modification was made in Conveyor::check_queue:
if (blocks_in_queue >= 2 || force)
This allows the motion planner to open the gates and trigger physical movement immediately upon receiving the first two G-code lines. The remaining micro-segments continue to stream seamlessly into the DMA ring buffer in the background while the machine is already moving, turning a slow sequential serial bottleneck into a highly parallel pipeline.

Instrumental Measurements (Logic Analyzer @ 100MHz):
To measure the real-world command junction latency, I executed a motion profile consisting of multiple segments separated by M400. In this scenario, the total idle pause between the bursts of STEP pulses on the analyzer captures the entire loop overhead: the time required for the controller to report the coordinates of the completed move (M114 logic), the host processing time, the cable transmission time of the next incoming command package, and the clean cold-start execution latency of the MCU:

• Stock Smoothieboard v1 (LPC1769 via USB VCP): 4.8 ms total idle pause (~3.0 ms clean cold start)
• Custom STM32F407 (DMA UART @ 921,600 baud): 4.3 ms total idle pause (~1.2 ms clean cold start)

The optimized STM32F407 core reduces the pure computational cold start down to just 1.2 ms, chipping away half a millisecond from the total loop. More importantly, it offers huge CPU and memory headroom.

Future Outlook:
The final goal is to offload the 3rd order S-curve smoothing entirely to the internal FIR filters of the Minas A6 drives, and route the drive's hardware Position Complete digital output back to the Smoothie endstop pin to handle instantaneous hardware-level settling control on M400.

The firmware is currently undergoing stability testing. If the community is interested, I will share the source code and configuration files once the tests are completed.

вторник, 18 августа 2026 г. в 11:53:08 UTC+3, ORIS ORIS:

[Luke Bayes]

I can't speak for anyone else, but I am definitely interested in seeing more of this exploration.

Love what you're sharing so far.

Thank you!

Luke Bayes

To view this discussion visit https://groups.google.com/d/msgid/openpnp/5bd4aa17-b52a-41a9-ac31-8bb8ff2a4c48n%40googlegroups.com.

[vespaman]

Yes, please make your fork available.

And I think it would also be good if you could document also your settings for the Simulated3rdOrderControl settings, as a starting point for anyone else taking this route.

When I wrote the serial dma driver (which then made it into Jans fork (if I remember correctly, he added proper support for using another UART of the stm32, to fit his machine)), I spent some  days trying out Simulated3rdOrderControl, but it felt so sluggish (I guess this is what you have identified and fixed), that I decided to park that, and come back to it later, so it is interesting to see that you may have it working. 

I have a similar (but simpler) setup, but not with real servo, just external closed loop stepper drivers that I also route back the 'in place' signal to the board.

The thing I'd be most interested in picking up, is motion blending between Z and X/Y, in order to shave some ms off during pick and perhaps place.

- Micael

[ORIS ORIS]

Hi Micael,

The attached logic analyzer capture demonstrates the system operation under a dense command stream using Simulated3rdOrderControl.

As shown in the chart, processing a high volume of motion segments is handled via a gate mechanism in the planner. The motion gate opens and triggers physical execution based on whichever condition occurs first: the arrival of the second motion command in the buffer, an explicit M400, or a user-defined timeout.

The capture shows the direct relationship between the RX/TX data stream (including the decoded M400 command), the state of the hardware RTS flow control line, and the generation of the STEP pulses. Hardware flow control plays an important role in maintaining serial line stability during these peak loads.

Please note that this specific test pattern represents an extreme benchmark scenario utilizing around 100 micro-segments to stress the parser and test communication stability. In standard production and normal machine operation, such heavy fragmentation is not required.

Once the ongoing stability tests are fully completed, I will make the fork repository public and share the exact configuration settings here.

пятница, 28 августа 2026 г. в 08:42:10 UTC+3, micael....@gmail.com:

[vespaman]

Hi Oris,

Thanks for the picture, now it is clear to me what you are chasing.

Looks like you have made some improvements! 

Have you pinned down the remaining 2.3-ish ms? Is this calculation time for the step pulse generation, or is this something like the step ticker round trip delay etc.

 - Micael

[ORIS ORIS]

Hi Micael,

Since the RX signal is captured directly from the MCU’s UART input pin, this duration represents the pure time spent on parsing, look-ahead calculations, and motion planning.

The latency varies depending on what immediately follows the first motion command:

• If a second consecutive motion command arrives, the total processing time is around 2.3 ms.
• If an M400 command follows, this time drops by approximately 1.0 ms. This reduction happens because the planner doesn't need to compute junction blending or look-ahead optimizations for merging two separate movements. In this case, the clean cold-start execution latency of the MCU is down to just about 1.2 to 1.4 ms.

As another interesting observation on the capture, I also mapped the DIR (Direction) pin. As you can see, the DIR line is actually set much earlier—about 1.0 ms before the very first STEP pulse appears.

There are still a few ideas for further optimization to shave off some microseconds from this cold-start window. For instance, we could refactor the core G-code parsing approach to minimize redundant function calls during multi-axis coordinate processing.

However, pursuing this yields diminishing returns and has no practical impact on machine throughput. I want to express my gratitude to everyone who contributed to the original forks and codebases I used as a baseline. Their hard work on the underlying optimization and motion architecture is truly amazing. I have merely added a few finishing touches to tailor it for extreme OpenPnP performance.

суббота, 29 августа 2026 г. в 10:58:31 UTC+3, micael....@gmail.com: