No motivation letter here.
Well, I got one Cartographer V3, and I want to run it on the mainline.
So, bootable configs.
The easiest way to flash it is by using the USB and DFU.
Katapult USB/CAN Example
Micro-controller Architecture (STMicroelectronics STM32) --->
Processor model (STM32F042) --->
Build Katapult deployment application (Do not build) --->
Clock Reference (24 MHz crystal) --->
Communication interface (USB (on PA9/PA10)) --->
Application start offset (8KiB offset) --->
USB ids --->
() GPIO pins to set on bootloader entry
[*] Support bootloader entry on rapid double click of reset button
[ ] Enable bootloader entry on button (or gpio) state
[*] Enable Status LED
(PB5) Status LED GPIO Pin
Micro-controller Architecture (STMicroelectronics STM32) --->
Processor model (STM32F042) --->
Build Katapult deployment application (Do not build) --->
Clock Reference (24 MHz crystal) --->
Communication interface (CAN bus (on PA9/PA10)) --->
Application start offset (8KiB offset) --->
(1000000) CAN bus speed
(PA1) GPIO pins to set on bootloader entry
[*] Support bootloader entry on rapid double click of reset button
[ ] Enable bootloader entry on button (or gpio) state
[*] Enable Status LED
(PB5) Status LED GPIO Pin
Klipper USB/CAN make menuconfig
[*] Enable extra low-level configuration options
Micro-controller Architecture (STMicroelectronics STM32) --->
Processor model (STM32F042) --->
Bootloader offset (No bootloader) ---> # Katapult (8KiB bootloader)
Clock Reference (24 MHz crystal) --->
Communication interface (USB (on PA9/PA10)) --->
USB ids --->
Optional features (to reduce code size) --->
[ ] Optimize stepper code for 'step on both edges'
() GPIO pins to set at micro-controller startup
....
[*] Support micro-controller based ADC (analog to digital)
[*] Support communicating with external chips via SPI bus
[*] Support software based SPI "bit-banging"
[*] Support communicating with external chips via I2C bus
[*] Support software based I2C "bit-banging"
[*] Support hardware PWM (pulse width modulation) # Not yet implemented in mainline
[*] Support GPIO based button reading
[ ] Support Trinamic stepper motor driver UART communication
[ ] Support 'neopixel' type LED control
[*] Support measuring fan tachometer GPIO pins
*** LCD chips ***
[ ] Support ST7920 LCD display
[ ] Support HD44780 LCD display
*** Accelerometer chips ***
[*] Support adxl accelerometers
[ ] Support lis2dw and lis3dh 3-axis accelerometers
[ ] Support MPU accelerometers
[ ] Support ICM20948 accelerometer
*** External ADC type chips ***
[ ] Support thermocouple MAX sensors
[ ] Support HX711 and HX717 ADC chips
[ ] Support ADS 1220 ADC chip
*** Other external sensor chips ***
[*] Support ldc1612 eddy current sensor
[ ] Support angle sensors
[*] Enable extra low-level configuration options
Micro-controller Architecture (STMicroelectronics STM32) --->
Processor model (STM32F042) --->
Bootloader offset (8KiB bootloader) --->
Clock Reference (24 MHz crystal) --->
Communication interface (CAN bus (on PA9/PA10)) --->
Optional features (to reduce code size) --->
(1000000) CAN bus speed
[*] Optimize stepper code for 'step on both edges'
(PA1) GPIO pins to set at micro-controller startup
....
Features section same as above
To get a rough idea of the sensor’s resolution distribution.
There are 2.5mm and 3.5mm sensor offsets from the bed.
Less crude graph script
# File name carto_2.5mm.data
0.050000:3246332.946,0.090000:3240873.962,0.130000:3235619.030,
0.170000:3230460.204,0.210000:3225456.210,0.250000:3220565.179,
0.290000:3215833.924,0.330000:3211168.165,0.370000:3206666.099,
0.410000:3202239.178,0.450000:3197979.178,0.490000:3193769.752,
#!/usr/bin/python3
import os
import glob
import matplotlib.pyplot as plt
data_files = sorted(glob.glob("*mm.data"))
plt.figure(figsize=(10, 6))
for filename in data_files:
# Extract postfix from filename (e.g. 30c from "carto_30c.data")
name = os.path.basename(filename).split("_", 1)[1].replace(".data", "")
z_values = []
freq_values = []
with open(filename, 'r') as f:
content = f.read().strip().replace("\n", "")
pairs = [p for p in content.split(",") if p]
for pair in pairs:
z, freq = pair.split(":")
z_values.append(float(z))
freq_values.append(float(freq))
plt.plot(z_values, freq_values, label=f"{name}", marker='.', linestyle='-', linewidth=1)
plt.title("Sensor Frequency vs. Z Height")
plt.xlabel("Z Height (mm)")
plt.ylabel("Frequency (Hz)")
plt.legend(title="File name")
plt.xticks([i / 10 for i in range(0, 450, 10)])
plt.grid(True)
plt.tight_layout()
plt.show()
"""
pairs = re.findall(r'([\d\.]+):([\d\.]+)', data)
Z = [float(z) for z, _ in pairs]
freq = [float(f) for _, f in pairs]
plt.figure(figsize=(10, 6))
plt.plot(Z, freq, marker='.', linestyle='-', linewidth=1)
plt.title("Z vs Frequency")
plt.xlabel("Z mm")
plt.ylabel("Frequency")
plt.xticks(np.arange(min(Z), max(Z) + 1, 2.0))
plt.grid(True)
plt.tight_layout()
plt.show()
Well, that explains why the eddy probe feels unusable with temperature drift with adequate z values, like 2-3 mm (in my opinion, that was adequate).
So, it seems that from a homing/probing perspective, it may make sense to use the lowest Z offset possible and probably calibrate it around some temperature mid-point.
It looks like higher temperature → lower frequency.
And that happens, the MCU frequency is also lower:
But MCU is the source of the frequency for the LDC1612, so the thermal drift can be amplified by the oscillator drift, and so the MCU drift.
Let’s assume my measurements are more or less accurate (they are not precise).
(Probably it would be better to simply heat the carto with a hairdryer, instead of gradually heating the hotend, bed, and rerun of probe calibration).
And calculate the frequency difference for several points:
LDC1612’s datasheet and application manuals (https://www.ti.com/lit/an/snoa950/snoa950.pdf) stated that a change in the IDRIVE current would shift the frequency output.
And we want to avoid hitting the 1.8V.
Because my sensor want IDRIVE 19 at mid-air, 20 at being close to the bed, and 21 when heated, there are data about that.
(With enabled IDRIVE boost).
20 and 21 will hit 1.8v at distance > 4mm.
19 would hit <1.2v at distance ~ 2.5 + 3 mm. Where 2.5 is my current nozzle offset and 3 is z_offset.
G90
G0 X205 Y202.5 Z0
LDC_SET_DRIVE_CURRENT CHIP=carto VALUE=19 # It is a custom command
PROBE_EDDY_CURRENT_CALIBRATE CHIP=carto
It seems insignificant to my taste.
Like, if we do overdrive it a little, it should perform okayish as long as the current is constant and vice versa.
I should say, that increasing the current increase the overall frequency range a little. Not sure if it worth it.
I’ve asked, Richard gave me the V4 pins.
Great kudos to Richard.
It is to be tested, written from what I can guess from pins and configs above:
Katapult USB/CAN Example
Micro-controller Architecture (STMicroelectronics STM32) --->
Processor model (STM32G431) --->
Build Katapult deployment application (Do not build) --->
Clock Reference (24 MHz crystal) --->
Communication interface (USB (on PA11/PA12)) --->
Application start offset (8KiB offset) --->
USB ids --->
() GPIO pins to set on bootloader entry
[*] Support bootloader entry on rapid double click of reset button
[ ] Enable bootloader entry on button (or gpio) state
[*] Enable Status LED
(PA15) Status LED GPIO Pin
Micro-controller Architecture (STMicroelectronics STM32) --->
Processor model (STM32G431) --->
Build Katapult deployment application (Do not build) --->
Clock Reference (24 MHz crystal) --->
Communication interface (CAN bus (on PA11/PA12)) --->
Application start offset (8KiB offset) --->
(1000000) CAN bus speed
(PA3) GPIO pins to set on bootloader entry
[*] Support bootloader entry on rapid double click of reset button
[ ] Enable bootloader entry on button (or gpio) state
[*] Enable Status LED
(PA15) Status LED GPIO Pin
Klipper USB/CAN Example
[*] Enable extra low-level configuration options
Micro-controller Architecture (STMicroelectronics STM32) --->
Processor model (STM32G431) --->
Bootloader offset (8KiB bootloader) --->
Clock Reference (24 MHz crystal) --->
Communication interface (USB (on PA11/PA12)) --->
USB ids --->
[*] Optimize stepper code for 'step on both edges'
() GPIO pins to set at micro-controller startup (NEW)
[*] Enable extra low-level configuration options
Micro-controller Architecture (STMicroelectronics STM32) --->
Processor model (STM32G431) --->
Bootloader offset (8KiB bootloader) --->
Clock Reference (24 MHz crystal) --->
Communication interface (CAN bus (on PA11/PA12)) --->
(1000000) CAN bus speed
[*] Optimize stepper code for 'step on both edges'
(PA3) GPIO pins to set at micro-controller startup
Thanks for your work! I recently acquired Carto V4 and started experimenting with it. In the process I characterized the on-board thermistor against a calibrated thermocouple. For my sample, the thermistor definition is as follows:
[thermistor carto50k]
## Characterized by ReXT3D against T thermocouple
temperature1: 1.15
resistance1: 154540.4
temperature2: 47.3
resistance2: 17425.7
temperature3: 84.4
resistance3: 4367.2
The generic 50k definition was producing 3-6 deg.C error while the above calibrated definition tracks within a fraction of a degree. Again, this is on my sample and I have no way of verifying sample to sample variations.
Coincidentally, under low MCU load the MCU on-die temperature also tracks the thermocouple within a fraction of a degree using this config block:
@MRX8024 has pointed out to me in DM that one can peek at carto code and extract the thermistor definition. I guess it is closer to what you have measured than my above examples:
Where the actual sensor performance can be validated by the SNR output of PROBE_EDDY_CURRENT_CALIBRATE
With a higher frequency, up to 35MHz, I would expect that the noise value mm will be inversely proportional to the input frequency you feed in.
And so, you can report it in the PR above that the frequency output is working.
(and even send your sample config for v4, as a PR).
Those thermistor coefficients do indeed look much closer to what I measured. In terms of R25 and Beta my measurements yield 45.979 kOhm and Beta of 4156.9.
Unfortunately I will not be able to put the Cartographer v4 into action for a bit of time as I need to convert my Voron to CAN on Stealthburner first. I need to finish a redesign to mount the Slice Mosquito with a 3010 fan. I am nearly there…
On a different note, I noticed that after reflashing the Cartographer v4 with mainline Katapult and Klipper, the existing CAN flashing tools do not appear to be able to activate the bootloader for reflashing. The flashtool.py times-out and fails:
Connecting to CAN UUID ************ on interface can0
Sending bootloader jump command...
Resetting all bootloader node IDs...
Detected Klipper binary version v0.13.0-610-g35ace529, MCU: stm32g431xx
Attempting to connect to bootloader
ERROR:root:Flash Tool Error
Traceback (most recent call last):
File "/home/piotr/katapult/scripts/flashtool.py", line 840, in run
await flasher.connect_btl()
File "/home/piotr/katapult/scripts/flashtool.py", line 275, in connect_btl
ret = await self.send_command('CONNECT')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/piotr/katapult/scripts/flashtool.py", line 407, in send_command
raise FlashError("Error sending command [%s] to Device" % (cmdname))
FlashError: Error sending command [CONNECT] to Device
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/piotr/katapult/scripts/flashtool.py", line 1104, in main
await sock.run()
File "/home/piotr/katapult/scripts/flashtool.py", line 850, in run
await flasher.finish()
File "/home/piotr/katapult/scripts/flashtool.py", line 493, in finish
await self.send_command("COMPLETE")
File "/home/piotr/katapult/scripts/flashtool.py", line 407, in send_command
raise FlashError("Error sending command [%s] to Device" % (cmdname))
FlashError: Error sending command [COMPLETE] to Device
Entering the bootloader manually with a double-tap (double-jumper) of the reset pads allows the flash to complete successfully.
I would guess they have some custom checks that do not like mainline firmware.
So you need to flash normal katapult first (through the DFU). I already have one similar report, and flashing normal katapult helps.
I did try all four combinations and the only one that works for me is the Carto supplied Katapult with Carto supplied Klipper. I was not able to get the other three to enter bootloader via CAN. I wonder if perhaps @Esoterical managed to make it work reliably?
