No, it sets the current and registers using UART.
I went through this in painful detail with @Digedi - if you don’t move the zero Ohm jumper on R65 to R66 you’re not able to access the X axis stepper uniquely, for reading or writing.
With R65 jumpered, the X axis driver stepper is given the UART address 0, the same as the stepper extruder. With the R65 jumper removed and placed at R66, the X axis stepper driver is given the UART address 3 which is unique.
Yes, that is correct. But you don’t need to access it uniquely, you can share the same settings between extruder and X axis. Did you read my README?
I’m reacting to your statement
I don’t read from the chips. This works fine in practice.
In practice I never have the same current on my extruder as any of my movement steppers. Right now on my 2.4 I’m running 0.8A on my A/B steppers, 0.6A on my Z axis steppers and 0.4A on my extruder.
Your README doesn’t seem to address the fact that anytime you write to the X axis stepper you’re also writing to the extruder stepper and vice versa. What jumped out to me was that this affects driver current, but it would also be problematic if you have different microstep counts on one driver and not the other or if you are going to use sensorless homing on the X axis (although if you’re not reading back, then it’s not an issue).
Also, I’m curious to know why you think multiple writes to the registers is any different than a single write? You have the same impedance on the MCU’s UART line whether or not you are addressing one TMC2209 or multiples, you don’t have to write multiple times to compensate for that.
I’m clearly missing something here and I’m curious to know what it is.
If you don’t have the same current or microsteps, then you have to solder. But in practice this doesn’t seem to be required, the Marlin firmware uses the same microsteps/current I think.
My README addresses it here:
This code takes a similar but different approach: Treat the two chips as one ‘mega chip’ with one set of registers that you write to and drive two stepper motors with. Error checking and status checking is disabled, but writes are done multiple times to compensate.
Klipper stock writes to registers multiple times if an error in transmission occurs. Since I can’t check that I just assume there’s an error and try harder.
Edit: Maybe the misunderstanding here is that this isn’t meant to be as configurable as the solder mod. But you don’t need that configuration to run and benefit from Klipper.
You haven’t directly answered either of my questions. You seem to dance around acknowledging that if you have two stepper drivers with the same UART address then they’re both going to have the same values written to them at the same time.
I guess you’re looking at the right block diagram from the datasheet:
and using that as your model with the problem being that by doing this you’re potentially ending up with a situation where you don’t know which stepper driver has been give which values.
You’re acknowledging that it isn’t as configurable as desirable. I guess I could see it being used in the case where you had two steppers that required the same current (such as the A/B steppers in a CoreXY printer) and moved the extruder to a driver that can be addressable. Clumsy, but something I could support but not what you’re doing here.
Personally, even if I didn’t have the right tools, I’d figure out a way to cut off the resistor at R65 and solder down a wire across the R66 pads and be done with it.
Your questions were:
- What do you do to address the UARTs
- Do I use pots to adjust the modules
- Why I use multiple writes to registers
I tried to answer them all and not dance around them but I’ll try again:
I use one driver for both controllers and treat them as if there’s just one controller. There’s no confusion or register conflicts at any point (unless you set different microsteps, but that’s a bug). Both stepper motors have the same values, and both steppers share the same driver instance and set of registers.
I don’t use pots to adjust the modules.
I write multiple times to the registers because that’s what Klipper does if it detects an error. I can’t use that error detection code so I just write multiple times anyway to be safe.
I hope that answers your questions. Please assume good faith on my part
the GitHub Link is not valid
Sorry about that, I was getting the PR ready and accidentally broke the original link. Here’s a good one:
Thank you for sharing the config! im curious to know if its possible to use a BL touch with the Kobra Max board or if its not possible
Debating on a Kobra Max vs an Ender 3 S1 Plus. Seeing the link is from Dec '22 is this config still good? Does it need any updates or having any issues?
Does this still work with latest sonic lad firmware? I have a kobra max and moved the jumper and did the cfg and bin but i just get errors.
Problem with kobra Max,
I have moved the resistor
installed the .bin using the Sd card
installed .config through the sonic pad
going through self test, the fans work
on homing the z goes up 10m as set in .cfg and then the sonic pad loses connection to the printer… i cant seem to home the machine… even trying to home manually… exactly the same
i think @Digedi had the same issue? can you tell me how you overcome the problem please?
resolved, i was using the .bin file from further up the page… i used the latest one from @Hereticx5 and it worked perfectly
printer.cfg (6.8 KB)
i haven’t set anything up, but i had the same issue as you after i updated the sonic pad… i altered the space that shouldnt have been there between probe : and 200,200,10 and also my printer serial port, that the sonic pod gave me…
maybe this will work for you… or at least get you past that screen… i havent set anything else up but i have got passed the initial test it carries out.
I’m planning to get klipper running on my Kobra Max via a Sonic Pad.
Just confirming what I need:
-printer.cfg
-.bin
-Mod Kobra Max motherboard
What would be the process order I need to go through? And how’s it working for you so far?
You may be interested on this notes concerning the Sonic Pad:
I could use a little advice with this setup. Also, perhaps I can help a bit for those who are doing this for the first time. Here’s my setup:
Anycubic Kobra Max
- Did the jumper change demonstrated above in this thread. I lost the jumper, so I just dripped a bit of solder on the board to bridge the connection for R66. Someone mentioned sticking pins in, so you could do this mod with a jumper; that would be a very nice idea.
- Flashed the firmware with Klipper.bin from SteveGotthardt/klipper/releases/tag/pre-merge on Github. I renamed it to firmware.bin and put it in the root folder of a little sd card (it did not work on my 64GB sd card, but worked fine on the 8GB sd card that came with the printer). I turned that printer on with the sd card inserted, and it flashed very quickly for me.
MKS PI (my controller board)
I have an MKS PI, which I set up to run the printer. Once that was set up and working, I hooked up my printer to the MKS PI via USB. It connected and was somewhat useable. I made some modifications to the printer.cfg above. Here is my printer.cfg that I am currently using
printer.cfg (6.2 KB). Everything is working really well. I was able to run the sensor calibration. I also calibrated the bed mesh, which is where things started getting really weird.
The calibrations for the bed mesh has mostly really large numbers: between 2.x–3.x. I thought those numbers should be generally a lot closer to 0. Secondly, my printer now starts printing in the air. When it starts a print, it is about 3mm above the printer bed. I tried deleting the bed mesh I had made, but it still prints in the air, albeit a bit lower. Has anyone had this problem? Is there anything obviously wrong in my printer.cfg? I assume there is some z-offset somewhere, but I am totally new to klipper, so I really don’t know what I am doing just yet. Thank you for any help/advice you can give, and I am happy to share my experience if anyone is having trouble with any other part of the install process.
are you using BL touch?