My actual log for my working canbus setup matches your latest one for the mcu configs and pins.
So it is odd that you would need to change the code.
I get what kevin had replied to you before
[tmc5160 stepper_x]
spi_software_sclk_pin = PE12
spi_software_miso_pin = PE13
spi_software_mosi_pin = PE14
My own test confirms that this appears with tmc5160 without spi configs above
Pin PB13 reserved for CAN - can't reserve for spi2
you will also need to cut a pin on the tmc5160 because mks bridged it.
- The
DCOpin is an output, keep attention that it is not connected toSDO, because some mainboards bridge these pins (also calledSLP+RST).
1 Like
Yeah, got it working 
Thanks gaby_64, your turned my view in the correct direction.
first, i had miso mosi switched, that’s the correct thing:
[tmc5160 stepper_x]
cs_pin: PE6
spi_software_sclk_pin:PE12
spi_software_mosi_pin:PE14
spi_software_miso_pin:PE13
second, as thought, the SLP pin of the tmc5160 driver has to be removed.
Now init_tmc and dump_tmc get’s correct results ^
21:30:07
// SGTHRS: 00000000
21:30:07
// ========== Queried registers ==========
21:30:07
// GCONF: 000001c0 pdn_disable=1 mstep_reg_select=1 multistep_filt=1
21:30:07
// GSTAT: 00000001 reset=1(Reset)
21:30:07
// IFCNT: 00000018 ifcnt=24
21:30:07
// OTP_READ: 0000000e otp_fclktrim=14
21:30:07
// IOIN: 21000041 enn=1 pdn_uart=1 version=0x21
21:30:07
// FACTORY_CONF: 0000000e fclktrim=14
21:30:07
// TSTEP: 000fffff tstep=1048575
21:30:07
// MSCNT: 00000008 mscnt=8
21:30:07
// MSCURACT: 00f7000c cur_a=12 cur_b=247
21:30:07
// CHOPCONF: 14030053 toff=3 hstrt=5 tbl=2 vsense=1 mres=4(16usteps) intpol=1
21:30:07
// DRV_STATUS: c00f0000 cs_actual=15 stealth=1 stst=1
21:30:07
// PWMCONF: c80d0e24 pwm_ofs=36 pwm_grad=14 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 pwm_reg=8 pwm_lim=12
21:30:07
// PWM_SCALE: 00000012 pwm_scale_sum=18
21:30:07
// PWM_AUTO: 000e0024 pwm_ofs_auto=36 pwm_grad_auto=14
21:30:07
// SG_RESULT: 00000000
21:30:08
$ dump_tmc stepper=stepper_z1
21:30:08
// ========== Write-only registers ==========
21:30:08
// SLAVECONF: 00000200 senddelay=2
21:30:08
// IHOLD_IRUN: 0008190f ihold=15 irun=25 iholddelay=8
21:30:08
// TPWMTHRS: 00000010 tpwmthrs=16
21:30:08
// TPOWERDOWN: 00000014 tpowerdown=20
21:30:08
// SGTHRS: 00000000
21:30:08
// ========== Queried registers ==========
21:30:08
// GCONF: 000001c0 pdn_disable=1 mstep_reg_select=1 multistep_filt=1
21:30:08
// GSTAT: 00000001 reset=1(Reset)
21:30:08
// IFCNT: 00000018 ifcnt=24
21:30:08
// OTP_READ: 0000000f otp_fclktrim=15
21:30:08
// IOIN: 21000041 enn=1 pdn_uart=1 version=0x21
21:30:08
// FACTORY_CONF: 0000000f fclktrim=15
21:30:08
// TSTEP: 000fffff tstep=1048575
21:30:08
// MSCNT: 00000008 mscnt=8
21:30:08
// MSCURACT: 00f7000c cur_a=12 cur_b=247
21:30:08
// CHOPCONF: 14030053 toff=3 hstrt=5 tbl=2 vsense=1 mres=4(16usteps) intpol=1
21:30:08
// DRV_STATUS: c00f0000 cs_actual=15 stealth=1 stst=1
21:30:08
// PWMCONF: c80d0e24 pwm_ofs=36 pwm_grad=14 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 pwm_reg=8 pwm_lim=12
21:30:08
// PWM_SCALE: 00000012 pwm_scale_sum=18
21:30:08
// PWM_AUTO: 000e0024 pwm_ofs_auto=36 pwm_grad_auto=14
21:30:08
// SG_RESULT: 00000000
now comes the fun part, get the board into my printer and everything dialed in 
1 Like
I am still working on my can-not bus. I somehow made moonraker not work anymore so I started again with a new image. I went to fluidd and updated moonraker, klipper, and fluidd.
I set up menuconfig like this:
and I renamed the resuting .bin file to mks_skipr.bin and copied it on an sd card. I put the sd card in the mcu tf card slot and cycled the power. I then verified that it changed the filename to mks_skipr.cur so it should be installed in the mcu.
I created /etc/network/interfaces.d/can0 with the following data:
allow-hotplug can0
iface can0 can static
bitrate 500000
up ifconfig $IFACE txqueuelen 1024
I plugged a usb cable into the usb3 port on the host and plugged the usb3 connector into the usb3 port on the mcu next to the reset button.
I think this is where I am going in the wrong direction. lsusb shows nothing plugged into the usb ports (except my wifi adapter).
~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
returns a lot of garbage but basically boils down to no can0 interface.
If I unplug the usb from the mcu and plug it into the utc-1 board the can interface is found so I am pretty sure my linux configuration is correct.
I have a SHT42 and a SB2040 that are both programmed and both show up as klipper devices when plugged into the utc-1.
I think I am missing something where the can interface is using PA11 and PA12.
Can someone point me in the right direction? Is there something else I can check on the mcu to be sure it is set up correctly?
When you plug in the usb cable, what is the dmesg command showing?
(Last 20 lines are enough)
Thank you for the tip on using dmesg. When I plug the mcu into the usb I get nothing in dmesg. The utc1 shows all the device info. So for some reason my skipr is not showing any connection. Is there something I may have missed in the setup or is it possibly just bad?
Here is the output after plugging in the mcu
A stack trace in dmesg is not really something you want to see. dmesg is evaluating the kernel buffer of your Linux operating system and a hard crash in there is serious and could very well lead to an unstable system.
Unfortunately I cannot provide any more insight on the reason, since I’m not a Linux developer but you might want to google for such errors or simply start setting up a new system. (I’d do the second because according to my experience, you will not be able to solve such).
General reasons for such are:
- Linux bug in the distribution you are using
- Some hardware faults either on SBC itself or connected hardware
I’ve uploaded my compiled files, sources and configs to my nextcloud.
you can flash this version to your skipr board, should work too
there only shows message: File not found.
Strange, link was correct but didn’t worked.
Now it should work
sounds like your usb cable is not good (charging only?), only usb 2.0 is needed, try usb c to usb 2.0 with another cable.
lsusb should show this for the mcu
1d50:606f OpenMoko, Inc.
I have tried the above configurations but no luck. I tried two different cables, both work with the utoc1 board so they are good. I have no idea what may be wrong with this board.
Show us the output of lsusb and a longer dmesg log, the stack trace can be ingored, it is common for rk3328.
Maybe your stm32 bootloader is damaged.
You can try to connect via stlink
Hello,
I have a problem getting the Fysetc SB CAN TH to run in combination with a BTT Octopus 1.1 and Pi 3B+. Octopus 1.1 is connected to the Pi via USB. Can is connected via RJ11/12.
I had flashed Canboot, as well as the current Klipper versions on the boards at the time. The latest Mainsailos 32-bit version runs on the Pi.
At first I had problems with ADXL345, timeouts, QGL, and while moving with the probe. I exchanged the probe, an inductive Omron, not only because of problems with Voron TAP Opto v2.
Basically the printer works. Resonance measurement is not possible - disconnection. Various mcu timeouts, shutdown, disconnects are annoying and should be manageable.
I have set a CAN speed of 500000 and txqueuelen512 (of course including all flashes)… any attempts with a combination of 1000000 or txqueuelen1024 failed…
I also became aware of the quickfix and had to realize that it was already implemented with the last Klipper update… so I flashed all the boards again. Unfortunately in vain…
Strange is octopus 1.1 still has v0.11.0-66-g4671cf2d despite flashing version v0.11.0-99-g56444815.
Pi & Toolhead are v0.11.0-99-g56444815.
I know the logs are needed - I’ll deliver them later. It would be nice if @opiswahn could describe a rough setup, since we seem to have a similar system. Then logs would follow…
A small side question: “restart_method:” is old? or does not work with Can or Octopus? I had the first start with “serial” instead of “canbus_uuid” and “restart_method” didn’t work there either.
Thanks and regards
Marcel
Hello all!
I have been holding back for a long time from trying klipper since I am not a Linux guy and it has always seemed to me a pretty involved process.
Now with the introduction of the SKIPR, I thought it was a good chance to try it. I have bought it together with the THR36 and the UTC module.
Now I am facing several problems and it still turned out to be not as straight forward a process as I had hoped for:
-
I followed the instructions on Gothub, but I cannot get the THR36 working through CAN. I don’t want to use USB and then additionally a power cable. I am trying to connect the THR36 through the UTC to SKIPR. The seller suggested that the UTC is not required at all. I have read through the entire thread here, but could hardly understand a thing. I would appreciate very much any help with this.
-
(Not as much related to the thread’s topic) Trying to connect the THR36 through USB, I am only able to control the fans. The temperature sensor is not functioning - showing a negative -40 value. Tried connecting 3 different thermistors (accordingly editing the printer.cfg) and all are the same. The heater doesn’t work either.
-
(NOT related to the topic of this thread). Put the jumpers to use the TMC2008 in UART mode, but they don’t work and I am getting an error that there is not communication with the drives. The drives I have are TMC2008 v1.2. Could be they are different?
I would appreciate any help.
-
You only have to use one usb cable from the mks pi part of the skipr board to the stm32 mcu part. You have to compile klipper for usb can emulation (use the config files from my nextcloud link)
-
You have to flash canboot to your toolhead board, and after connecting it to the canbus interface, you can flash it through canboot
-
Did you configure uart in your printer.cfg? (Again, have a look at my printer.cfg)
1 Like
Well, thanks everyone for their help, but I yield. I have spent more hours trying to get this canbus working than I will ever use this printer. I am going to just use the UTOC-1 and put the printer together. I can plug anything into the usb port and lsusb will show it, but not this mcu. Maybe I will come back to this later, but I have to move on. This printer is just screaming to get Marlin off of it.
So, if anyone else is following this thread, I never got it to work and I believe something is wrong with my board. I can get the canbus to work with an external board, and all the IO on the SKIPR is working, so I think my setup is good. Maybe there is some firmware that needs to be loaded through the usb port like the UTOC needs if you get a blank one? I don’t know, but I am moving on.
Thank you for your response.
- That means instead of the UTC board? I have already the UTC connected in the mix.
Not sure I know what does it mean or how to do this…
-
Again, not sure I know what it means…
-
Yes, I did.
I have the same IRQ57 stack trace issue. I’ve described it in this thread at Jan. 02.
Despite to this issue the printer works flawless 