Main Controller Board Functional Test

General Discussion
1

Basic Information:

Printer Model: N/A
MCU / Printerboard: Custom Main Controller Board
Host / SBC: rPi CM4/CM4 Equivalent
klippy-KGB_XY_Stepper_Test.log (150.5 KB)

I’m about to have some custom boards manufactured and tested. I’m working through the Functional Test Requirements right now.

2025.01.06 - KGP_4x2209-Rev_7-NoBackground
2025.01.06 - KGP_4x2209-Rev_7-NoBackground1247×765 275 KB

The expectation is that the boards will be inserted into a test fixture with Pogo Pins to the different interfaces followed by booting Klipper/Moonraker/Mainsail and execute a macro that runs through tests that provide basic exercising of the hardware.

The boards have the following features:

  1. Socket for Raspberry Pi CM4 (or equivalent) with Raspberry Pi 40 Pin IO header, CSI/DSI, USB 2.0, Ethernet and HDMI IO
  2. STM32G0B1 MCU
  3. 4x TMC2209 controlled serially with DIAG pins connected
  4. 2x 15A Heater Drivers with Thermistor Inputs (which have 4.7k Pull ups)
  5. 5x Endstop Sockets
  6. 4x Fan/LED Strip Drivers
  7. 2x NeoPixel Drivers/outputs
  8. Microfit CAN Interface
  9. 3Pin Inductive Probe Interface
  10. 5Pin BL Touch Header
  11. 6Pin ADXL345 Interface
  12. I2C Interface
  13. EXP1/EXP2 Header

I have a pretty good idea for many of these interfaces but there are a couple that I’m not sure of and I’m looking for ideas.

The first one to work with are the TMC2209 stepper motor drivers. The best way to test them is to connect them to motors and let them run - as they are connected to the DIAG pin, I want to test Sensorless Homing as this will test essentially all the functionality of the chip as well as connections to it (ie the EN, DIR, STEP, UART and DIAG pins).

The easiest hardware to do the test is a simple base on a stepper motor that has a post that a striker arm, mounted to the stepper output shaft will collide with:

2025.02.22 - Stepper Test
2025.02.22 - Stepper Test1743×1288 107 KB

I’m thinking that after the sensorless homing is complete, the striker arm will come into contact with a momentary on switch, inductive sensor or BL Touch to test that interface’s functionality. But, that’s the next steps.

As can be seen in the attached klippy.log, I have set up a simulated printer and can run homing on X & Y using sensorless homing (with the striker arm coming into contact with the base’s post).

The question is, how can I repeat this test for the other two stepper motor drivers (not labeled “X” or “Y”)?

I don’t see any published console commands to do this and I can’t find macro hardware interfaces that will allow me to do this. I don’t want to load a new printer.cfg as that takes time and will require a higher level of service than somebody that just presses a button to start a test and waits for the results (in displayed LEDs/Neopixels).

I don’t mind writing code but I would like a direction to look in.

Thanx!

2 Likes
2

Sorry, no idea.
While sensorless homing should work for Z as well (just not recommended in operation), it would give you an additional [stepper z] to work with, but still leaving one unsolved.

MAYBE, @dmbutyugin’s cool addition of a flexible cartesian kinematic could do something here. See New generic_cartesian kinematics (incl. CoreXYU/CoreXYUV, generic IDEX and AWD) and [kinematics] Generic Cartesian kinematics implementation by dmbutyugin · Pull Request #6815 · Klipper3d/klipper · GitHub

My understanding is that Klipper only works with one endstop per axis. This would mean you need to define one axis per stepper to test.