About SKR2 settings
Hi,
I just purchased SKR2 board from BigTreeTech and want to run it with Repetier ver2 firmware. I see in constants.h file that STM32F4 chip is supported however SKR is not explicitly defined:
// STM32F4 based boards (3000 - 3499)
#define MOTHERBOARD_RUMBA32 3000
#define MOTHERBOARD_STACKER3D_SUPER_MINI 3001
Should I use any of these 2 motherboards in my settings, or do I need a different setup?
If somebody is already running Repetier on SKR2 and could share config, that would help immensely.
Thanks
Comments
If you are up to some testing I can try to copy some required files and make changes to the firmware so it theoretically should then work at the weekend, but it will be untested as I do not own that board. I would then post progress here for testing.
Set MOTHERBOARD to MOTHERBOARD_SKR_2
and in platformio.ini default_env to SKR2
The board uses 3 different hardware SPI so hope spi devices work correctly. See skr.h for definitions and comments. By default the sd card on the board is used which has an own spi.
Not sure if the sd card upload is something that comes from the chip or not. The STM32 on rumba have a DFU mode that I use for uploading. But that is one mode used by some chips so it can be and as long as it also works after marlin has been replaced it is ok to use that.
Unlike marlin I use the provided serial solution from STM32 for usb. This gets influenced by the special board definition in stm32f4.ini in this part:
Fixed settings are -DUSBCON -DHAL_UART_MODULE_ENABLED -DUSBD_USE_CDC which are needed to enable usb drivers.
The part that is unsure is
-DUSBD_VID=0x8000 "
-DUSB_MANUFACTURER=\"BTT\""
"-DUSB_PRODUCT=\"BTT_SKR2\""
-DUSBD_PID=0x5740
These define how it is named and might windows make not detect it. Can you check in hardware manager if you see it as unknown device. I just copied it from rumba32 settings where it works, but there Manufacturer has name "Unknown" so that might be a significant difference making it fail detecting on windows.
But I have now ordered the skr 2 to see myself. It is hard to do remote debugging and having it locally for tests is much easier especially since I see some things other might not mention or even notice to be important. So lets hope I see something then so it works quickly.
You are absolutely right. Meanwhile I will focus on hardware changes, will need to do lots of crimping, replace power supplies, etc.
Looking forward for your test results and updates.
Thanks!
Regarding second extrude note that everything activated in configuration_io.h gets compiled, so just removing it from one array does not mean it gets not compiled in. You really need to delete the lines for second extruder then.
// COOLER_MANAGER_MOTORS(BoardFanController, BoardFan, 0, 192, 10)
plus the above settings defining BoardFan and the fan. The first 2 define a pin while COOLER_MANAGER_MOTORS is the logic that controls the fan. But I see the description is bad, meaning wrong.
When you omit Px in M106 it selects the fan associated to the active extruder. In your case
TOOL_EXTRUDER(ToolExtruder1, 0, 0, 0, HeaterExtruder1, /*AL1Motor */ E1Motor, 1.75, 147.0, 5, 30, 5000, 40, "M117 Extruder 1", "", &Fan2PWM)
If you look at your fan list
you see you assigned the second fan to extruder 0 so that is why omitting P0 chooses Fan2. Replace by Fan1PWM. The FAN_LIST is just for controlling fans with Px - you should omit fan 2 and 3 anyway as they are controlled automatically by firmware logic and should not be overwritten as that gets reset anyway.
y max homing.
ENDSTOP_SWITCH_HW(endstopYMax, IOEndstopYMax, Y_AXIS, true)
looks correct. At least if pin is correct. So check M119 with y triggered and untriggered if it shows correct signal.
Also text if homing y moves towards y max. Have often seen that users tricked them self by placing end stop to wrong side or changed home dir to -1 to get move to y max direction. Better check if moves go to correct direction and otherwise change core factors to do this correct.
2209 drivers, see
https://docfirmwarev2.repetier.com/config/motors#stepper_trinamic
You need
but not sure it works with STM processors. You need to try. If you onyl want to use one uart for both drivers one gets slaveAdr 0 and one slaveAdr 1 and you need to modify the driver board accordingly. MS1 and MS2 define the address.
Use M122
https://docfirmwarev2.repetier.com/GCodes/motion_gcodes#m122
to debug if the drivers are working correctly. They normally only work when main power is also enabled. At least some other TMC drivers have that issue.
slaveAddr
value. I have only 2 TMC drivers. Should I use addresses 0 and 1? Or, since slots X and Y have non-TMC drivers and TMCs are in Z and E0, I should set addresses to 2 and 3?microsteps
parameter in STEPPER_TMC2209_HW_UART ?Where and which pins? Here is the schematic:
https://github.com/bigtreetech/SKR-2/blob/master/Hardware/BIGTREETECH SKR 2-SCH.pdf
There you also see which pins belong to which uart serial. According to datasheet it has 4 hardware uart.
Slave address only depends on the setting on the driver chip where you configure it, it does not depend on socket connected to. I think the jumpers below should set it - the one I checked used at least 2 of them to set it.
TMC_INTERPOLATE only defines if the driver should increase internal microsteps to 256 or not. You normally want that on as it is the most quiet solution. Chip will then interpolate smooth even when externally 16 microsteps are set it uses internally 256.
M18 fix on github should fix the motor off problem.
So as you see they are using software serial for all chips. For Z axis it would then look somehow like this
STEPPER_TMC2209_SW_UART(name, stepPin, dirPin, enablePin, rxPin, txPin, rsense, microsteps, currentMillis, stealth, hybridSpeed, slaveAddr, stallSensitivity, fclk, minEndstop, maxEndstop)
resulting in
check for rsense value to be the one used on your driver! So slave addresses needed as all have their own serial.