Support for Prusa MK3S+
Original thread in #ratos-development Big thanks to Mikl and blacksmith for chiming in - https://discord.com/channels/582187371529764864/859890291591217162/1082791496295653386. Tagging @cloudhd3d as they were repeatedly mentioned.
Unfortunately I'm not familiar enough with this project to speculate on the processes involved here but I can give my user report.
My MK3S+ has stock Prusa firmware
Setting up a Raspberry Pi 3b+ with RatOS v2.x: v2.0.0-10-g440096b
Had to force skip configurator due to no board detection, ran updates as described in docs, and then ran the INSTALL_PRUSA_MK3S command in console
Klipper started attempting to connect and failing
Various messages in the logs
Let me know if there's any further detail I can provide or questions to answer. Cheers.
189 Replies
conscious-sapphire•2y ago
Hi, did you flash your bootloader? Previously to try to use RatOS, it's a prerequisite https://github.com/PrusaOwners/mk3-32u2-firmware
GitHub
GitHub - PrusaOwners/mk3-32u2-firmware: Updated Atmega 32u2 Firmwar...
Updated Atmega 32u2 Firmware for the Einsy Rambo. Contribute to PrusaOwners/mk3-32u2-firmware development by creating an account on GitHub.
conscious-sapphire•2y ago
@dollatom please let me know if you have flashed your bootloader and also the output of "ls -l /dev/prusa-einsy"
conscious-sapphire•2y ago
should be something like this
conscious-sapphire•2y ago
also would be helpful if you execute this command
udevadm info /dev/ttyACM0
I'm quite interested on the red squared values
conscious-sapphire•2y ago
conscious-sapphire•2y ago
because are the values that will use the udev rules to detect the prusa einsy
so, what I need from your side is:
- Answer to the question about the bootloader, did you flash it?
- execute the "udevadm info /dev/ttyACM0" command
- execute the "ls -l /dev/prusa-einsy" command
conscious-sapphire•2y ago
if you didn't flash the bootloader, flash it following the manual from https://github.com/PrusaOwners/mk3-32u2-firmware
GitHub
GitHub - PrusaOwners/mk3-32u2-firmware: Updated Atmega 32u2 Firmwar...
Updated Atmega 32u2 Firmware for the Einsy Rambo. Contribute to PrusaOwners/mk3-32u2-firmware development by creating an account on GitHub.
conscious-sapphire•2y ago
and repeat the execution of the followings commands
- execute the "udevadm info /dev/ttyACM0" command
- execute the "ls -l /dev/prusa-einsy" command
also, in order to fix the compile & flash issue on the configurator, just edit the file /home/pi/printer_data/config/RatOS/boards/prusa-einsy/compile.sh
just executing this command
sed -i 's/klipper.bin/klipper.elf.hex/g' ~/printer_data/config/RatOS/boards/prusa-einsy/compile.sh
Please let me know about all of this, because with this changes your einsy should be able to be flashed, and also you can going back to the prusa firmware in any moment just flashing it using prusaslicer as always
All of these are there before klipper is flashed, which is a problem for the configurator. It can't talk to marlin.
I can fix this
conscious-sapphire•2y ago
There is a PR
oh lol, i just pushed it 🤦♂️ l
ah yeah there was a bit more needed than what's in the PR so it's fine
configurator will still make it download as .bin, will fix that later
doesn't even get that far because the udev rule identifies the board at all times even when it has marlin on it.
conscious-sapphire•2y ago
does not matter about marlin, I have flash mine to marlin and the serial and vendor remain the same, I think that thos values are on the bootloader
That's a problem
The configurator thinks the board is already flashed in that case
So the whole process breaks
conscious-sapphire•2y ago
not really, because the very first step is to flash the bootloader with the arduino board
We have to be able to identify the board after and only after it has been flashed correctly or it won't work
conscious-sapphire•2y ago
I understand your point
I'm testing the configurator right now from marlin state
👍
We'll need to write a guide with the arduino flashing stuff
for os.ratrig.com
conscious-sapphire•2y ago
conscious-sapphire•2y ago
never ends
but the board is detected
conscious-sapphire•2y ago
conscious-sapphire•2y ago
so the udev rules works, the issue is related with the configurator query
exactly, because there's no klipper
which it shouldn't be at this point
that's the problem
It should only be detected (ie the udev rule shouldn't match before) when klipper is present on the board.
version checking queries klipper on the board. That fails because there's no klipper.
conscious-sapphire•2y ago
If I execute the make and flash script or the prusa-einsy I got this timeout answer
conscious-sapphire•2y ago
but if I go to the klipper folder and execute the make flash
conscious-sapphire•2y ago
conscious-sapphire•2y ago
it's able to flash it
well that's weird!
conscious-sapphire•2y ago
so, the solution should be related with the flash script
Configurator doesn't even get that far, but yes that should be fixed too
the only difference i can see is that the flashing script runs as root. Can you try the following:
?
conscious-sapphire•2y ago
well that makes no sense
conscious-sapphire•2y ago
I think that is not related with that, because I've observed that when I try to flash using the make&flash script de borad got restarted and then the timeout messages start, and when I execute the make flash FLASH_DEVICE=/dev/prusa-einsy, the board just start to flash
flashing script does this:
Which is exactly the same as what you're running
conscious-sapphire•2y ago
I know
But the output and result is completely different. Makes no sense.
conscious-sapphire•2y ago
I will replace the content of the flash_path.sh to directly make flash FLASH_DEVICE ...
Before you do that
Try running flash_path manually
conscious-sapphire•2y ago
I'm going to flash back to marlin again
so
replace the contents of
~/printer_data/config/RatOS/boards/prusa-einsy/flash.sh insteadconscious-sapphire•2y ago
that worked, and the board was running marlin before flash
conscious-sapphire•2y ago
and make-and-flash-mcu.sh or just flash.sh still doesn't work?
conscious-sapphire•2y ago
let me check, I will flash marlin again, and test it replacing the flash.sh content
conscious-sapphire•2y ago
conscious-sapphire•2y ago
But.. it's the same damn thing 😂
only the existing code allows the ratos configuration to be installed in arbitrary environments. That hardcoded path doesn't.
uncomment the script again and do
echo $FLASH_SCRIPT $MCU before the last line, pretty sure it's identical to what you hardcoded right there.conscious-sapphire•2y ago
I know
Man, that's frustrating.
conscious-sapphire•2y ago
I will do some other tests along today
Thanks for putting in the effort man, much appreciated 🙏
conscious-sapphire•2y ago
and I will try to find the "standard" solution
a possible solution could be use avrdude directly I will test it now, in a similar way that's used to flash the prusa firmware
@miklschmidt I don't know why, but I have added a sudo before make flash on the flash_path.sh file and just works
I know does not make sense
conscious-sapphire•2y ago
conscious-sapphire•2y ago
I'll take it lol
conscious-sapphire•2y ago
conscious-sapphire•2y ago
I will try again from the configurator to see the behaviour
Shouldn't hurt anything
👍
conscious-sapphire•2y ago
is there any log about the configurator actions?
conscious-sapphire•2y ago
conscious-sapphire•2y ago
conscious-sapphire•2y ago
So, if you are comming from marlin, the first thing that you have to do from the configurator is to execute the "Flash all connected MCU's"
conscious-sapphire•2y ago
conscious-sapphire•2y ago
after that select the einsy and then will be detected
if you doesn't flash previously configurator will hang waiting for the einsy
/var/log/ratos-configurator.log
sweet!
Hmm.. I think i need to handle errors in the check version step, so that if it doesn't repond as expected you can flash the board instead. Then it should work like regular boards.
That + a guide on os.ratrig.com about how to flash the bootloader on the einsy
That should be good enough to use
conscious-sapphire•2y ago
I will work on the guide, yesterday night I was broke and I fall sleep
haha no worries 😄
I'll take a look at the configurator later today 🙂
conscious-sapphire•2y ago
By now I’m happy, because we are starting to see the light
So i will do the guides for einsy and buddy and wait for more bugs
conscious-sapphire•2y ago
yep, this is the error i need to handle
conscious-sapphire•2y ago
that's why the process stop when you are running marlin
Yeah, it can't check the version on the board because there's no klipper on the board
I had not flashed the bootloader, I was hoping something had changed upstream but I will do that today.
conscious-sapphire•2y ago
apparently we have found the issue, so to solve these are the commands that could help you:
sed -i 's/klipper.bin/klipper.elf.hex/g' ~/printer_data/config/RatOS/boards/prusa-einsy/compile.sh
Yep, I swapped that out. That doesn't touch the bootloader though right? I still need to do that flash. - https://github.com/Prutsium/3D-Druckerplausch-Klipper/wiki/1_Flash_Einsy_USB_bootloader_en
conscious-sapphire•2y ago
sed -i 's/make flash FLASH_DEVICE=$MCU/sudo make flash FLASH_DEVICE=$MCU/g' ~/printer_data/config/RatOS/scripts/flash-path.sh
and the last one is to flash klipper in the first step of the configurator
conscious-sapphire•2y ago
conscious-sapphire•2y ago
yes, you will need to flash de bootloader in order to use klipper
The $MCU should be explicit right, this isn't referring to an env variable I should have set?
conscious-sapphire•2y ago
is explicit sorry
the single quote suggests that as well 🙂
conscious-sapphire•2y ago
I made the change manually and didn't notice about the $
you just need to add the sudo before the make flash o the file flash_path.sh
👍 I've run the seds. I'll head down and flash the bootloader in a few. I can take some pictures of the wiring for a guide if that's useful.
not necessary already fixed this 🙂
just update ratos
Generally i'd like to avoid modifying RatOS files, because that will make moonraker complain
oh well.. you're gonna have to reset it, and that might ruin the githooks etc. Do a
git checkout * and refresh moonraker before updating.
Modifying files is generally bad practice
And i would like to have you test the actual fixes, not the hacks
I thought you had to modify the flash-path.sh script and not the flash.sh of the board.git checkout * in /home/pi? or a subdir?
this.. i will make this change
in the RatOS folder
/home/pi/printer_data/config/RatOS
roger. Good timing, as I'm hooking up to flash the bootloader this instant
RatOS version now v2.x: v2.0.0-11-g94dcec9
just pushed the flash-path change
Update again 😄
🙂
now v2.x: v2.0.0-12-g27ba4d0
Just pushed a change to the configurator, so now when you've fixed the bootloader you should be able to flash the board entirely through the configurator.
obviously you'd need to update the configurator through mainsail first 🙂
I've hooked it up, backed up, and flashed but got verification errors so I'm rebooting and re-flashing as instructed
And success
Yaaaaaay!
Now we just need to add something about the bootloader to the docs
My einsy hookup
And the pi
Can i use those pics for the docs?
I think you already have AVRdude console output so I'll forgo sending that
Yes please, that's why I took them
Awesome, thank you
Also took care to keep the colors consistent with how it's currently documented
Configurator version now v2.x-deployment: v2.0.0-beta2-8-g9056254
Yes that should be the correct one
I have to disconnect my LCD cables to try to fix an unrelated problem so I'm doing that while all this is apart
Going to boot ratos and do the configuration after
👍
Step 1 still spins and the logs look very similar
Should I "Flash all connected MCUs" from the actions menu?
I've done nothing other than skip the wifi setup and select einsy under the control board preparation step
Timed out after a while with this message
Perfect, this is intentional
Then you click the "flash again" button
And you should be presented with 2 options
I did so, it completed
Click automatic flash
YEES
😄
It works!
You're ready to rock 🙂
you guys are fucking great
Thank you for bearing with us 😄
And thanks @cloudhd3d for the work, i appreciate all of y'all!
wowww the dashboard looks cool all populated
I searched the docs but I couldn't find instructions on setting up a webcam?
look up mainsail-crew/crowsnest
Basically you put a crowsnest.conf in the config root (where printer.cfg is) with some settings
Fairly easy to set up
I'll be able to figure it out with that
So much respect y'all
conscious-sapphire•2y ago
Many thanks @dollatom for your patience!!
I also appreciate the opportunity that I have had to contribute to this project
Hey I can pop into another channel if this question is more applicable but I'm now working on bed leveling of course (natural flow of things) and I'm new enough to 3D printing that I don't know if this is me trying to do something nonsensical or a misconfiguration.
It's pretty clear my bed has some slight skew to it and it seems like a mesh should compensate quite well, but when attempting to start a print with a mesh loaded I get an error:
Running a home all seems to crash the carriage unless I unload the mesh and home from that point.
There are user reports of that all over the internet so it seems intended? I'm not sure how to run a leveling calibration print with the mesh applied.
More research suggests none of this is relevant and it's applying a mesh automatically at the beginning regardless.
yea RatOS takes care of all this as part of the START_GCODE
Just setup your slicer according to: https://os.ratrig.com/docs/slicers
Slicer Configuration | RatOS
RatOS comes with STARTPRINT and ENDPRINT macros that you can call directly from your slicers. This way the printer knows how to start a print, and you can there easily switch between slicers without worrying if you changed anything in another slicer.
xenial-black•2y ago
Hi
I am thinking about installing Klipper/RatOS on my Prusa MK3S+.
(Currently using a Pi Zero 2 for Octoprint.)
I already read a bit, but am not sure, if I understood everything correctly. So are the following things true?:
1. This is only a bootloader: https://github.com/PrusaOwners/mk3-32u2-firmware
And when I install it, the rest of the firmware will be like before. And it's compatible with the original Prusa Firmware as well as Klipper firmware.
I need it, because otherwise Klipper Firmware can't be installed on the Prusa Einsy Rambo Board.
It can only be installed over the 6-Pin ISP port of the Einsy Rambo.
2. Usually installing Klipper is like:
- Install Device-Specific Firmware on something like a Pi.
- Install Board-Specific Firmware on the Control Board of the Printer.
- Insert Printer-Specific CFG on the Pi (contains info on what is connected where, e-steps, etc.).
Also a question:
With the currently available firmwares and configs, will everything be supported?
Like the Default-Display, PrusaSlicer-Timer on Display, Sensorless Homing, ABL, Filament Runout Sensor, Silent Mode, etc.?
Is there anything else important I might have overlooked?
Correct on all counts. As for the question, yes all of it is supported currently.
Although i'm not sure about silent mode? Does it do anything besides disable the screen beeps?
RatOS has a "stealth mode" which requires restarting klipper, it puts the drivers into stealthchop mode making them super quiet <100 mm/s
xenial-black•2y ago
Yes, that's exactly, what I meant. Thx for your answer!
Faster than 100mm/s is not possible/safe with StealthChop?
How dangerous is it to flash the bootloader?
Will the board be bricked, when it fails?
And if it works, is it uncritical to switch between the Prusa Firmware and Klipper?
It is but it'll start making more noise than spreadcycle
xenial-black•2y ago
Ah, ok. So probably not worth it.
and you loose 3/4 of your torque with stealthchop
xenial-black•2y ago
Ok. Good to know!
Plus it decreases accuracy significantly
xenial-black•2y ago
Oh, didn't know that.
It's very rare to brick a board this way, you can write a new bootloader if it fails.
And if it works, is it uncritical to switch between the Prusa Firmware and Klipper?Yeah, should be straight forward
xenial-black•2y ago
Do you know, if the ABL will compensate for the magnets, if I use the 7x7 matrix?
In the Prusa Firmware they leave out some points, because the measurement might be flawed as it's too close to the magnets.
I would assume the mesh is already setup to not be affected by the magnets, but that would be a question for @cloudhd3d who implemented MK3s support
xenial-black•2y ago
Ok. Thx!
I just ordered this adapter to flash the bootloader:
https://www.amazon.de/Paradisetronic-com-Programmierger%C3%A4t-ISP-Adapter-Programmer-Arduino/dp/B07Y3B8H91/
However in the reviews I now read, that it's not fully compatible to Arduino IDE.
Do I even need this?
In the guides I saw, they use "avrdude", which seems to be another application to use with this device.
Ok, it seems, that it's only related to setting the clockspeed for processors, which work below 1Mhz. So it should not be an issue here.
conscious-sapphire•2y ago
No, if you setup the 7x7 then you will be affected by the magnets (I don't really know if the magnets affects to superpinda or only to the pinda v2). Anyway for me the best approach is to set up the silicon mod for the heatbed and just correct the phisical deviation. I use the 3x3 and do not have any issue with the magnets
xenial-black•2y ago
Thx for the information.
As far as I understood, Prusa's approach is to just discard the measurements of the affected points and interpolate them.
https://www.klipper3d.org/Bed_Mesh.html#faulty-regions
if you want to go that route
xenial-black•2y ago
Thx!
conscious-sapphire•2y ago
I didn't know about that, using the step file of the bed is possible to calculate the route in order to avoid the magnets
xenial-black•2y ago
I flashed the Bootloader and everything seems fine.
I installed RatOS on my Pi Zero 2, and installed it to the RPi Port of the Einsy Board.
Now in the http://ratos.local/configure when I try to install Klipper to the Control Board, it can't find it.
Is this normal, or should it already be recognized?
I only have the option of flash Klipper over the SD card now.
Is there any way to confirm, the Board is reader for Klipper now?
Or does it need to be USB instead of the Pi-Port?
I followed the same steps, which I had to do to get Octoprint running through the UART of the GPIO:
https://help.prusa3d.com/article/octoprint-configuration-and-install_2182
So I added:
dtoverlay=pi3-miniuart-bt
at the end of:
/boot/config.txt
And I checked:
/boot/cmdline.txt
to see, that there's no:
console=serial0,115200
However I think I need to add somewhere:
/dev/ttyAMA0
But I don't know where. For Octoprint it could be done in the web-interface.
I also opened the:
raspi-config
to enable the serial-port there.
But there still seems to be missing something.
Is there a config, where I can tell RatOS to use the UART instead of USB?
I mean before even having flashed Klipper to the Control Board.
So that the Configurator recognizes it to be able to flash it through the Pi/UART.
USB is required in RatOs. Check
lsusb for the board. If its not an original einsy board it currently won't be recognized.
We can fix that thoughxenial-black•2y ago
Bummer. USB makes the setup a lot more complicated with the Pi Zero 2.
I'd need to find a short USB-B to Micro-USB. And then I'd need an additional Micro-USB Cable to power the Pi. And then I'd always have to manually turn it on.
Is there no way to get RatOS running through the UART?
It's an Original Prusa Einsy (MK3S+).
Yes and no, it won't work with the configurator and there's no automatic updates but you can do it just like any other klipper installation that you want to configure with UART.
I don't understand why using USB for the board has anything to do with turning it on and off though
xenial-black•2y ago
As far as I understood, I need to tell the Pi to use the UART.
And I need to compile a Klipper for the Einsy, which also uses the UART.
For both things I am not sure, which steps are required to do that.
Because the Pi Zero 2 has to be powered by an extra USB port.
If you haven't done it before, i strongly suggest you use the supported hardware. And that means USB mode.
xenial-black•2y ago
It has two ports. One for power, the other for connections.
power it via the GPIO
xenial-black•2y ago
Ah, ok. Good idea!
Still don't understand what that has to do with turning it on and off though 😄
xenial-black•2y ago
So I'd only need that cable.
If it was on an extra USB cable to power it, I'd need to put that cable into an adapter into the wall.
I move the printer often. Because of this, a setup like that is a NoGo.
It should just be connected to the printer and turn on, when the printer is turned on.
as opposed to what?
How did you power it before?
xenial-black•2y ago
GPIO.
Didn't think about just leaving it there and adding a usb cable.
from the einsy?
xenial-black•2y ago
Yes.
I'm not sure it can handle that
xenial-black•2y ago
Also I would need to modify the case to make it fit I think.
You mean, the Pi Zero 2 might draw too much power with Klipper?
i would be very surprised if the Einsy can deliver much more than 1A on 5V.
xenial-black•2y ago
With Octoprint I had no problems.
Ok.. Just don't go connecting web cams and screen and stuff.
It'll pull 3A+
xenial-black•2y ago
Ok. Good to know.
and that most likely will fry the DC/DC converter on the einsy
xenial-black•2y ago
😳
Add a small DC/DC converter module that gets 24V directly from the supply
That's the safest route
But, yeah.. Another project for another time 😄
xenial-black•2y ago
Yes. I actually expected the process to be easier. 😅
well you could just plug it into the wall 😄
xenial-black•2y ago
Don't have too much time right now. So maybe I will try Klipper later.
Its easy until you start requiring things
xenial-black•2y ago
Really not an option.
and that's what's making it not easy 🙂
xenial-black•2y ago
Printer is moved into the bath for printing.
And I don't want to have to use an extra multi-plug.
Most people leave their printer in one spot 😄
xenial-black•2y ago
Yes. Can't do that right now sadly.
But yeah, everything is doable, just need to do it 🙂
xenial-black•2y ago
Too loud and too smelly.
I'd really prefer to use the UART. Maybe later I can take my time to figure it out.
i do not recommend it
xenial-black•2y ago
But why?
Power via GPIO and use USB
Because it's not supported
xenial-black•2y ago
It's an extra cable and would need modification of the casing.
RatOS was not made with UART in mind
So there's a bunch of stuff that won't work as expected
And you'll be back here asking why things don't work
xenial-black•2y ago
Oh. That's sad. 😦
No, it's a non issue
There's no reason for you to use UART
xenial-black•2y ago
Maybe then another Klipper would be better?
That's up to you
xenial-black•2y ago
Or maybe I will just search for that stupid cable and print a new case.
Anyways. Thx for your help.
Will go to sleep now. 😴
It's worth it
xenial-black•2y ago
I now got RatOS running and connected to the MK3S+.
However when I want to home, I get this error-message:
Error evaluating 'gcode_macro HOME_X_SENSORLESS:gcode': jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'tmc2209 stepper_x'
Maybe something went wrong with the automatic configuration?
How can I restart it.
I am just going through the config files to understand everything better.
In https://github.com/Rat-OS/RatOS-configuration/blob/v2.x/steppers/ldo/42sth40-1684ac/2130/ there are 4 configs for the same motor on the different axes.
Why does it say run_current: 0.52 for the extruder motor?
All others use 0.4A. And that's also in the file-name:
24v-0.4a-extruder.cfg
I noticed the extruder motor getting very hot while printing.
Is it really necessary to give it more current?
I assume it's the prusa defaults
The extruder stepper is a different spec than the rest afaik
You can lower the current if you want. But hot != bad. 50-60C is totally OK.
any chance to see a MKS3S version with duet2wifi board ? like caribou/zaribo printers
No, use RRF on Duet boards, they're no fun to support.
xenial-black•2y ago
Thx.
I lowered it to 0.4A now and will see, if it skips steps in any situation.
I still have issues with the Filament Sensor.
(And loading/unloading in general.)
(I did insert, what you suggested here: https://discord.com/channels/431557959978450984/431559228050636820/1097113239927660616 )
But sometimes when I load new Filament it triggers and unloads the filament (after loading was finished).
The sensor might have been confused, because I did cut off the filament above the extruder and feeded new one behind it.
Still the Sensor should not automatically initiate a loading/unloading process ever. And while loading it should not try to detect anything.
I also wouldn't want the printer to automatically unload filament, when it runs out in a print.
It should just pause the print and wait for the user to confirm the unloading.
-
Also the unloading macro seems to be buggy.
First it pushes in the filament deeper, then it pulls it back and changes speed a few times .. also getting very slow.
And after the filament is already out it suddenly spins the extruder wheel concerningly quickly multiple times (not sure, if it also changed direction .. would need to check that again).
Loading Macro is also a bit strange.
After it already pushed out some filament, it keeps pushing out more with a super slow tempo for like a minute.
Why does it slow down?
The loading/unloading process with the Prusa Firmware was super straight forward.
Not wasting any time or doing strange stuff.
Would be great to get the same (or at least similar) behaviour into Klipper.
unwilling-turquoise•2y ago
someone has developed a bunch of macros for a prusa style buildsheet management with klipper https://klipper.discourse.group/t/build-sheet-manager-adjust-live-z/4013
Klipper
Build Sheet Manager & "Adjust Live Z"
This is a small group of macros that implements Prusa’s Build Sheet system and Adjust Live Z behavior in klipper. Specifically: You can have as many build sheets as you like, each with a unique human readable name Each sheet has its own Z offset A sheet can be installed in the printer and this persists across restarts. When you “Adjust Live Z”...
Also the unloading macro seems to be buggy. First it pushes in the filament deeper, then it pulls it back and changes speed a few times .. also getting very slow. And after the filament is already out it suddenly spins the extruder wheel concerningly quickly multiple times (not sure, if it also changed direction .. would need to check that again).All intentional, it extrudes to make sure you don't suck in any gunk, then it's doing tip forming and then it retracts fully.
Loading Macro is also a bit strange. After it already pushed out some filament, it keeps pushing out more with a super slow tempo for like a minute. Why does it slow down?To avoid exceeding the flow rate of the hotend making the extruder skip. It should extrude slowly once the filament makes it's way to the nozzle. Again, intentional. Not a bug.
xenial-black•2y ago
Ok. Then the speeds are a bit funky though.
Or the distance is not right.
With "fast" I always get a lot of skipped steps. And with slow it gets very slow later on.
And then sometimes the Filament Sensor triggers while loading or unloading.
I think I made a video of it. Will search for it tomorrow.
At the moment, I don't have a lot of time for 3DPrinting.