Can I help with Trinamic support?

[fitch22]

I have a Bigtreetech SKR 2 and would love to get Trinamic 2209 drivers working, although I could make do with 2130 if I had to. I was able to create a map file for the SKR 2 and I can compile everything with Trinamic support, but I am pretty sure there is no UART code. So, I would like to help in that regard.

I will admit I am a bit lost wandering through the code. If I could get pointed in a direction that is most helpful to the project, I will do my best.

Bill

[terjeio]

I'll look at this later as I am a bit busy for a couple of days more. IIRC TMC2209 UART support for Bigtreetech will require a bit of work on the low-level side as the pins used for comms are not routed to UART capable pin(s) - one has to use soft UART(s)?

[fitch22]

Terje, Thanks, whenever you can get to it. Yes, BigTreeTech routed a single pin for RX and TX to the 2209 (or other UART capable driver). In the Marlin code, they refer to this as single wire serial. It uses software serial rather than hardware, but for Marlin it all seems to work. I am still trying to figure out how the Marlin stuff works in the hopes it will help me. Bill From: Terje Io ***@***.***> Sent: Saturday, July 24, 2021 2:02 PM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (#41) I'll look at this later as I am a bit busy for a couple of days more. IIRC TMC2209 UART support for Bigtreetech will require a bit of work on the low-level side as the pins used for comms are not routed to UART capable pin(s) - one has to use soft UART(s)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIQOQQZ64OABYPYT4S3TZMS3LANCNFSM5A4RF4QQ> . <https://github.com/notifications/beacon/ACQUGIUSQON6JJDQWZVLDFDTZMS3LA5CNFSM5A4RF4Q2YY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAH7MVQ.gif>

[terjeio]

There is some code in the STM32F4xx driver that may help, from line 166. This driver uses a hardware UART so rather simple code, at least you can see how the datagrams are transmitted and the response decoded.

[fitch22]

Terje, Thank you for the pointer. I think I can make sense of what needs to be done. When I have something, I will let you know. Thanks, Bill From: Terje Io ***@***.***> Sent: Monday, July 26, 2021 3:00 AM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (#41) There is some code in the STM32F4xx driver that may help, from line 166 <https://github.com/grblHAL/STM32F4xx/blob/master/Src/st_morpho.c> . This driver uses a hardware UART so rather simple code, at least you can see how the datagrams are transmitted and the response decoded. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIXDWMAMF4FTKDN7BTDTZUW25ANCNFSM5A4RF4QQ> . <https://github.com/notifications/beacon/ACQUGIU7A5A333GARUPPPF3TZUW25A5CNFSM5A4RF4Q2YY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAIAO3Y.gif>

[fitch22]

Terje,
A philosophical question. What is the feeling about using c++ code in grblHAL? The reason I ask, is that there are a couple Marlin libraries that has everything needed. These are TMCStepper and SoftwareSerial. Problem is they are both c++.

it seems one solution would be to re-write these libraries in C. Another solution might be just compile the project using c++ and tweak the code if necessary to get the syntax to compile. This second approach would open the doors to using other c++ in the future.

What are your thoughts?

Bill

[terjeio]

A philosophical question. What is the feeling about using c++ code in grblHAL?

I am not going to rewrite grblHAL to use C++, I'll leave that to somebody else. Using C++ code for specific drivers is ok, but I do not want C++ in the core or in plugins that are for general use across drivers. There are already drivers that has C++ code wrapped for use from C, IIRC currently USB driver code for Arduino based drivers. This is an example.

These are TMCStepper and SoftwareSerial.

Since the Trinamic code is in a plugin a new plugin (or plugins) can be written that uses whatever library the developer fancy. The two libraries you mention above have dependencies on the Arduino framework? If so they might be problematic to use with other frameworks, limiting their use. Myself I am no fan of the Arduino framework and the so called IDE, it is far too expensive to work with for any serious coding efforts.

I will stick to my own library for the current plugin as it is in plain C and thus usable for all drivers that implements the low-level interface(s) required. If you can wrap SoftwareSerial in a stream implementation with the few calls required you can use the current plugin as-is. If you want to use TMCStepper you will have to write a new plugin on top of that.

FYI I have been revisiting the plugin code for a TMC2209 based BTT board (the MINI E3) and have found a couple of bugs, the most serious is that init code for TMC2209 was not in place. I'll commit a fix for those tomorrow.

[fitch22]

Terje,
I have some working files, a map file and a .c file for the BTT SKR-2 board. At the present time, the .c file only has software SPI routines that work with the TMC2130. I think with the right map file, this code will also work with the BTT SKR Pro models. I intend to add software uart routines to work with the TMC2209 drivers, this will be next.

My question for you is what is the best way to give you my changes? I have found it hard to keep up with all the work you are doing. It would be easier for me if these new files get checked in, but you probably want to review what I have done. Let me know how you would like to proceed.

Thanks,
Bill

[terjeio]

I have some working files, a map file and a .c file for the BTT SKR-2 board.

Great.

At the present time, the .c file only has software SPI routines that work with the TMC2130.

The did not even route the SPI signals to hardware SPI capable pins? Morons...

My question for you is what is the best way to give you my changes?

A PR is easiest to review. Yesterday I committed an update, mainly for the Trinamic code - you should update your code to match that? Not much has changed related to the driver comms implementation - the main change for is that ganged axes are now supported by the motor plugin (use driver.id instead of driver.axis to address the driver for SPI comms).

[terjeio]

The did not even route the SPI signals to hardware SPI capable pins? Morons...

Not so it seems, they have routed them to the SPI3 port. So no need for adding software SPI?

[fitch22]

It looks like they did use spi 3 for the skr pro, but for the skr-2 they did not. In fact, they used one of the SWD pins for MISO, so to debug things you have to use another pin and jumper around things. I hope to send you a pull request soon. Bill

…

Sent from my iPad

On Aug 9, 2021, at 2:04 AM, Terje Io ***@***.***> wrote:  The did not even route the SPI signals to hardware SPI capable pins? Morons... Not so it seems, they have routed them to the SPI3 port. So no need for adding hardware SPI? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[fitch22]

Terje, OK, I have a repository setup on github. But before I let you pull from it, I have a couple questions. The BTT SKR-2 has an 8MHz crystal, so I had to set HSE_VALUE. I also set STM32F407xx. I modified driver.h to include a place for defining the new board type BOARD_SKR_2. My question for you is where should these definitions go? I thought at first that maybe they should all be defined in the map file, but with the order things are loaded it doesn’t work. Maybe that can be fixed. Do you have any thoughts about where these definitions should go? I think setting them in the eclipse project properties is not the best place. Thanks, Bill From: Terje Io ***@***.***> Sent: Monday, August 9, 2021 2:04 AM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (#41) The did not even route the SPI signals to hardware SPI capable pins? Morons... Not so it seems, they have routed them to the SPI3 port <https://github.com/grblHAL/STM32F4xx/blob/38a9cff26da8336395185449d1f0bcbe8aa6dae0/Src/spi.c#L80-L91> . So no need for adding hardware SPI? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIQPJVAIN6STHNXEBQTT36KZRANCNFSM5A4RF4QQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> . <https://github.com/notifications/beacon/ACQUGITQU67VKPPG3KUSOZDT36KZRA5CNFSM5A4RF4Q2YY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAIYJII.gif>

[terjeio]

My question for you is where should these definitions go?

HSE_VALUE and STM32F407xx definitions should go into new build configurations for debug and release.

Add BOARD_SKR_2 to my_machine.h and driver.h, but please name it BOARD_BTT_SKR_20 so it follows the naming convetion used in the LPC176x driver. The map file and board code file should also be named similarly as those in that driver.

I thought at first that maybe they should all be defined in the map file... Maybe that can be fixed.

I belive it can not. Chicken and egg issue.

I think setting them in the eclipse project properties is not the best place.

End users may set BOARD_BTT_SKR_20 (and other defines in my_machine.h) in the project file by adding OVERRIDE_MY_MACHINE to the defines there.

[fitch22]

Do you mean BOARD_SKR_2.0 or BOARD_SKR_20? Bill From: Terje Io ***@***.***> Sent: Monday, August 9, 2021 11:49 AM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (#41) My question for you is where should these definitions go? HSE_VALUE and STM32F407xx definitions should go into new build configurations for debug and release. Add BOARD_SKR_2 to my_machine.h and driver.h, but please name it BOARD_BTT_SKR_20 so it follows the naming convetion used in the LPC176x driver <https://github.com/grblHAL/LPC176x/tree/master/src> . The map file and board code file should also be named similarly as those in that driver. I thought at first that maybe they should all be defined in the map file... Maybe that can be fixed. I belive it can not. Chicken and egg issue. I think setting them in the eclipse project properties is not the best place. End users may set BOARD_BTT_SKR_20 (and other defines in my_machine.h) in the project file by adding OVERRIDE_MY_MACHINE to the defines there. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIXUMXCEZJTZXYQWFL3T4API3ANCNFSM5A4RF4QQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> . <https://github.com/notifications/beacon/ACQUGIRQIEL6VWNU2EZSICLT4API3A5CNFSM5A4RF4Q2YY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAIY7GY.gif>

[terjeio]

Do you mean BOARD_SKR_2.0 or BOARD_SKR_20?

None, I wrote BOARD_BTT_SKR_20. Defines cannot have a full stop in them. Filenames can.

[fitch22]

Terje, I created a pull request. I have never done this before on github. Please let me know how it goes, I will try to respond quickly if I need to fix something. One little note, I had to comment out #define USB_SERIAL_CDC in my_machine.h so that I can debug the hardware. I had to use USART1 available via the TFT connector. If you know any tricks to getting the USB serial interface to work while debugging, please let me know. If this goes well, I will include the changes to support TMC2209. Bill From: Terje Io ***@***.***> Sent: Monday, August 9, 2021 12:36 PM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (#41) Do you mean BOARD_SKR_2.0 or BOARD_SKR_20? None, I wrote BOARD_BTT_SKR_20. Defines cannot have a full stop in them. Filenames can <https://github.com/grblHAL/LPC176x/blob/master/src/btt_skr_1.3_map.h> . — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIWZOCRC2SYGLAZ2WK3T4AUZNANCNFSM5A4RF4QQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> . <https://github.com/notifications/beacon/ACQUGIT5O6IN7WYM37JXTIDT4AUZNA5CNFSM5A4RF4Q2YY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAIZANY.gif>

[terjeio]

Looks ok from a brief check - it is late here now so will take a closer look tomorrow. I have some changes coming for the chip select lines and extra motors (E0/E1) allowing them to be assigned as A, B, or ganged motors. I can update the code for that as it will be more or less copy/pasting from the LPC176x driver I have been working on.

If you know any tricks to getting the USB serial interface to work while debugging, please let me know.

It is a pain, the USB stack may die when a breakpoint is hit (I am not sure if it does for this driver). On a restart the connection is lost and senders (or a terminal connection) has to be restablished. Sometimes you have to remember to disconnect before restarting, for some drivers even unplug/reinsert the USB cable... Using a UART connection is thus usually far simpler, it is always there.

[fitch22]

Terje,
I finally have my software serial stuff working from the SKR-2 to/from the TMC2209. I have found an issue and I have not tried this with the TMC2130 but it may be present with them as well.

When I use $338 to set a mask for the TMC drivers, it seems that if I change it from say $338=1 to $338=2, it fails and says it cannot communicate with the stepper driver. If I go from $338=1 to $338=0 to $338=2 it will begin to work. Sometimes I have to go back to 0 and then try again. I will say it is not 100% the same from time to time. I seem to have to hit return to get OK prompt a couple times and possibly ^X or two.

Once I get past this when changing $338, the drivers seem pretty solid.

Any ideas?

Bill

[terjeio]

Bill, I'll take at look at this later - maybe tomorrow. Note that some settings are hard to do/undo/redo reliably - a reboot is sometimes required.

BTW great that you have managed to implement this, you will create a PR for it?

[fitch22]

Terje, As part of the software serial solution, I needed a timer for another interrupt. I chose to use timer 7 as it is sufficient and the least capable of all the timers so it is unlikely to conflict with other purposes. However, this timer is not present in other MCUs in the project like F401. To get the interrupt to work I ended up using the startup .s file from the F407. I don’t know if there is an easy way to conditionally compile (assemble) one .s file or another. Do you have any ideas how to do this? At one point I tried to just add some of the timer 7 stuff to the original F401 .s file but whatever I did would not work. Thanks, Bill From: Terje Io ***@***.***> Sent: Sunday, October 3, 2021 11:42 AM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (Discussion #41) Bill, I'll take at look at this later - maybe tomorrow. Note that some settings are hard to do/undo/redo reliably - a reboot is sometimes required. BTW great that you have managed to implement this, you will create a PR for it? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIRRVACMIJORAESZEKTUFCPY7ANCNFSM5A4RF4QQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> . <https://github.com/notifications/beacon/ACQUGITOXGM7E4KQ4PILPILUFCPY7A5CNFSM5A4RF4Q2YY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAK3DFI.gif>

[terjeio]

I don’t know if there is an easy way to conditionally compile (assemble) one .s file or another. Do you have any ideas how to do this?

In the CubeIDE you can exclude a file from a build configuration, right click on it and select Properties:

I have not tried it but I guess that would work. Conditional assembly (by the preprocessor) is also possible?

[fitch22]

Terje, Now the big question. There are configurations for F401, F407, F411 and F446, and I expect maybe some more in the future. If I add the new .s file, I am happy to change the settings here locally so I can build, but do you want me to check in the .s file? If so, what about the settings for the other configurations? They will be affected as they will need to have the new .s file excluded. And for whatever reason, my settings are not the same as yours and I don’t want to break anything. I think I am ready to check in my changes for the software serial. I found out what was killing my drivers, there is a hardware issue on the skr-2 that needs to be addressed. I would love to see other people besides myself testing out the software serial, but don’t want them blowing up their stepper drivers. I could put some warnings in the .map file for the skr-2. Would like your opinion on what to do here. Thanks, Bill From: Terje Io ***@***.***> Sent: Monday, October 4, 2021 9:47 AM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (Discussion #41) I don’t know if there is an easy way to conditionally compile (assemble) one .s file or another. Do you have any ideas how to do this? In the CubeIDE you can exclude a file from a build configuration, right click on it and select Properties: <https://user-images.githubusercontent.com/20260062/135890772-98dcfae5-6df4-4129-9606-e5c4ef8de124.png> I have not tried it but I guess that would work. Conditional assembly (by the preprocessor) is also possible? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIQJ6ZSJNYNVZYFNWTDUFHLAPANCNFSM5A4RF4QQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> . <https://github.com/notifications/beacon/ACQUGIWDWILWPTR2FT2Y2LTUFHLAPA5CNFSM5A4RF4Q2YY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAK4DIY.gif>

[terjeio]

Earlier you wrote:

At one point I tried to just add some of the timer 7 stuff to the original F401 .s file but whatever I did would not work.

What went wrong with this attempt and what did you try? I have compared the startup files and the current vector table has .word 0 where the interrupt handler should go (at line 198).
Changing line 198 to .word TIM7_IRQHandler /* TIM7 */ and adding

   .weak      TIM7_IRQHandler
   .thumb_set TIM7_IRQHandler,Default_Handler

at line 389 should work if I am not mistaken? If it works I think this would be my preferred way to do it as it no other files needs to be changed (and it will be compatible with PlatformIO builds).

I could put some warnings in the .map file for the skr-2. Would like your opinion on what to do here.

Warnings should be put on the driver homepage and in my_machine.h as it is unlikely anybody will open the .map file?
What is the hardware issue? Something to do with the buck converter?

[terjeio]

The problem is they use the same signal to switch both MOSFETs and the ground connection is very slow

I checked the Q1 datasheet - it is fast device, certainly a lot faster than the optocoupler used for switching Q2. However, switching it on directly from a MCU pin looks like bad engineering - 3.3V is a lower end Vgs on. And it has a rather large gate capacitance...

Sensorless homing seems to be a tricky business. What I have done is to try to figure out how to set it up from info in the datasheets and by looking at other implementations.
The only testing I have done is on my bench, not in a machine, and only by manually applying a load to the motors. So it will be great if you can take a look at this as well.

What could be noted is that it seems to me sensorless homing is just that, it cannot replace limit switches in a reliable way.

[terjeio]

I've started to look into this again and there are several issues popping up regarding TMC2209:

1. The Watterot driver (which I have) is not pin compatible with Bigtreetech, the DIAG pin location differs.
2. The Watterot driver is not pin compatible with their TMC2130 and TMC5160 drivers, again the DIAG pin location differs.
3. TMC2209 has push-pull diag/index outputs, TMC2130 and TMC5160 can be configured to open drain that allows wire-or'ing with a limit input.

1 and 2 may require pin cutting and bridge soldering. Or perhaps the Watterot driver is designed to use the INDEX output for homing? To be investigated.
3 can be more problematic depending on how the controller board is routed. If the DIAG output is connected to the corresponding limit input in a manner where the limit input can either ground the DIAG output or drive it to some voltage, this may destroy the driver(?) or at least load the output in a way that it is likely not designed for. The SKR2 board is IMO bad as it has limit inputs which allow the use of double throw switches that will connect the DIAG output to 5V - will it destroy the driver? Is this warned about?

I am changing pin init sequence to switch on the driver power before any other pins are configured as outputs. I guess it is better not to drive any TMC2209 pins when it is basically floating? What do you think?

Do you know if Marlin has code to detect drivers inserted the wrong way? And if Marlin uses/can use polling for stall detection if the DIAG output is not connected to a MCU input?

There are issues with my code as well...

[fitch22]

Hi Terje, Bummer that the Watterot is not pin compatible. They were first, you would think that BTT would copy their pin out, but maybe BTT wanted to sell their own. Marketing😊. Anyway, I have ordered some FYSETC 2209 drivers that are compatible with the SKR-2, I will report on them once they arrive. The thing I like about the FYSETC drivers is they have a 1K ohm in series with what they call the TX pin, which is the single pin the SKR-2 uses for the uart interface. Having a 1K there is a bit of protection for when the software serial interface does the wrong thing. As best I can tell, the INDEX pin is not connected to anything on the SKR-2, but the schematic is not completely clear. They show a 2 pin connection for each driver, which is the DIAG to endstop connection that uses a small jumper. But they don’t show the 2 pin portion of the header that mates with INDEX and DIAG to the board. For the SKR-2, if you want to use limit switches, you don’t populate the jumper. If you want to use sensorless homing, you can’t have a limit switch. For what it is worth, I have Marlin running with sensorless homing and it works perfect. I am trying to work through the differences in how the registers are programmed between Marlin and grblHAL, but as you know these devices are reasonably complicated. Everything affects everything else. It will take me a while to go through all of the 2209 code. Marlin has code to detect drivers in backwards. That was the reason for the circuit that causes trouble. If you look at where the 2 GND pins are, and you rotate the module 180 degrees, the GND pins line up between EN and STEP. Marlin sets EN to input which is pulled high on the board and drives STEP low. If it reads low on EN then the module is in backwards. If it reads high it is OK. To do this, they had to interrupt the GND and Vm or they would damage the module. When I put a scope on the signals involved, I saw some spikes on the MGND when the Vm was coming up. I think rise of Vm coupling through the 500uF onboard was the origin of this spike. I think the mosfet on the GND side was not sufficiently ON. From a timing standpoint, it should turn on before the power mosfet does, but BTT drove it from the weakest IO pin possible, PC13. The idea is OK, and perhaps with a better drive for the GND mosfet there would be no issues. But I am paranoid now and have jumpered across my GND mosfets on both the boards I have, and have not blown any more 2209s with this setup. I think you are OK turning on the power to the steppers before configuring output pins. The EN pin is pulled high (inactive), so the state of the other inputs should not matter. In the meantime, would you like me to get you a PR so that you can roll in the software serial code? I have not yet made any changes to include any warnings, but other than that I think the changes are ready. Bill From: Terje Io ***@***.***> Sent: Wednesday, October 6, 2021 11:44 PM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (Discussion #41) I've started to look into this again and there are several issues popping up regarding TMC2209: 1. The Watterot driver (which I have) is not pin compatible with Bigtreetech, the DIAG pin location differs. 2. The Watterot driver is not pin compatible with their TMC2130 and TMC5160 drivers, again the DIAG pin location differs. 3. TMC2209 has push-pull diag/index outputs, TMC2130 and TMC5160 can be configured to open drain that allows wire-or'ing with a limit input. 1 and 2 may require pin cutting and bridge soldering. Or perhaps the Watterot driver is designed to use the INDEX output for homing? To be investigated. 3 can be more problematic depending on how the controller board is routed. If the DIAG output is connected to the corresponding limit input in a manner where the limit input can either ground the DIAG output or drive it to some voltage, this may destroy the driver(?) or at least load the output in a way that it is likely not designed for. The SKR2 board is IMO bad as it has limit inputs which allow the use of double throw switches that will connect the DIAG output to 5V - will it destroy the driver? Is this warned about? I am changing pin init sequence to switch on the driver power before any other pins are configured as outputs. I guess it is better not to drive any TMC2209 pins when it is basically floating? What do you think? Do you know if Marlin has code to detect drivers inserted the wrong way? And if Marlin uses/can use polling for stall detection if the DIAG output is not connected to a MCU input? There are issues with my code as well... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIS6REC4XM5LV7IOF5LUFU6TJANCNFSM5A4RF4QQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> . <https://github.com/notifications/beacon/ACQUGIUT2R7PEKHQJF5KE5TUFU6TJA5CNFSM5A4RF4Q2YY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAK7XAA.gif>

[fitch22]

Terje, I was in the midst of comparing Marlin to Grbl settings when I tried a home with “G28 X0” and it worked nicely, just as it does with Marlin. If instead I home with “$H X”, it runs into the end and tries to keep going. I did not realize these two commands were different. Can you explain to me the difference and why one works and not the other? Thanks, Bill From: Terje Io ***@***.***> Sent: Wednesday, October 6, 2021 11:44 PM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (Discussion #41) I've started to look into this again and there are several issues popping up regarding TMC2209: 1. The Watterot driver (which I have) is not pin compatible with Bigtreetech, the DIAG pin location differs. 2. The Watterot driver is not pin compatible with their TMC2130 and TMC5160 drivers, again the DIAG pin location differs. 3. TMC2209 has push-pull diag/index outputs, TMC2130 and TMC5160 can be configured to open drain that allows wire-or'ing with a limit input. 1 and 2 may require pin cutting and bridge soldering. Or perhaps the Watterot driver is designed to use the INDEX output for homing? To be investigated. 3 can be more problematic depending on how the controller board is routed. If the DIAG output is connected to the corresponding limit input in a manner where the limit input can either ground the DIAG output or drive it to some voltage, this may destroy the driver(?) or at least load the output in a way that it is likely not designed for. The SKR2 board is IMO bad as it has limit inputs which allow the use of double throw switches that will connect the DIAG output to 5V - will it destroy the driver? Is this warned about? I am changing pin init sequence to switch on the driver power before any other pins are configured as outputs. I guess it is better not to drive any TMC2209 pins when it is basically floating? What do you think? Do you know if Marlin has code to detect drivers inserted the wrong way? And if Marlin uses/can use polling for stall detection if the DIAG output is not connected to a MCU input? There are issues with my code as well... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIS6REC4XM5LV7IOF5LUFU6TJANCNFSM5A4RF4QQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> . <https://github.com/notifications/beacon/ACQUGIUT2R7PEKHQJF5KE5TUFU6TJA5CNFSM5A4RF4Q2YY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAK7XAA.gif>

[fitch22]

Terje,
I think I answered my own question. Marlin uses G28 to home, but grbl uses it to go back to 0. So my crashing from $H is something I need to look into.

Sorry for the dumb question:-(.

Bill

[terjeio]

Bummer that the Watterot is not pin compatible. They were first, you would think that BTT would copy their pin out, but maybe BTT wanted to sell their own.

The BTT version IMO is better as it is compatible with the Watterot TMC2130/5160 drivers when it comes to the DIAG output...

In the meantime, would you like me to get you a PR so that you can roll in the software serial code?

Yes.

I have problems with getting sensible SG_RESULT values from the TMC2209, it is very sensitive to settings. Have to find out why - crappy motors could be part of it.

Code for setting up the drivers for homing starts here if you have not already found it.

[terjeio]

Seems I am getting closer to a solution to this. I will commit an update tomorrow that might work.

Leaving the PWM threshhold (tpwmthrs) at 0 or setting it higher than the homing seek rate is part of it, another is that the default slow homing rate @ 25 mm/min is too low. A high number of steps/mm seems to be a problem as well.

M913 can be used to set the PWM threshold at run-time, by PWM_THRESHOLD_VELOCITY at compile time. I wonder if this should be added as a $-setting? Leaving it at 0 causes my motors to stall at lower feedrates than when setting it.

I also found a clue to why the Watterot driver has the index output where the TMC2130/5160 drivers has the diag output. From page 63 in rev 1.05 of the manual:

"The index output allows precise detection of the microstep position within one electrical wave, i.e.
within a range of four fullsteps. With this, homing accuracy and reproducibility can be enhanced to
microstep accuracy, even when using an inexpensive home switch."

You do not use sensorless homing by ramming into a homing switch?

[terjeio]

Update is now committed. I have added a warning about the SKR2 board in my_machine.h, I think that should be enough.

[fitch22]

Terje, I am having a bit of trouble stepping through the code for homing with TMC2209. It seems that interrupts for the limit pins are not enabled unless I enable hard limits ($22). I am just trying to use a single driver for the X axis. I have $338=1 and $339=1. So far, I am unable to trigger the limit via the DIAG output of the TMC2209. What should I set $22 to? Thanks, Bill From: Terje Io ***@***.***> Sent: Monday, October 11, 2021 5:23 AM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (Discussion #41) Update is now committed. I have added a warning <https://github.com/grblHAL/STM32F4xx/blob/e2ec311d8a17f5393b9e24c8ce581cbdd3bd539b/Inc/my_machine.h#L36-L39> about the SKR2 board in my_machine.h, I think that should be enough. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIVQDDSEZFROEZY3CJ3UGLJJ7ANCNFSM5A4RF4QQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

[terjeio]

Set $21=0 and $22=1. The limit pins are polled when homing and limit interrupts are disabled.

So far, I am unable to trigger the limit via the DIAG output of the TMC2209.

And I am not able to make the drivers stop triggering the limit inputs, even when running a program... And the motors are just sitting on my desk unloaded.

For testing I am using ioSender and excercising the motors in the Trinamic tuner tab. There the SGRESULT is plotted in real-time and driver status can be queried while the motor is running. I have added the Signals box (same as in the main view) so that I can see if a limit input is triggered (long enough to show up), I am also monitoring DIAG pins with a scope.

I am running the motors at 12V, it seems from searching the internet that is too low so I will go fetch a 19V PSU from the workshop later.
From browsing the Marlin code I found that there are options to select different settings for chopconf depending on motor voltage - I guess there is a reason for that? We need to add that too?

From info the datasheet and searching the internet I am starting to wonder if sensorless homing is a good thing to have for general use as there are many parameters to tune. Many users will not be able to do that? See chapters 6, 7,11 and 12 in the datasheet.

[fitch22]

Terje, I think I will give your ioSender a try. I have just been using a terminal program or bCNC depending on what I had to do. I have had some better luck, I have had the homing trigger on the first bump and it pulls off the bump, but when hitting the end for the 2nd time, it keeps going (although it seems to time out shortly). I have tried to duplicate the speeds from Marlin as that works. If I have homing seek at 500mm/min and homing feed at 100mm/min, it detects the first bump. If I change homing feed to the same 500, it runs into the stop and tries to keep going. Why homing feed influences the first bump I don’t understand. For the chopconf, Marlin does have some defaults. I think it might be a good idea for grbl to do something similar. I am running my motors at 24V but the Marlin defaults of 12V and 24V both worked with no discernable difference. When I use the TMC calculator I get yet another set of numbers for chopconf, and they also work. Perhaps instead of providing defaults for the chopconf, the docs could refer the user to the TMC calculator to choose the best values. Whatever they did in Marlin, they made it easy to tune. All you have to do is adjust the sg threshold. Nothing else gets changed. However I should mention that Marlin suggests that you do not use the bump and repeat. Maybe the repeat is the problem. Is there a way to disable this in grbl? Bill From: Terje Io ***@***.***> Sent: Tuesday, October 12, 2021 8:52 PM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (Discussion #41) Set $21=0 and $22=1. The limit pins are polled when homing and limit interrupts are disabled. So far, I am unable to trigger the limit via the DIAG output of the TMC2209. And I am not able to make the drivers stop triggering the limit inputs, even when running a program... And the motors are just sitting on my desk unloaded. For testing I am using ioSender <https://github.com/terjeio/ioSender> and excercising the motors in the Trinamic tuner tab. There the SGRESULT is plotted in real-time and driver status can be queried while the motor is running. I have added the Signals box (same as in the main view) so that I can see if a limit input is triggered (long enough to show up), I am also monitoring DIAG pins with a scope. I am running the motors at 12V, it seems from searching the internet that is too low so I will go fetch a 19V PSU from the workshop later. From browsing the Marlin code I found that there are options to select different settings for chopconf depending on motor voltage - I guess there is a reason for that? We need to add that too? From info the datasheet and searching the internet I am starting to wonder if sensorless homing is a good thing to have for general use as there are many parameters to tune. Many users will not be able to do that? See chapters 6, 7,11 and 12 in the datasheet. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIWFVLNQ2LFRXJBD5YLUGT663ANCNFSM5A4RF4QQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

[fitch22]

Terje,
Some good progress. I made the first change above and now I can hit the bump, pull off, hit the bump again, and pull off. It does not try to keep going.

However, the above is with both $24 and $25 set to 500. If I set $24 to 100, what happens is this: seek to limit, bump, pull off, instead of changing direction, it appears it detects a bump immediately and pulls off again and I get ALARM:8. $24=400 works, but $300 does not.

I agree with you, having the feed rate the same as seek rate makes little sense. I do know that the sg threshold depends on the speed when it hits the obstacle. It might require a different sg threshold for seek and feed. Maybe this is why Marlin just does not do the bump thing.

Once this is all working, a feature that might be nice is to have a pull off distance after the 1st bump different from the pull off on the 2nd bump. Right now they are both the same.

I grabbed a copy of ioSender (bleeding edge). Nice work, by the way! I did not see a Trinamic tuning tab. What do I have to do to enable this?

Bill

[terjeio]

Great, we are getting closer then.

I do know that the sg threshold depends on the speed when it hits the obstacle. It might require a different sg threshold for seek and feed.

I have added a function pointer to the core that can be used, if assigned to it will be called when the homing feed rate is set.

core/limits.c

Lines 318 to 319 in 79882cf

	if(grbl.on_homing_rate_set)
	grbl.on_homing_rate_set(cycle, homing_rate);

If the Trinamic plugin sets it to a local function it can be used for changing whatever parameters it want to.

Once this is all working, a feature that might be nice is to have a pull off distance after the 1st bump different from the pull off on the 2nd bump.

I don't know if that is a good idea or even neccessary. A new setting may only add complexity?

I did not see a Trinamic tuning tab. What do I have to do to enable this?

Strange. Do you have TMC=<n> in the NEWOPT element in the $I response? The presence of that is used to enable the tab. I not there then perhaps you have compiled with compatibility level set too high?

[fitch22]

Terje,
I played with the sg threshold and the homing feed rate. Turns out that when I had the feed rate much lower than the seek rate, the motors would trip the sg threshold that was good for the seek rate. For me, the threshold for the seek rate of 500 was about 120, and that was so high that as soon as the motors would start to move at the feed rate of 100, they would trip. I was able to find a good threshold for the feed rate of 100 (52 worked, 53 did not). With this set as my threshold, the motor seeks at 500, hits the end, pulls off, feeds at 100, kisses the end and pulls off one last time.

Time to add Y and Z...

Bill

[fitch22]

Regarding the Trinamic tab, I just grabbed your bleeding edge version of ioSender from your web site. I do show TMC=1 in the response from $I. I will try your released version and check my compatibility level (I have not changed from the default so I expected it to be 0).

Bill

[terjeio]

I have just uploaded a new edge version, same as I am using now.

[fitch22]

Terje, The released version has the Trinamic tab. I will try your new edge version. Things are looking pretty good at the moment. Yay! From: Terje Io ***@***.***> Sent: Wednesday, October 13, 2021 12:01 PM To: grblHAL/core ***@***.***> Cc: fitch22 ***@***.***>; Author ***@***.***> Subject: Re: [grblHAL/core] Can I help with Trinamic support? (Discussion #41) I have just uploaded a new edge version, same as I am using now. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQUGIQBI7EWMOKP5H2EHBDUGXJOPANCNFSM5A4RF4QQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

[fitch22]

Terje,
I see something unexpected with the TMC2209, wonder if you have, too.

After I dial in the sg threshold for the speed and current settings I have and good detection of the end of travel, if I then just jog the axis, I see the DIAG pin pulse high at the end of the movement. This end of travel pulse seems to be generated when the motor stops. I can decrease the sg threshold and make this go away, but then it is not the right value for detecting the limits.

I stumbled across this with working on the sensorless homing. I have things set for homing seek at one rate and threshold followed by a homing feed at different rate and threshold. I was getting an Alarm:8 because of the DIAG pulse at the end of the final pull-off. It is difficult to find a threshold at very low feed rates (default is 25), the values I need are single digits. Perhaps the solution is to insert a delay after the final pull-off so the DIAG pulse can expire before the check for the limit switch is done. Thoughts?

Bill

[fitch22]

Terje,
I have sensorless homing working very nicely using 2 separate sg thresholds, one for homing seek rate and another for the homing feed rate. I can home each axis individually, for example $HX or $HY. If I try to home all axis at once with $H things break and I don't understand why.

I see that in limits.c around line 315 the homing rate is increased by sqrtf(n_active_axis). This appears to speed up the rate of x and y when homing them together. Is there some other math going on somewhere else that reduces the x and y rates by the same amount?

When I try just a $H, the following happens:

1. Z axis gets homed just as it does using $HZ.
2. X and Y both move toward their limit and trigger the DIAG output of the TMC2209s.
3. X and Y both move out the pull-off distance. Some times I get an alarm because one of the DIAG pins pulses.
4. X and Y move at the feed rate toward the limit again. This time Y gets a pulse on its DIAG pin but X does not. Eventually I get an alarm 9.

I do not know why the X axis behaves differently when homing with Y vs homing just X. I have verified that the correct thresholds are loaded for both x and y, same as when homing individual axis. The rates seem to be the same if I comment out line 315 in limits.c. I am suspicious that the rate of the individual axis is different than when homing individually and that I caused it by commenting out line 315.
But commenting out the line should slow things down, and slowing things down should work with a lower sg threshold than what is programmed, so I should still get DIAG output.

And I don't seem to be able to single step through a lot of this code since it is time sensitive.

One last question: I wanted to break up the homing cycle so that $H would home z first, then x and then y. Modifying the HOMING_CYCLE_1 and _2 in config.h did not seem to change any behavior. Is there another hidden setting I need to change?

Thanks,
Bill

[fitch22]

@terjeio You da man! The fix you posted works great.

Hate to burden you with more questions, but right now I have only dealt with x, y, and z axis. Should I provide for sensorless homing for all possible axis (a, b, c, u, v)?

Next question is my changes only affect trinamic.c and trinamic.h. These are in a submodule of my STM32F4xx project. How do I do a pull request? Should I clone the grblHAL/Plugins_motor repository and offer a PR to that, or is there a way to offer a PR from my STM32F4xx project for these changes?

Thanks,
Bill

[terjeio]

The fix you posted works great.

Good to hear.
I have added a parameter to grbl.on_homing_rate_set so that Stallguard can be switched off during pulloff, not sure if this has any value but could be ok to have the option.

Should I provide for sensorless homing for all possible axis (a, b, c, u, v)?

A, B, and C should be supported "out-of-the-box" without any changes - U and V can wait, support for those are work in (slow) progress.

Should I clone the grblHAL/Plugins_motor repository and offer a PR to that, or is there a way to offer a PR from my STM32F4xx project for these changes?

You should try to do it from the STM32Fxx project and see how it goes. If git is any good it should work...

Be aware that I have pending changes to the same files as well so I have to do a merge locally. There are changes to other files as well, among them a simplified Trinamic HAL.

[fitch22]

Terje,
Where did you make the change to on_homing_rate_set to turn off stallguard during pull off? I would like to use that.

Bill

[terjeio]

Here is the new homing code:

// Configure sensorless homing for enabled axes
static void trinamic_on_homing (axes_signals_t axes, float rate, bool pulloff)
{
    uint_fast8_t motor = n_motors, axis;

    axes.mask = driver_enabled.mask & trinamic.homing_enable.mask;

    if(axes.mask) do {
        axis = motor_map[--motor].axis;
        if(bit_istrue(axes.mask, bit(axis))) {
            if(pulloff) {
                if(trinamic.driver[motor].mode == TMCMode_StealthChop)
                    stepper[motor]->stealthchop_enable(motor);
                else if(trinamic.driver[motor].mode == TMCMode_CoolStep)
                    stepper[motor]->coolstep_enable(motor);
            } else
                stepper[motor]->stallguard_enable(motor, rate, settings.axis[axis].steps_per_mm, trinamic.driver[axis].homing_sensitivity);
        }
    } while(motor);
}

// Enable/disable sensorless homing
static void trinamic_homing (bool on, bool enable)
{
#ifdef TMC_HOMING_ACCELERATION
    static float accel[N_AXIS];
#endif

    if(limits_enable)
        limits_enable(on, enable);

    homing.mask = driver_enabled.mask & trinamic.homing_enable.mask;

    is_homing = enable;
    enable = enable && homing.mask;

    if(enable) {
        grbl.on_homing_rate_set = trinamic_on_homing;

#ifdef TMC_HOMING_ACCELERATION
        uint_fast8_t axis = 0, axes = homing.mask;
        while(axes) {
            if(axes & 1 && accel[axis] == 0.0f) {
                accel[axis] = settings.axis[axis].acceleration / (60.0f * 60.0f);
                settings_override_acceleration(axis, min(TMC_HOMING_ACCELERATION, accel[axis]));
            }
            axes >>= 1;
            axis++;
        }
#endif
#if TMC_POLL_STALLED
        if(limits_get_state == NULL) {
            limits_get_state = hal.limits.get_state;
            hal.limits.get_state = trinamic_limits;
        }
        diag1_poll = 0;
#endif
    } else {

        uint_fast8_t motor = n_motors, axis;

        do {
            axis = motor_map[--motor].axis;
            if(bit_istrue(driver_enabled.mask, bit(axis))) {
                if(trinamic.driver[motor].mode == TMCMode_StealthChop)
                    stepper[motor]->stealthchop_enable(motor);
                else if(trinamic.driver[motor].mode == TMCMode_CoolStep)
                    stepper[motor]->coolstep_enable(motor);
#ifdef TMC_HOMING_ACCELERATION
                if(accel[axis] > 0.0f) {
                    settings_override_acceleration(axis, accel[axis]);
                    accel[axis] = 0.0f;
                }
#endif
            }
        } while(motor);
#if TMC_POLL_STALLED
        if(limits_get_state != NULL) {
            hal.limits.get_state = limits_get_state;
            limits_get_state = NULL;
        }
#endif
    }
}

There are many other changes as well, also some in the core so you cannot just paste it in. I can push an update, but then your changes to trinamic.c/trinamic.h has to be redone by you. Should I push them or wait for your PR and merge on my side?

TMC_HOMING_ACCELERATION can be set to reduce acceleration during homing - can reduce the risk of unwanted DIAG signalling, TMC_POLL_STALLED is off by default as there no need to poll the drivers during homing when DIAG output is wired to limit inputs.

Here is the new trinamic.c/trinamic.h code if you want to take a look.

trinamic.zip

[fitch22]

Terje,
It is probably easier for you if I get you a PR with my changes first. I will get you something later today. I am going to try as a single PR with changes for my BTT board and the trinamic files. If that does not work I will create 2. I think they are easily merged.

Bill

[fitch22]

Terje,
I tried to make a release build that uses USB for communication. When I do, my board does not see the trinamic drivers (they don't show up in NEWOPT: list). When I build a debug version, the TMC stuff works fine but I can't use the USB and use USART1 instead. I am in a catch 22, I can't debug why the release would not see the trinamic drivers. Other than some optimization the only difference between my debug and release builds are related to the USB vs USART.

This is really the first time I have tried a release build with the TMC2209s. Any conflict with interrupts or anything else come to mind that could cause this? At this point my TMC2209 stuff would not be very useful without the USB:-(.

Bill

[terjeio]

Any conflict with interrupts or anything else come to mind that could cause this?

Some folders are missing from the Source Location tab in Paths and Symbols under C/C++ General? Compare release and debug configurations.

[fitch22]

Terje,
Well this is embarrassing. Turns out it was optimization after all. When I turned on even -01 in the debug build, I got the same problem. My quick solution was to add more delay to the end of tmc_uart_read(). Now with full optimization I can run with USB and reload new firmware from the SD card. I need to understand why my previous version did not have enough delay, so I pulled my related PR until I understand.

Thanks for your help and patience.

Bill

[fitch22]

Terje,
Created 2 PRs, one for the changes to trinamic.[ch] and the other for changes to btt_skr_2.0.c. There are changes I have not included, your fix to limits.c and to tmc2209hal.c, both required to get everything to work. Both PRs look mergeable. Once you roll in your changes to allow stallguard to turn off during pull-off, I will incorporate that into my code, too, or if it is easier for you to do it, that's OK too. To me it makes sense to only have stallguard on during the 2 approach cycles (for sensorless homing).

Bill

[terjeio]

I now have manually merged your changes and committed an update, I hope I have not broken anything...