grblhal / plugins_motor Goto Github PK

This (and the next line) should omit the hal. part in order to properly chain through the user_mcode call 'stack'. Goes into an infinite loop when called. This prevents other user defined mcodes that are later in the stack from running.

Hi, I'm having 2 main issues. 1) Enabling hybrid mode for switching between stealthchop and spreadcycle and 2) Stallguard for sensorless homing.

Hybrid Issue:
I cannot determine if TMC2209_TPWM_THRS in tmc2209.h is being honored or overwritten by PWM_THRESHOLD_VELOCITY in trinamic.h. TPWMTHRS from the 2209 datasheet is the TSTEP at the desired velocity, I cannot determine if you account for the unit conversion between velocity and TSTEP properly. Also after setting PWM_THRESHOLD_VELOCITY a broken piece of code is exposed here:

The error is
../main/motors/trinamic.c:670:98: error: 'motor_settings_t' {aka 'struct '} has no member named 'steps_per_mm'

Stallguard Issue:
When enabled, stallguard seems to be oversensitive even during a typical jog. There is persistent stalling after issuing M122 x S1. M122 x S1 shows SG_RESULT ranging from 0 to 300 which almost implies either it's configured wrong or stallguard cannot be used except during homing. Using the calculator below, TMC2209_TPWM_THRS is set to 38 (corresponding to 6000mm/min). I've tried TMC2209_COOLSTEP_THRS ranging from 100 to 200 (which is 1000-2200mm/min and reasonable homing speeds). The datasheet says diag is only pulsed when TCOOLTHRS ≥ TSTEP > TPWMTHRS. I used the calculator below for calculating Txxx. I've been trying to unravel this mystery, but I need your help in figuring it out. I know for instance your default settings do not satisfy the conditions gating diag being pulsed and perhaps the unit consistency is a problem as everything must be implemented in units of TSTEP.

TMC2209_Calculations.zip

Thank you!

I have a SKR1.4 board with TMC 5160 in SPI. when i poll the drives this is what is see below. If I adjust the threshold it seams to change my steps per mm, Olso the Vsense is set to .075 in the config but the poll shows N/A the motor runs very choppy like is has no micro-stepping. I'm not sure what could be the issue. Im using IOsender 2.0.34, and the lpc176x_210809 build.

Hi
I'm having issues with the SKR Pico Board where the steppers run very slowly. I'm using 1/8th micro-stepping with a 1.5mm lead screw pitch and 1066 steps/mm. This works fine on my foam cutter using Grbl-Mega-5x using an Arduino Mega 2560. I've been running this for 3 years and built many RC model aircraft. I decided it was time to look at 32-bit with the RP2040.
I just have the motor on the bench at the moment and even if I try different step/mm settings and micro-stepping they turn very slow, so slow I didn't think they were turning at first. I've tried my G-code sender and ioSender and both show the same slow running in the DRO's.
I decided to enable TMC_DEV to further investigate but I get compiling errors. The first error being

_[build] C:\Users\khowl\Documents\Code\RP2040\motors\trinamic.c:776:111: error: 'stepper[report.sg_status_motor]' is a pointer; did you mean to use '->'?
[build] 776 | sprintf(sbuf, "[SGPARAMS:%ld:%d:%d:%d]" ASCII_EOL, report.sg_status_motor, stepper[report.sg_status_motor].coolconf.reg.sfilt, stepper[report.sg_status_motor].coolconf.reg.semin, stepper[report.sg_status_motor].coolconf.reg.semax);

TMC_DEV.txt

I've attached the compiler output which has more errors. Without TMC_DEV enabled it compiles without any errors.

As an additional test, I have one of the little Pico Boards and if I use PicoBoB as the board in my_machine.h the DRO's show the normal speed in the DRO's. So I suspect it's something in the Trimanic 2209 drivers causing the issue.

Any help greatly appreciated.
Keith

I am trying to change the number of microsteps with setting $15x, the command is accepted but when reading out the setting the value has not changed.
And is there some documentation on setting $17x, $20x, $21x, $22x?

Hello, so when compiling thru MCUX i get this error:

/src/trinamic/TMC2130_I2C_map.h:44:10: fatal error: trinamic2130.h: No such file or directory
44 | #include "trinamic2130.h"
| ^~~~~~~~~~~~~~~~

So i just changed 44 | #include "trinamic2130.h" to #include "tmc2130.h" and its working, but im not sure if its correct.

EDIT: this issue should be in : Trinamic-library/TMC2130_I2C_map.h

Is there a good way to check to see if the setting for TRINAMIC_R_SENSE is changed from the default 0f 75 mOhm after the firmware is built? I am using the BTT 5160 Plus external driver modules and they use a 22 mOhm current sense resistor rather than the standard 75 mOhm. I have added -D TRINAMIC_R_SENSE=22 to platformio.ini as I am using platformIO to perform the builds but with testing I am still drawing over 3.5A for a driver when the current is set to 1A. Is there a way to verify that the value is actually included properly?

Found some odd behaviour when trying per axis homing, while having sensorless enabled on partial axes. I suspect the trinamic_on_homing function has some strange logic leading to this.

To trigger the bug it is required to enable the tmc drivers on all drivers (3 in my case).

The bug seems triggered when setting partial sensorless homing axes using $339:
e.g. (debug added in my build)

This is the correct output when enabling all sensorless axes:

$339=7
ok
$HX
[SG: Motor: 2]
[SG: TCOOLTHRS set: 135]
[SG: Sens set: 80]
[SG: Motor: 1]
[SG: TCOOLTHRS set: 281]
[SG: Sens set: 30]
[SG: Motor: 0]
[SG: TCOOLTHRS set: 281]
[SG: Sens set: 100]

Its sets only the last motor parameters (motor 2) and stops.
$339=4
ok
$HX
[SG: Motor: 2]
[SG: TCOOLTHRS set: 135]
[SG: Sens set: 80]

I have a skr1.4 turbo LPC1769 board running the latest build as of 10/31/21. I have TMC-2160 drivers installed. and jumpers in spi mode. IOsender auto recognizes them and added the Trimatic tab and I can see the driver status so everything seems to be configured corectly. in the LPC Grblhal build TMC5160 is defined.

The issue I have is the steppers are loud and choppy/vibrate. completely different from when I use them with other firmware. it appears that the Rsence and some other configurations are not being applied correctly. based on the TMC status screen also if i jog and re-poll the tmc's the settings seem to change I have attached the Grblhal trimatic build config and the TMC screen from IOsender. I don't see a few of the lines populated and the values seem off from what I see online for 5160's I think it has to do with the rsense value not showing.



Thank you for your help

It would be great if we could utilize Trinamic's feature set for some safety, namely:

• Different motor currents for different modes (G0 or jogging should require much less than steel milling).
• StallGuard thresholds associated with those modes / current settings.
• Either or both modulated by the expected motion system load (ie. acceleration being more demanding than constant rapid movement).
• M-code configurable current / SG thresholds, so that wood-cutting jobs can run much closer to stalling (causing no damage on crash), while steel-cutting ones can ask for higher values.

(Just some ideas.)

Exceeding these thresholds (triggering StallGuard) would result in an E-stop (or something equivalent, doing M5, disabling the EN motor driver pins, etc.).

This is something I'm considering doing on a standalone Arduino (probably with a potentiometer for the current / SG setting), but it would be better to have it natively supported as it could integrate with motion planning more closely.

The use case is mainly for teaching CNC programming to students / novices and minimizing the damage caused by them. :)

Thanks!

When homing specific axes, which have their max rate set lower than the locate/seek homing rate, the TCOOLTHRS is set according to the locate/seek homing rate. This leads to TCOOLTHRS being too low to trigger DIAG/stallguard output for the actual speed the motor is planned/run at.

I've implemented a fix for per-axis homing here but this could probably be done more elegantly:
fc04c05

One of the things that comes to mind is implementing per-axis seek/feed rates for homing. Since also now I am limited also to seeking at the maximum speed of the axis.

(full homing $H still seems to be somewhat problematic for me. Running too slow? But this might be a separate issue.)