(fix)boards: Prusa Einsy corrections - #144
Conversation
corrections to Prusa Einsy pinnout to include/correct (spi, endstops, board temperature sensor) pins.
|
Warning Review limit reached
More reviews will be available in 35 minutes and 3 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe PR updates the Prusa Einsy board configuration to use software-based SPI for stepper motor communication. The board definition switches from hardware SPI to software SPI with explicit pin mappings, motor slots are extended with software SPI pin assignments, and redundant endstop/diagnostic pins are cleared. The configuration file applies these definitions with reformatted pin aliases and adds onboard temperature sensor monitoring. ChangesPrusa Einsy Software SPI and Temperature Sensor Configuration
Sequence Diagram(s)No sequence diagrams are applicable. These changes are configuration-only updates to pin mappings and sensor definitions without multiple component interactions or control flow changes. Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
configuration/boards/prusa-einsy/board-definition.json (1)
21-32:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winCritical: Duplicate JSON key
stepperSPI.The JSON object contains two
stepperSPIkeys (lines 21-25 and 26-32). This violates the JSON specification. JSON parsers will either reject this file or silently use only the last occurrence, ignoring the hardware SPI definition.Remove the first
stepperSPIdefinition (lines 21-25) since the intent is to switch to software SPI.🔧 Proposed fix
- "stepperSPI": { - "hardware": { - "bus": "spi" - } - }, "stepperSPI": { "software": { "sclk": "PB1",🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@configuration/boards/prusa-einsy/board-definition.json` around lines 21 - 32, There are two duplicate JSON keys named "stepperSPI" (one containing "hardware": { "bus": "spi" } and the other containing "software": { "sclk": "PB1", "mosi": "PB2", "miso": "PB3" }); remove the first hardware-style "stepperSPI" entry so only the intended software SPI block remains, or if any hardware fields must be preserved, merge them into a single "stepperSPI" object that contains only the required "software" properties (sclk, mosi, miso) and no duplicate keys.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@configuration/boards/prusa-einsy/board-definition.json`:
- Line 40: Replace the string values "null" for the JSON key endstop_pin with a
real JSON null (i.e., endstop_pin: null) for the X, Y and Z motor slot objects
so consumers treat the pin as absent/disabled; locate the occurrences of the
endstop_pin property in the board-definition JSON (currently set to the string
"null") and either change the value to null (without quotes) or remove the
endstop_pin field entirely for those motor entries (X, Y, Z) to reflect a
disabled/absent endstop.
- Around line 33-81: The motorSlots entries X, Y, Z and E0 are missing the
required uart_pin field per the motor-slot schema; update each slot object in
the motorSlots map (keys "X", "Y", "Z", "E0") to include a uart_pin property
(set to the appropriate UART pin name or null if unused) ensuring the value type
matches the schema (string or null) so the board-definition validates.
In `@configuration/boards/prusa-einsy/config.cfg`:
- Around line 42-46: The [temperature_sensor einsy_board] block uses sensor_pin:
PF6 which is not a Prusa Einsy onboard thermistor ADC input; change sensor_pin
to a correct onboard ADC pin (e.g., PF0, PF1, PF2 or PF3 depending on which
thermistor/probe is wired) in the section and verify the chosen pin matches your
board wiring and ADC mapping. Also confirm sensor_type: TDK NTCG104LH104JT1 is
supported by your firmware (Klipper) and matches the actual installed thermistor
curve; if you must keep PF6, replace the assumption of an onboard sensor by
wiring a proper external voltage divider and ADC input and update the config to
reflect that hardware change. Ensure both sensor_pin and sensor_type are
consistent with the physical wiring and supported sensor definitions.
---
Outside diff comments:
In `@configuration/boards/prusa-einsy/board-definition.json`:
- Around line 21-32: There are two duplicate JSON keys named "stepperSPI" (one
containing "hardware": { "bus": "spi" } and the other containing "software": {
"sclk": "PB1", "mosi": "PB2", "miso": "PB3" }); remove the first hardware-style
"stepperSPI" entry so only the intended software SPI block remains, or if any
hardware fields must be preserved, merge them into a single "stepperSPI" object
that contains only the required "software" properties (sclk, mosi, miso) and no
duplicate keys.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: eb7764f7-3ffa-4528-801b-bcf4e971e99d
📒 Files selected for processing (2)
configuration/boards/prusa-einsy/board-definition.jsonconfiguration/boards/prusa-einsy/config.cfg
| "cs_pin": "PG0", | ||
| "endstop_pin": "PB6", | ||
| "diag_pin": "PK2" | ||
| "endstop_pin": "null", |
There was a problem hiding this comment.
Critical: Use JSON null instead of string "null" for endstop_pin.
Lines 40, 52, and 64 set endstop_pin to the string "null" instead of the JSON null value. This will cause downstream consumers to treat "null" as a literal pin name rather than an absent/disabled pin.
Change "endstop_pin": "null" to "endstop_pin": null (without quotes) or remove the field entirely if null pins should be omitted.
🔧 Proposed fix
"cs_pin": "PG0",
- "endstop_pin": "null",
+ "endstop_pin": null,
"diag_pin": "PK2",Apply the same fix to lines 52 and 64 for the Y and Z motor slots.
Also applies to: 52-52, 64-64
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@configuration/boards/prusa-einsy/board-definition.json` at line 40, Replace
the string values "null" for the JSON key endstop_pin with a real JSON null
(i.e., endstop_pin: null) for the X, Y and Z motor slot objects so consumers
treat the pin as absent/disabled; locate the occurrences of the endstop_pin
property in the board-definition JSON (currently set to the string "null") and
either change the value to null (without quotes) or remove the endstop_pin field
entirely for those motor entries (X, Y, Z) to reflect a disabled/absent endstop.
| [temperature_sensor einsy_board] | ||
| sensor_pin: PF6 | ||
| sensor_type: TDK NTCG104LH104JT1 | ||
| min_temp: -10 | ||
| max_temp: 70 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Prusa Einsy Rambo board temperature sensor pin PF6 thermistor type
💡 Result:
On the Prusa Einsy Rambo board, the pin labeled PF6 (Atmel ATmega2560 Analog Pin 6) is not a dedicated thermistor input [1]. According to the official Einsy Rambo board schematics and documentation, thermistors for the hotend, heatbed, and PINDA probe are connected to dedicated analog pins PF0 (ADC0), PF1 (ADC1), and PF2 (ADC2), with an additional thermistor circuit often associated with the Z-probe on pin PF3 (ADC3) [1][2]. Pin PF6 is a general-purpose analog input pin [1]. While it is physically present on the processor and can be accessed on the board (often via spare headers), it does not have a hardwired thermistor circuit (such as a voltage divider with a pull-up resistor) on the PCB by default [3][4]. If you intend to use PF6 for a temperature sensor, you would need to externally construct the necessary voltage divider circuit—typically requiring a 4.7k ohm pull-up resistor to 5V—to interface with a standard NTC thermistor [3]. Because the pin is not hardwired for a thermistor, there is no fixed "thermistor type" associated with it; the type would be determined by the sensor you choose to connect and the corresponding sensor definition in your printer's firmware configuration [2]. Most Prusa printers utilize 100k ohm NTC thermistors (typically NTC 3950 or EPCOS 100K) for temperature sensing, which would be the standard expectation if you are attempting to add an additional sensor [2].
Citations:
- 1: https://wiki.reprap.org/wiki/EinsyRambo_development
- 2: https://reprap.com/wiki/EinsyRambo
- 3: https://fr.scribd.com/document/436203765/Einsy-Rambo-Schematic
- 4: https://raw.githubusercontent.com/ultimachine/Einsy-Rambo/1.1a/board/Project%20Outputs/Schematic%20Prints_Einsy%20Rambo_1.1a.PDF
Fix Einsy temperature sensor config: PF6 is likely not the onboard thermistor input
- On the Prusa Einsy Rambo,
PF6is not a dedicated thermistor input; onboard thermistor circuits are on other analog pins (commonlyPF0/PF1/PF2, with additional probe/Z wiring often involvingPF3). UsingPF6would require an external voltage-divider circuit rather than assuming it’s the onboard sensor. - Ensure
sensor_type: TDK NTCG104LH104JT1matches the actual installed thermistor/resistance curve used with the pin you select; otherwise temperature readings will be incorrect (and Klipper support for that exactsensor_typestring should be checked against the available sensor definitions/config).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@configuration/boards/prusa-einsy/config.cfg` around lines 42 - 46, The
[temperature_sensor einsy_board] block uses sensor_pin: PF6 which is not a Prusa
Einsy onboard thermistor ADC input; change sensor_pin to a correct onboard ADC
pin (e.g., PF0, PF1, PF2 or PF3 depending on which thermistor/probe is wired) in
the section and verify the chosen pin matches your board wiring and ADC mapping.
Also confirm sensor_type: TDK NTCG104LH104JT1 is supported by your firmware
(Klipper) and matches the actual installed thermistor curve; if you must keep
PF6, replace the assumption of an onboard sensor by wiring a proper external
voltage divider and ADC input and update the config to reflect that hardware
change. Ensure both sensor_pin and sensor_type are consistent with the physical
wiring and supported sensor definitions.
1 participant
corrections to Prusa Einsy pinnout to include/correct (spi, endstops, board temperature sensor) pins.
Summary by CodeRabbit
New Features
Configuration