Duet 3 6HC Unable to write tmc spi 'stepper_z' register GLOBALSCALER

General Discussion
1

Basic Information:

Printer Model: Custom
MCU / Printerboard: Duet 3 6HC
klippy.log (41.7 KB)

Hi, I managed it, to flash my Duet 3 6HC with Klipper. I wanted to use it, because all other printers in my farm use klipper and I dont want to use different config languages, even that I worked with duet for years.

For my actual custom design I decided to use an old Duet 3, which wasnt used before, because the driver 1 is defect. Since you can activate them in RRF driver by driver, I thought it would work with klipper too. After some hours of research I know think that this is the problem for my error mentioned in the caption above.

Is there any way to declare only 5 of the 6 drivers? The printer.cfg doesnt seem to make that happen and is still trying to adress it. Or is there another reason that could be the problem? The fusion is fine and should not be the problem. The power supply is old, but there is nothing else on it - only the board.

Maybe somebody here can help me.

Best regards
William

2 
[tmc5160 stepper_x]
cs_pin = PD17
spi_bus = usart1
chain_position = 1
chain_length = 6
interpolate = False
run_current = 1
sense_resistor = 0.05

If I read this correctly, chain_position = 1 corresponds to the first slot. If this is your defect slot, then you are exactly addressing this one.

Never used this board, so :man_shrugging:

3

Hi Sineos, thanks for your answer.

Iam reading it as the protocol chain position. Because the pin should define the position on the board. But I will give it a try.

Also you can see in the log that he is trying to address the other drivers too with an error message…

4

If I read this correctly, chain_position = 1 corresponds to the first slot.

Today I tried to change that and ignoring the first chain slot - nothing changed sadly :frowning:

5

Always post a new klippy.log so that your changes are transparent.

Generally your first slot has multiple “hardware addresses” that are used to talk to this driver:

[stepper_x]
#driver 0
step_pin: PC18
dir_pin: PB5
enable_pin: !PA9

[tmc5160 stepper_x]
cs_pin: PD17
chain_position: 1

You likely need to avoid using any of these throughout your config. This means you need to move all your definitions one position.
Refer to https://github.com/Klipper3d/klipper/blob/master/config/generic-duet3-6hc.cfg:

  • What is called [stepper_x] must be omitted
  • What is called [stepper_y] will become your [stepper_x]
  • etc

In addition it might make sense to force the CS pin of the first slot to high, e.g. add to your config:

[static_digital_output slot0_cs_high]
pins: PD17
6

Im not sure what you mean. In stepper_x Im defining the step, dir and enable pins. In the general tmc stepper x Im defining chain position and the cs pin, which is the same for all drivers. The config you linked is doing it exactly like I did :thinking: Maybe you can explain a bit more what you mean?

But why? Im not sure what youre doing there. The PD17 Pin is the chipselect pin. Since all drivers are using the same Pin I cant just pd 17. But klipper doesnt know which drive “slot0” is - does it? when putting output of the cs pin to 1 im activating the driver. Since the driver is defect that doesnt work.

When having a look in the klippy log file, I can see, that he is already having problems with “virtual enable” the drivers. May this have something to do with my problem?

Configured MCU ‘mcu’ (1024 moves)
Enabling TMC virtual enable for ‘stepper_x’
TMC stepper_x failed to init: Unable to write tmc spi ‘stepper_x’ register GLOBALSCALER
Enabling TMC virtual enable for ‘stepper_y’
TMC stepper_y failed to init: Unable to write tmc spi ‘stepper_y’ register GLOBALSCALER
Enabling TMC virtual enable for ‘stepper_z’
TMC stepper_z failed to init: Unable to write tmc spi ‘stepper_z’ register GLOBALSCALER
Enabling TMC virtual enable for ‘extruder’
TMC extruder failed to init: Unable to write tmc spi ‘extruder’ register GLOBALSCALER
Starting heater checks for heater_bed
Starting heater checks for extruder

7

Ah, of course. My fault, you are right. Since the drivers are daisy chained, you only have one CS pin. I have generously overlooked this fact.

Not sure here, since I never tried such a setup.
Have you tried moving the entire [stepper_x] and [tmc5160 stepper_x] to the y slot, e.g.

# [stepper_x]
# driver 0
# step_pin = PC18
# dir_pin = PB5
# enable_pin = !PA9
# microsteps = 128
# rotation_distance = 40
# endstop_pin = PD25
# position_endstop = 0
# position_max = 450
# 
# [tmc5160 stepper_x]
# cs_pin = PD17
# spi_bus = usart1
# chain_position = 1
# chain_length = 6
# interpolate = False
# run_current = 1
# sense_resistor = 0.05

[stepper_x] # This was previously [stepper_y]
# driver 1
step_pin = PC16
dir_pin = PD10
enable_pin = !PA9
microsteps = 16
endstop_pin = PD25 # Endstop pin for X
position_endstop = 0
position_max = 450
rotation_distance = 4
full_steps_per_rotation = 450

[tmc5160 stepper_x]
cs_pin = PD17
spi_bus = usart1
chain_position = 2
chain_length = 6
interpolate = False
run_current = 1.0
sense_resistor = 0.05

Consequently, you need to relocate every slot:

  • Y from driver 1 to driver 2
  • E from driver 3 to driver 4
8

Hi,

If you have a look at the link you posted you can compare both configurations. I just changed the pins so that the driver 1 pins are not used anymore.

If you have a look at the klippy log you can see, that he is only trying to contact the steppers configurated in the printer.cfg. But there the driver 1 is not used. Is there a deeper part of the firmware for example, where he is trying to contact all drivers and get this error?

Maybe switching back to RRF is the only way to do it.

9

Now you are confusing me.
According to your log, your stepper_x uses:

[stepper_x]
step_pin = PC18
dir_pin = PB5
enable_pin = !PA9
...

[tmc5160 stepper_x]
cs_pin = PD17
spi_bus = usart1
chain_position = 1
...

These are exactly the pins that are tied to driver 0 which apparently is defect.

I can’t say whether Klipper is able to skip a driver in a daisy chain at all, but according to your log you are addressing the defective one.

10

Yes, because the faulty one is driver 1 :smile:

11

Doh! That makes sense :person_facepalming:

Sorry, no further idea. I gathered you already tried skipping the daisy chain position, i.e. 1,3,4,5
Not a lot of options left to play with.

12

Yes I did…

Today I did also something else: I changed the kinematics to none and just configurated an extruder. This should result in just one motor is used.

In the log file I can now see the “cant write to GLOBALSCALER”-error again, but there is also a lot more mcu traffic than before.

Interesting is, that he is shutting down when I try to move the motor, but the error

Configured MCU ‘mcu’ (1024 moves)
TMC extruder failed to init: Unable to write tmc spi ‘extruder’ register GLOBALSCALER

Is coming right after startup. Question for me is, if there is any other configuration file, that is trying to reach all drivers implemented for that board.

Even with changing the pins to different drivers I dont get any good results. I´m now giving up, since I need this board. Otherwise I maybe would try to fix it.

Is there anybody who wrote this stuff and knows how klipper is using the tmc configuration? There are some more questions about the enable and cs pins. Maybe they are the problem in any way?

klippy (8).log (604.6 KB)

13

To check if the defect driver may interrupt the miso mosi lines with unwanted high or low, I started desoldering it. Sadly that didnt change anything. I also started to change the printer.cfg to SPI1 instead of usart1 and used cs PIN PC25. I cant even change the error message. That said I think the problem needs to be with klipper firmware. Since there are many people with the same problem with faulty drivers I think they are adressing the drivers in another way than RFF.

The global scaler register is used for maxmimum current, so maybe RFF is just not trying to write there…? I dont really know where to start searching in the software. maybe somebody has a hint for me.

14

I’m not sure I understand the issue here.

When tmc5160 drivers are daisy chained, Klipper sends commands to “driver0” (chain_position: 1) which relays the commands to “driver1” (chain_position: 2), which relays the commands to “driver2” (chain_position: 3), etc.

So, if you don’t want to use “driver0” then you must not reference a chain_position: 1 anywhere in your config.

If “driver0” is not functioning correctly, then it may not be able to relay commands and responses to “driver1” (and thus all other drivers in the chain). I guess it depends on how the chip is malfunctioning.

If you desolder “driver0” then it definitely wont be able to forward commands on to “driver1”.

-Kevin

15

Hi Kevin,

Thanks for your answer here.

I think the problem is, that Klipper in some way is using a daisy chain type of communication with the given example config before. That seems to be the reason why Klipper can’t be used with one or more defect drivers on the board.

If you have a look at RFF and the board layout at Duet3-Mainboard-6HC/Duet3_Mainboard_6HC_v1.01/Duet3_MB_Schematic_v1.01.pdf at master · Duet3D/Duet3-Mainboard-6HC · GitHub you can see that it seems like only SDO and SDI are used in daisy chain. Not to forget SPI and Step/Dir are both Connected. So it seems like there are truly more ways to talk to the drivers. Sadly I’m not sure if this is having influence on the global scaler register since this is the only error I can get from Klipper.

This said I think the solution would be to find a way using Klipper Just like RFF is doing. Maybe it’s kind of ignoring the SDOs from the driver before or just stop trying to write to global scaler. Maybe you get a high or low state at some point RFF doesn’t care but Klipper does.

To find answers to this question you need to dive deep into at least the Klipper Code to understand which way it is going. Otherwise its hard trying to understand the whole code without any references.

16

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.