Close
0%
0%

Xeltri — Pick-and-Place Control Board

A 3-core board (MPU + MCU + FPGA) for a DIY desktop pick-and-place machine. WIP.

Similar projects worth following
106 views
0 followers
This project is a main controller board built for a desktop pick-and-place (PnP) machine. The three cores — STM32H745XIH6 (MCU), XC7A35T-2CSG325C (FPGA), and V851S (MPU) — are locked in and work together. Expansion I/O so far: PCIe 2.1 ×2 (in a PCIe ×4 slot, wired to the FPGA) and a microSD card slot. Everything else is still TBD. The board is designed in KiCad 9.

You can check out the project on GitHub.

This board is designed for my pick-and-place machine. It might also work on an FDM 3D printer, because in my plan the PnP machine is derived from a box-style printer (for example a Voron). I am not sure yet whether that part is fully feasible.

Why I'm building this:
One day I had to place a lot of 0603 SMD parts onto a PCB with tweezers. It was exhausting. Later boards may use 0402 as well. Sending a small batch (two or three boards) to a PCBA house costs too much. I wanted to buy a pick-and-place machine, but commercial machines are far beyond my budget, so I decided to build one myself. When I looked at open-source PnP machines, most of them were flat 2D layouts. With many feeders they take too much desk space. So I decided to build a box-style pick-and-place machine from scratch. That is why this project exists.

Hardware:
The three cores are STM32H745XIH6 (MCU), XC7A35T-2CSG325C (FPGA), and V851S (MPU).

I chose this trio because I want mixed alignment: pure optical alignment for simple parts (0805, 0402, and similar packages), and a vision camera (OpenCV-style) for complex parts. I also want up-looking / down-looking cameras plus on-device AI for machine-health checks — that is why V851S is in the mix.

I am using pure optical alignment on simple parts because I want industrial on-the-fly ("flying shot") speed, and the vision hardware that can actually do that is far too expensive. Optical alignment is much cheaper, but it needs real-time performance. The machine is meant to be a box-style CoreXY so it takes less floor space (like a Voron printer). The box-type feeders work like a small parts warehouse: during a job, parts are brought down to the bottom and dispensed from there. The moving head can also travel to a zone tens of centimeters above the work platform to change tools (nozzles and other accessories). That means a lot of structure and a lot of stepper motors to control. Closed-loop steppers with the servo drive in the motor base are too expensive for me, and the cheap ones are not fast enough. An FPGA can handle that and more — I want the finished machine to be strong, not merely usable. That is how this three-core combination ended up here.

This hardware cannot run OpenPnP smoothly, so I have two approaches:

1. I reserved a PCIe 2.1 ×2 link for another board that would run OpenPnP (it sits in a PCIe ×4 slot, wired to the FPGA). XC7A35T-2CSG325C actually supports PCIe 2.1 ×4, but honestly I am not confident I can make that work yet. So I will not aim that high for now — maybe later.

2. Another way to measure component offset without OpenCV.

First, a camera detects the part (the camera is connected directly to the MPU). I have two design options; I prefer the second. Both use a small AI model to detect orientation (0°, 90°, 180°, or 270°). Everything below happens after Step 0.

Here are the actual steps (flowchart first, then the explanation):

① The nozzle picks up the part and moves to a laser light curtain near the feeder (light curtain 1).

② When light curtain 1 is blocked by the part, lock X = c.

③ When the part leaves light curtain 1, lock X = d.

④ Rotate θ degrees.

⑤ When light curtain 1 is blocked by the part, lock X = e.

However, knowing only these values is not enough to calculate the XY and angular offsets. Therefore, when a component type is used on this machine for the first time, it will go through the following steps, and the final results will be saved. 

① The nozzle picks up the part and moves to light curtain 1.

② When light curtain 1 is blocked by the part, lock X = f.

③ When the part leaves light curtain 1, lock X = g. And save |f − g|.

④ Rotate α degrees (this value is small like 0.9 degrees or smaller) and moves to light curtain 1.

⑤ When light curtain 1 is blocked by the part, lock X = h.

⑥ When the part leaves light...

Read more »

  • Log #2 — STM32 power supply

    Shin Lin5 hours ago 0 comments

    After the overall power tree was roughly settled, I started with the MCU power supply. I want the MCU to handle low-level monitoring and management for the whole board.

    I am not using a PMIC for power sequencing. The board has many chips that need different voltages, and some rails are shared. A PMIC would take a lot of board area, and it is hard to find one that matches everything. So I merged rails at the same voltage and use load switches to control power-up.

    Without a PMIC, something still has to control the sequence. I gave that job to the MCU. One reason is that I do not need a complex bring-up path for the STM32 itself: with USB disabled and VREF on the internal reference, it can boot from a single 3.3 V rail. Another reason is that USB is not used on the MCU in my design (USB goes to the V851S). I only need to monitor each rail coming up, so ultra-high precision is not required.

    Current progress: the basic MCU power-on circuit is drawn. Power sequencing control is not in the schematic yet.

    MCU power schematic:

  • Log #1 — Architecture: boot sequencing and the 24 V power tree

    Shin Lin08/20/2026 at 07:05 0 comments

    I did not expect it would take two months before I started posting logs on Hackaday. Since two months have already passed, I will just record what got done in that time.

    After the chip selection was frozen, the first real headache was power-on sequencing. If the FPGA controls the sequence, who sequences the FPGA? Handing it to the MPU did not feel stable enough, and I have not seen people do it that way. So I gave it to the MCU — STM32H745XIH6. With proper protection it can still boot safely and handle emergencies.

    The plan is: the M4 core plus the FPGA watch hardware status for the whole board and the whole machine, and respond. The M7 core runs on its own: signal processing, computation, and logic. In short, the STM32 owns the earliest sequencing.

    Next is power. I plan to feed the whole motherboard from 24 V. First I built a simple protection circuit with a P-MOSFET:

    After that, two TI TPS56637 parts do 24 V → 12 V (for the PCIe slot) and 24 V → 5 V (the board bus). Four SY8843 bucks then make 1.0 V, 0.9 V, 1.5 V, and 3.3 V. From 3.3 V, RT9013-12 / RT9013-15 LDO parts make 1.2 V and 1.5 V.

    Once every rail exists, four TPS22966 load switches, driven by the MCU boot code, bring the different cores up in order.

    Photos of the power tree:

View all 2 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates