@dc42 I tried reducing the "special moves" acceleration with M201.1.

I finally managed to set up sensorless homing, but it's still not very stable. I believe the issue is more related to the configuration than the threshold value.

Occasionally, a stall is detected at the start of the first homing motion but never again. Restarting the mainboard sometimes resolves the issue, but it tends to reappear after 2-3 reboots.

I ended up with with this homing file (axis is C) :

M400
M574 C1 S3 ; setup sensorless endstop
M915 C R0 S40 ; set sensitivity
M569 P22.0 V11 ; increase TPWMTHRS
M913 C30 ; reduce current to 30%
M400
G4 P500 ; wait 500ms - don't know if usefull
G91
G1 H1 C-75 F120
G1 C0.5 F600
G90
M400
M569 P22.0 V117 ; restore TPWMTHRS
M574 C0 ; remove endstop
M913 C100 ; reset current to 100%
M400

As you can see I'm creating and deleting the endstop every time. I don't know why, but it's the most stable configuration I could find.

Hi,

This might be a simple question with many ideological, preferential, or historical reasons behind it, but is there any technical justification for using mm/min instead of mm/s as the feed rate unit?

Acceleration is typically expressed in mm/s², and stepper drivers operate in microsteps per second. From a user perspective, mm/s also feels more intuitive and tangible.

Some might argue that mm/min provides greater resolution, but since we can use floating-point values, that doesn't seem like a valid argument to me.

I’d love to hear your thoughts.

Thanks!

@dc42 Thanks for the the binary. I tested it today, but couldn't setup a proper stall detection.
Either a stall is detected immediately on the start of the first G1 H1 motion (and then never again).
Or it is not detected at all.

Maybe it's worth mentioning that I'm using the 1LC to control a small auxiliary axis. Nema 11 stepper motor with 670mA nominal current, ball screw linear axis with 1mm pitch, max. speed ~15mm/s (900rpm).

Is there a way to report the value of SG_RESULT register while moving the axis?

@droftarts @dc42 By the way, there's another issue related to smart drivers on expansion boards. The parameter C of M569 is not handled (yet?).

@droftarts @dc42

As I’ve been thoroughly reading the Trinamic documentation to better understand their technology (StealthChop, SpreadCycle, CoolStep, StallGuard, etc.), I also examined the expansion board firmware and believe I’ve identified the issue.

In the TMC22xx.cpp file, an interrupt is defined for the "diag" pin, but it seems it is disabled by default.

#if HAS_STALL_DETECT
	diagPin = p_diagPin;
	IoPort::SetPinMode(p_diagPin, INPUT_PULLUP, false);
	AttachPinInterrupt(p_diagPin, DiagPinInterruptEntry, InterruptMode::rising, CallbackParameter(p_driverNumber), false);
	// Leave the interrupt disabled until we enable a stall endstop on this driver
#endif

Later, in the SmartDrivers::SetStallEndstopReporting function, it looks like we're missing a call to TmcDriverState::EnableDiagInterrupt, which prevents the interrupt from ever being enabled.

GCodeResult SmartDrivers::SetStallEndstopReporting(uint16_t driverNumber, float speed, const StringRef& reply) noexcept
{
	if (driverNumber < GetNumTmcDrivers())
	{
		const char *_ecv_array _ecv_null const msg = driverStates[driverNumber].CheckStallDetectionEnabled(speed);
		if (msg == nullptr)
		{
			stallEndstopsEnabled.SetBit(driverNumber);
			return GCodeResult::ok;
		}
		reply.printf(msg, CanInterface::GetCanAddress(), driverNumber);
		return GCodeResult::error;
	}
	else
	{
		stallEndstopsEnabled.Clear();
		for (TmcDriverState& ds : driverStates)
		{
			ds.DisableDiagInterrupt();
		}
		driverStallsToNotify = 0;
		return GCodeResult::ok;
	}
}

I'll have a try on Monday and keep you posted.

Hi there,

I'm in the same situation...
@Aurimas did you find a solution?

Thanks

@dc42 I see... I was trying to use the default baud rate of the device I communicate with, which is 57600. I tested with 9600 and it seems much better!
Thank you very much! I would never have thought of such a thing...

@dc42 Indeed, this is done in Platform::InitialiseInterupts like that:

...
#elif SAMC21
		NVIC_SetPriority(StepTcIRQn, NvicPriorityStep);
		NVIC_SetPriority(CAN0_IRQn, NvicPriorityCan);
# if NUM_SERIAL_PORTS >= 1
		NVIC_SetPriority(Serial0_IRQn, NvicPriorityUart);
# endif
...

And I've defined Serial0_IRQn as SERCOM2_IRQn.

Hi,

I'm trying to implement a serial communication on the TOOL1LC firmware (v3.5.3) using pins PA09 and PA12 (io0.in/out). So far, I managed to transmit what I want from the board, but I can't receive proper data and I don't understand why.

Regarding the ports configuration and serial initialization this is what I've done:

void SerialPortInit(AsyncSerial*) noexcept
{
    SetPinFunction(PortAPin(9), GpioPinFunction::D); // Rx on PA09, sercom 2, pad 1
    SetPinFunction(PortAPin(12), GpioPinFunction::C); // Tx on PA12, sercom 2, pad 0
}

void SerialPortDeinit(AsyncSerial*) noexcept
{
    pinMode(PortAPin(9), PinMode::PIN_MODE_NOT_CONFIGURED);
    pinMode(PortAPin(12), PinMode::PIN_MODE_NOT_CONFIGURED);
}

AsyncSerial uart0(2, 1, 128, 128, SerialPortInit, SerialPortDeinit);

extern "C" void SERCOM2_Handler()
{
    uart0.Interrupt();
}

Then, uart0 is used in a handler to send and read data periodically (it is spinning in the heating task, so every 250ms).

Sending data works perfectly with method uart0.write(..), but when data is uart0.available() I get only 0s (null) when I uart0.read().

I know uart is officially not supported on expansion boards, but this is the only option I have to communicate with the device I want to use. And I don't have the knowledge to build a completely new expansion board using a SammyC21, in terms of electronics.

Any help or hint would be greatly appreciated.
Thanks

@dc42 I enabled the pullup resistor for the io0.out pin, (and I found out a bad crimping contact for the X endstop... ^^').
Everthing works fine now. Thank you David.