Main Controller Board Functional Test

[mykepredko]

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.

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:

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!

[Sineos]

@mykepredko

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

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.

[mykepredko]

Heya,

I have the solution to testing the TMC2209s using homing.

First off, I followed your note indicating that sensorless homing should work for the Z axis - it does and works fine. To get the fourth TMC2209 tested I added a [dual_carriage] to turn the system into a simulated IDEX printer (which uses all four of the stepper motor drivers).

Now, when a homing operation (ie G28) is initiated, all four stepper motor drivers are exercised with sensorless homing.

Here is the printer.cfg that I came up with for these basic tests:
kgp_tmc2209_homing_test_printer.cfg (4.5 KB)

---

Next step is to trigger the Endstop sensors using N-Channel MOSFETs controlled by the Host’s Raspberry Pi 40pin IO header.

[mykepredko]

I have a simple Digital Input test set up.

It consists of a simple Raspberry Pi hat that consists of five 2N7000 N-Channel MOSFET transistors controlled by the IO pins of the CM4 (or equivalent) on the board. The N-Channel MOSFETs are wired as open drain and are used to act as a switch for the Endstop Digital Inputs.

Here it is in operation, it’s a bit messy but if you look hard, you can see the DIY Raspberry Pi hat and the wires going to the yellow digital input JST HS connectors:

After setting up the Raspberry Pi as a secondary MCU, using the information here:

RPi microcontroller - Klipper documentation

I added definitions for the pins I used for driving the Gates of the N-Channel MOSFETs and then access them from a couple of simple macros that turn them on and off:

[mcu host]
serial: /tmp/klipper_host_mcu

[output_pin hostgpio02]
pin: host:gpio2

[output_pin hostgpio017]
pin: host:gpio17

[output_pin hostgpio022]
pin: host:gpio22

[output_pin hostgpio09]
pin: host:gpio9

[output_pin hostgpio06]
pin: host:gpio6

[gcode_macro resethostgpio]
gcode:
   SET_PIN PIN=hostgpio02  VALUE={0}
   SET_PIN PIN=hostgpio017 VALUE={0}
   SET_PIN PIN=hostgpio022 VALUE={0}
   SET_PIN PIN=hostgpio09  VALUE={0}
   SET_PIN PIN=hostgpio06  VALUE={0}

[gcode_macro sethostgpio]
gcode:
   SET_PIN PIN=hostgpio02  VALUE={1}
   G4 P500                                          
   SET_PIN PIN=hostgpio017 VALUE={1}
   G4 P500                                          
   SET_PIN PIN=hostgpio022 VALUE={1}
   G4 P500                                          
   SET_PIN PIN=hostgpio09  VALUE={1}
   G4 P500                                          
   SET_PIN PIN=hostgpio06  VALUE={1}

Next is to use the Digital Endstops to turn on/off LED Strips on the Fan ports to verify their connection to the MCU as well as provide a test of the Fan drivers.

[Sineos]

Nice solution!