Eddy connection, Auto-Z-Calibration, OS Image infos

[hannpet]

I am inclined to buy a Edd probe and mod my toolhead.
What I don't 🙂 like is the need to route another USB cable through the umbilical.

I had an idea how to circumvent this:
There exist mini PCB's called USB extenders on AliExpress, which function as a 1 to 2 USB hub (they're sized like 1.5x2cm). The 5V could be taken from the UART port of the toolboard I suppose. I think that would be a convenient way to connect the Eddy Probe, if it works!

The second thought I'm having is about the Sovol Pressure-Sensor: I'm afraid I'm sadly not capable enough to pull that off, but it would be super awesome for the Z-Auto-Calibration script to probe the Eddy directly over the sensor.... I think that would be a perfect thing to have as it would enable superfast bedleveling with always correct z height.
If somebody digs into the Sovol pythonscript and figures it out, I'm sure there would be a bunch of donations 😆

Third thing... I found it's possible to use the cb1 Armbian distro for the OS. No config modifications at all needed.. its a newer Debian and a newer Kernel with much less error messages in the dmesg log... seems perfect to use, only small problem is I'm running from SD card, the emmc seems not to work (but I much prefer SD because it's more convenient).

That was just a little feedback, thanks for the great project!

[ss1gohan13]

There exist mini PCB's called USB extenders on AliExpress, which function as a 1 to 2 USB hub (they're sized like 1.5x2cm). The 5V could be taken from the UART port of the toolboard I suppose. I think that would be a convenient way to connect the Eddy Probe, if it works!

Extenders are only that, extensions. You are referring to a USB hub, which is needed, to divide the USB signal properly. In theory, you can pull the 5V from the UART connection for power, but you need a dedicated hub to divide the signal properly between USB devices.

The second thought I'm having is about the Sovol Pressure-Sensor: I'm afraid I'm sadly not capable enough to pull that off, but it would be super awesome for the Z-Auto-Calibration script to probe the Eddy directly over the sensor.... I think that would be a perfect thing to have as it would enable superfast bedleveling with always correct z height.
If somebody digs into the Sovol pythonscript and figures it out, I'm sure there would be a bunch of donations 😆

The pressure sensor is not needed with Eddy because Eddy will auto config the Z, but requires your time, patience, and configuration. You can free the pin connection and use it for an endstop.

Third thing... I found it's possible to use the cb1 Armbian distro for the OS. No config modifications at all needed.. its a newer Debian and a newer Kernel with much less error messages in the dmesg log... seems perfect to use, only small problem is I'm running from SD card, the emmc seems not to work (but I much prefer SD because it's more convenient).

In theory, all CB1 images should work. At the time of writing the document, it was best suited to use the bare min installation to make sure there were no other issues with installation. I would be interested to hear if it helps, or fixes, the MCU/CPU overload issues a lot of klipper users have been experiencing.

[hannpet]

Thanks for the reply!

This is the USB board I was talking about:
https://a.aliexpress.com/_EwZ76S1
I'm pretty sure it's a hub!

About the Eddy: Maybe you misunderstood what I meant... right now, the stock probe is tested exactly over the pressure sensor "metal button-plateau", which yields with the prwssure measurement the knowledge how long the nozzle is. I was suggesting to instead home the EDDY over that metal pressure-sensor pin and thus again yield the exact nozzle-length as a result (given again the pressure measurement of the nozzle). It's about automating the eddy-hight to nozzle-tip measurement.

[ss1gohan13]

About the Eddy: Maybe you misunderstood what I meant... right now, the stock probe is tested exactly over the pressure sensor "metal button-plateau", which yields with the prwssure measurement the knowledge how long the nozzle is. I was suggesting to instead home the EDDY over that metal pressure-sensor pin and thus again yield the exact nozzle-length as a result (given again the pressure measurement of the nozzle). It's about automating the eddy-hight to nozzle-tip measurement.

Again, the pressure sensor is not used with Eddy, at all. Eddy takes care of it's Z by itself. To put this bluntly, it cannot be done.

[hannpet]

About CPU/MPU overload issues... I haven't had them, but I have to say that I did not get to actually print a lot (yet). So those things might show up after some hours of printing,

[hannpet]

Ok, never mind... there is nothing that stops anyone to measure the distance between eddy and pressure sensor-plateau with the eddy itself. It's a metal knob, and the eddy is exactly for this kind of measurement 🙂
And yes, this has to be implemented in the python code of the sovol addon script. I'm very much aware that this is not implemented right now. It was just a suggestion that it would be cool to have... maybe I'll try to hack on the code.

[ss1gohan13]

Ok, never mind... there is nothing that stops anyone to measure the distance between eddy and pressure sensor-plateau with the eddy itself. It's a metal knob, and the eddy is exactly for this kind of measurement 🙂 And yes, this has to be implemented in the python code of the sovol addon script. I'm very much aware that this is not implemented right now. It was just a suggestion that it would be cool to have... maybe I'll try to hack on the code.

Please bring this up to the btt team.

[Rappetor]

I am inclined to buy a Edd probe and mod my toolhead. What I don't 🙂 like is the need to route another USB cable through the umbilical.

I had an idea how to circumvent this: There exist mini PCB's called USB extenders on AliExpress, which function as a 1 to 2 USB hub (they're sized like 1.5x2cm). The 5V could be taken from the UART port of the toolboard I suppose. I think that would be a convenient way to connect the Eddy Probe, if it works!

The second thought I'm having is about the Sovol Pressure-Sensor: I'm afraid I'm sadly not capable enough to pull that off, but it would be super awesome for the Z-Auto-Calibration script to probe the Eddy directly over the sensor.... I think that would be a perfect thing to have as it would enable superfast bedleveling with always correct z height. If somebody digs into the Sovol pythonscript and figures it out, I'm sure there would be a bunch of donations 😆

Third thing... I found it's possible to use the cb1 Armbian distro for the OS. No config modifications at all needed.. its a newer Debian and a newer Kernel with much less error messages in the dmesg log... seems perfect to use, only small problem is I'm running from SD card, the emmc seems not to work (but I much prefer SD because it's more convenient).

That was just a little feedback, thanks for the great project!

usb
Hey there! Thanks for your suggestions. There has been some talk before on discord about such a small usb hub but nobody has tried it as of yet. Would be very interesting to see for sure. Think the biggest issue might be if the uart port can supply enough power (for both hub and Eddy). It might just work, who knows! If you give it a try please let us know if it works or not. It would be awesome not having to run the whole usb cable back to the mainboard.

auto z calibration
About the pressure sensor/auto z calibration, since I fixed the script for mainline klipper I'm already familiar with it. And I think it's quite possible to get it working with the Eddy sensor (as it's also an inductive probe, so should be able to probe the pressure sensor).

I might give it a try myself later but at the moment time is limited so can't look at it quickly. Some pointers if you were to experiment yourself with the z_offset_calibration.py script:

1. At line 28 is the reference to the probe via self.probe = probe. We must reference the eddy current probe here, so in pseudo code self.probe = eddy_current_probe. So then it can be used later in the script. Just maybe it will still support the function self.probe.run_single_probe()
   (this was, amongst other things, the change I had to implement to get the script working again. Klipper changed the way probing worked and 'run_single_probe' was a nice helper function that was also introduced).
2. Change the coordinates of the probing. This is actually set in the [z_offset_calibration] configuration as endstop_xy_position:289,361. Those x,y have to be changed in order to get the Eddy properly above the pressure sensor.
   (This is used at line 92 for the 'manual_move()' and the actual inductive probe of the pressure sensor is done at line 94)

This might actually be it already to get it working (especially if the eddy current probe also support the single_probe() function). But to be honest I haven't missed the auto_z_calibration one bit since I installed the Eddy (and after all those paper tests for the temp drift calibration I'm afraid I'm now faster in paper testing a new z offset than the auto z script 😛 ).

However! If we could use that pressure sensor to automate that temperature drift calibration process.. now you're talking! 😄

armbian cb1
I'll give this a try this weekend or next week since it seems worth checking out for sure. Got myself an sd-card extender so I dont have to lift the printer to change the sd-card anymore, so hopefully this will be a lot easier once that gets here. It sounds promising but we have to check if all the functionality is still there. Maybe it's even more slimmed down, at least the IOT image is a lot smaller. I don't suppose the dtb file (sun50i-h616-sovol-emmc.dtb) can be used with this (have you tried that?) since it's a newer version of Debian..

[hannpet]

Hey Richard, thanks for the elaborate reply, appreciate it!

usb
It might just work, who knows! If you give it a try please let us know if it works or not. It would be awesome not having to run the whole usb cable back to the mainboard.

I'm waiting for the AliExpress delivery, then I'll try to hook it up. I thought about the power requirement too, I guess it's worth a try.

auto z calibration
However! If we could use that pressure sensor to automate that temperature drift calibration process.. now you're talking! 😄

That would indeed be awesome, it would enable a lot of people to install the eddy without hassle.

armbian cb1
Got myself an sd-card extender so I dont have to lift the printer to change the sd-card anymore

I'm about to order that too 😄

we have to check if all the functionality is still there.

true, and keep in mind I didn't get it to boot from emmc.

I don't suppose the dtb file (sun50i-h616-sovol-emmc.dtb) can be used with this (have you tried that?) since it's a newer version of Debian..

I tried to use it, but no that didn't work.

I'm looking forward what we can come up with regarding integrating Eddy with the Pressure-sensor and hooking up the USB-board. Let's make the sv08 a dream to use!

[froh42]

@hannpet I am in the process of a fresh reinstall on emmc. After reading this issue I decided to give the armbian a try using the (minimal) Armbian_24.8.1_Bigtreetech-cb1_bookworm_current_6.6.44_minimal.img.xz image.

It just booted up on my SV08 from an 32GB emmc. I needed to change the dtb file it uses. There's one line in the ambian.txt on the boot partition which specifies something like ftdfile=sun50i-h616-somethingwhatever-sd.dtb.

The "sd" version disables the emmc controller, you need to replace the "-sd" by "-emmc" to enable the controller. (Have a look at the dtb/allwinner directory to see the complete filename - it's in my printer right now, waiting for the armbian setup, so right now I can't look up the specifics)

In any event you need the correct device tree file to be able to use the emmc.

Update: Got the initial armbian config done (with the SV08 connected to my living room TV and USB Keyboard :-) ) and the ambian.txt line for booting armbian from emmc is:

fdtfile=allwinner/sun50i-h616-bigtreetech-cb1-emmc.dtb

[hannpet]

Thanks for the info, great! Do you notice any advantages using the emmc? I admit I'm a bit reluctant to use the emmc, because it feels somewhat inflexible compared to a put-in/out SD card. Anyway, great to hear that the Armbian image seems to be working fine.

[LexiconCode]

Thanks for the info, great! Do you notice any advantages using the emmc? I admit I'm a bit reluctant to use the emmc, because it feels somewhat inflexible compared to a put-in/out SD card. Anyway, great to hear that the Armbian image seems to be working fine.

SD cards are slower and more importantly prone to failure compared to emmc

[hannpet]

SD cards are slower and more importantly prone to failure compared to emmc

Yeah, I just never encountered a failed SD so far.. and the speed depends mostly on the price of the card. For me, the convenience therefore beats the emmc 10x, but that's just my very subjective preference 😉