Welcome to the Pick (𝝅𝑐𝑘) project!

Pick (𝝅𝑐𝑘) is a spinoff of Klipper that focuses on Pick and Place machines.

That is:

• support for extra axes (working M114)
• USB Power Delivery (CH224Q configurable over i2c) for a slim toolhead board
• central endstop
• support for pumps, valves, and pressure sensors, not just by reusing features related to hotend/hotbed temperature (todo)
• feeders control (servo for now)

more to come.

Features

Kinematics

Rotary axes for Pick and Place toolhead shall be implemented using `MANUAL_STEPPER' command it's good to put it in a "startup macro" like this

[delayed_gcode init_axes]
initial_duration: 0.1
gcode:
    MANUAL_STEPPER STEPPER=stepper_a GCODE_AXIS=A LIMIT_VELOCITY=5000 LIMIT_ACCEL=3000
    MANUAL_STEPPER STEPPER=stepper_b GCODE_AXIS=B LIMIT_VELOCITY=5000 LIMIT_ACCEL=3000
    RESPOND PREFIX='info' MSG='initializing A and B axes: {printer.toolhead.position}'

Of course steppers need to be defined in configuration file, like this:

[manual_stepper stepper_a]
step_pin: toolhead:A_STEP
dir_pin: !toolhead:A_DIR
enable_pin: !toolhead:A_EN
#endstop_pin: ^toolhead:A_STOP
microsteps: 16
full_steps_per_rotation: 200
rotation_distance: 360
# position_min:-360
# position_endstop: 0
# position_max: 360

(this setup treats degrees like millimeters, speeds and accelerations need to be adjusted to match motor.)

some effort has been made to make those steppers show up and be acted upon in relevant gcode commands so OpenPNP can see and use them. Maybe some deeper integration into kinematics will be done in future, but it's good enough for now.

Central Endstop

Central endstop is a feature that allows you to put endstop not at ends of axes but somewhere in (near) the middle. Homing will cause the stepper to move in a positive direction if endstop is in triggered state in current position and in negative direction if it's open
it works best with optical (either slot or reflective) sensors.
original puropse of this feature is a z-axis of pick and place machine in configuration known as 'Peter's Head'.

only implemented for CoreXY kinematics for now, (ask if you need others)

USB Power Delivery

Intended for a slim toolhead mcu board with only one cable going to it (and vacuum pipe). 20V@3A is well enough to drive motors of 2 rotary axes, z axis, and some auxiliary functions. Nema8 are rated at 0.5A. currently only CH224Q configurable over i2c controller is supported

Module provides 3 gcode commands:

• PD_CAPS Dumps PD Source Capabilities: available power profiles (PDOs)
• PD_SET VOLTAGE=<value> Request voltage fromm supply (charger)
• PD_GET Returns status as a single line of space separated key:value format that can be parsed

This layout allows flexibility to enable extra power when it's actually needed (use macros).
There can be many instances of this chip configured. I2C address in not configurable so there can be one per i2c bus, but one per controller board is only thing that makes sense, therefore name config section same as relevant mcu and use MCU=<name> param do differentiate between them.

[ch224q_pd toolhead]
i2c_mcu: toolhead
i2c_bus: i2c1e

Pneumatics

Framework very similar to Klipper's heaters is being developed, it's called [pneumatics]. it's intended to exist parallel to heaters/temperature framework instead of reusing it for pressure so you can still use heaters and temperature sensors for whatever reason.

Pressure sensors

Following sensors are supported for now:

• wf100dp i2c sensor (2 variants: 100kpa and 40kpa, if you know scaling parameters for other in that series let me know).
• Analog XGZP6859A series, ranges for several are in klippy/extras/pressure_sensors.cfg, they are named with their respective part number (ie. XGZP6859A100KPGPN33), other can be added with data from datasheet.
• Differential wheatstone bridge based pressure sensors should work too with ADS1115 in differential mode (sensor_pin: ads1:DIFF01) and some config in klippy/extras/pressure_sensors.cfg

Support for more sensors is on the way, along support for pump that can maintain pressure and valves that can monitor pressure.

Sensors can be used as 'standalone' [pressure_sensor my_sensor] analogous to klipper's [temperature_sensor my_sensor], or attached to pump or valve.

Pump

Pump object can be set to maintain pressure in a system, similar to what heater does with temperature. This works really nice if you have pump with reservoir (tank) and separate valves for nozzles. Currently only BanBang algorithm is implemented. cycle_time is hardcoded to report_interval of sensor. Only command for now is SET_PUMP_PRESSURE PUMP=<name> TARGET=<value> config looks like this:

[pressure_pump pump]
gcode_id: PUMP
pump_pin: PUMP_pin
hardware_pwm: False
max_power: 1
control:watermark
#sensor config part
sensor_type: XGZP6859A100KPGPN33
sensor_pin: gpio29
adc_voltage: 3.3
offset: -2

Valve

Valve is rather simple object that (for now) operates like a binary output_pin but lets you configure kick_start_time during which max_power will be supplied (to force valve to open), after which switches to hold_value so solenoid doesn't overheat. It can contain pressure sensor config.

There's command to open/close valve: VALVE_SET VALVE=<gcode_id> VALUE=[0|1|ON|OFF|OPEN|CLOSE] and to read its status and value of attached sensor: VALVE_GET VALVE=<gcode_id>, response looks like this: <gcode_id>:<value(%.2f)> OPEN|CLOSED

Config looks like this:

[pressure_valve LEFT]
pin: toolhead:VALVE1
hardware_pwm: True
max_power: 1.0
hold_value: 0.75
kick_start_time: 0.2
#optional sensor
sensor_type: WF100DPZ1BGS6DT
i2c_mcu: toolhead
i2c_bus: i2c0e
# sleep_time: 0.1250s
offset: 0.4

Webhooks

gcode/session

This endpoint just like gcode/script allows one to run a series of G-Code commands.

However, unlike like gcode/script if the G-Code command produces terminal output, that output is provided in the response.

For example: {"id": 123, "method": "gcode/session", "params": {"command": "M114"}} might return {"id":123,"result":{'output': ['X:0.000 Y:0.000 Z:0.000 E:0.000 A:0.000 B:0.000', 'ok']}}

No special distinction for error messages is done at response format, just parse output like it would came from terminal.

Same considerations regarding queuing and delay as for gcode/script apply.

Miscellaneous

• Overall brightness of Neopixel strip is configurable.
• Errors in gcode responses are more pronounced and easier to parse: Error: instead of !!