Topics created by Gixxerfast

@o_lampe I tend to agree, however, I do like to add inlayed pieces to my parts. Most of what I do is more functional parts versus toys, so I like to add indicators, logos, etc.

The biggest reason for me is to use soluble supports. Understood that resin printers do supports better, but I really couldn't get over the cleanup and smell. I may try it again when I can move the operation to my new shop.

The bed plate acts as a heat sink/heat spreader for the heater. If part of the heater separates from the bed, that part gets extra hot. Here's what happens to the heater when the 3M adhesive starts to let go:

alt text

@jay_s_uk @R4ffers
Thank you.

@gixxerfast maybe it's something simple like needing to add a delay between initialising the UART (so that the TxD output is high) and the first communication with the TMC2209.

@gixxerfast good luck, I hope you find the reason. I have the Sammy-C21 also, but have to install the firmware first.

@gixxerfast I will change the baud rate to be 115200 on the SammyC21 to match the bootloader.

OK, so far so good! It's been stable for a while now so maybe I can trust it I don't totally trust it. I had to change in a few more places.

@dc42 Well, that look promising 🙂

So now (I really hope it lasts):

Driver 0: pos 80000, 80.0 steps/mm,standstill, SG min 16, read errors 0, write errors 0, ifcnt 70, reads 13761, writes 1, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0 Driver 1: pos 574280, 574.3 steps/mm,standstill, SG min 16, read errors 0, write errors 0, ifcnt 68, reads 13762, writes 1, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0 $ git diff src/Movement/StepperDrivers/TMC22xx.cpp diff --git a/src/Movement/StepperDrivers/TMC22xx.cpp b/src/Movement/StepperDrivers/TMC22xx.cpp index 4b8a1acb..b301af8e 100644 --- a/src/Movement/StepperDrivers/TMC22xx.cpp +++ b/src/Movement/StepperDrivers/TMC22xx.cpp @@ -1441,7 +1441,7 @@ void TmcDriverState::AbortTransfer() noexcept #if TMC22xx_USES_SERCOM DmacManager::DisableChannel(DmacChanTmcTx); DmacManager::DisableChannel(DmacChanTmcRx); - sercom->USART.CTRLB.reg &= ~(SERCOM_USART_CTRLB_RXEN | SERCOM_USART_CTRLB_TXEN); + sercom->USART.CTRLB.reg &= ~(SERCOM_USART_CTRLB_RXEN/* | SERCOM_USART_CTRLB_TXEN*/); //UER while (sercom->USART.SYNCBUSY.bit.CTRLB) { } #else uart->UART_IDR = UART_IDR_ENDRX; // disable end-of-receive interrupt @@ -1497,17 +1497,18 @@ inline void TmcDriverState::StartTransfer() noexcept regnumBeingUpdated = regNum; #if TMC22xx_USES_SERCOM - sercom->USART.CTRLB.reg &= ~(SERCOM_USART_CTRLB_RXEN | SERCOM_USART_CTRLB_TXEN); // disable transmitter and receiver, reset receiver + sercom->USART.CTRLB.reg &= ~(SERCOM_USART_CTRLB_RXEN /*| SERCOM_USART_CTRLB_TXEN*/); // disable /*transmitter <--- UER*/ and receiver, reset receiver while (sercom->USART.SYNCBUSY.bit.CTRLB) { } #else uart->UART_CR = UART_CR_RSTRX | UART_CR_RSTTX; // reset transmitter and receiver #endif const uint8_t regNumber = (regNum < WriteSpecial) ? WriteRegNumbers[regNum] : specialWriteRegisterNumber; - SetupDMASend(regNumber, writeRegisters[regNum]); // set up the DMAC + //SetupDMASend(regNumber, writeRegisters[regNum]); // set up the DMAC <---UER #if TMC22xx_USES_SERCOM dmaFinishedReason = DmaCallbackReason::none; DmacManager::EnableCompletedInterrupt(DmacChanTmcRx); - sercom->USART.CTRLB.reg |= (SERCOM_USART_CTRLB_RXEN | SERCOM_USART_CTRLB_TXEN); // enable transmitter and receiver + sercom->USART.CTRLB.reg |= (SERCOM_USART_CTRLB_RXEN /*| SERCOM_USART_CTRLB_TXEN*/); // enable transmitter and receiver <--- UER + SetupDMASend(regNumber, writeRegisters[regNum]); #else uart->UART_IER = UART_IER_ENDRX; // enable end-of-transfer interrupt uart->UART_CR = UART_CR_RXEN | UART_CR_TXEN; // enable transmitter and receiver @@ -1520,19 +1521,20 @@ inline void TmcDriverState::StartTransfer() noexcept AtomicCriticalSectionLocker lock; #if TMC22xx_USES_SERCOM - sercom->USART.CTRLB.reg &= ~(SERCOM_USART_CTRLB_RXEN | SERCOM_USART_CTRLB_TXEN); // disable transmitter and receiver, reset receiver + sercom->USART.CTRLB.reg &= ~(SERCOM_USART_CTRLB_RXEN/* | SERCOM_USART_CTRLB_TXEN*/); // disable transmitter and receiver, reset receiver while (sercom->USART.SYNCBUSY.bit.CTRLB) { } #else uart->UART_CR = UART_CR_RSTRX | UART_CR_RSTTX; // reset transmitter and receiver #endif const uint8_t readRegNumber = (registerToRead < NumReadRegisters) ? ReadRegNumbers[registerToRead] : specialReadRegisterNumber; - SetupDMARead(readRegNumber); // set up the DMAC + //SetupDMARead(readRegNumber); // set up the DMAC #if TMC22xx_USES_SERCOM dmaFinishedReason = DmaCallbackReason::none; DmacManager::EnableCompletedInterrupt(DmacChanTmcRx); - sercom->USART.CTRLB.reg |= (SERCOM_USART_CTRLB_RXEN | SERCOM_USART_CTRLB_TXEN); // enable transmitter and receiver + sercom->USART.CTRLB.reg |= (SERCOM_USART_CTRLB_RXEN/* | SERCOM_USART_CTRLB_TXEN*/); // enable transmitter and receiver + SetupDMARead(readRegNumber); #else uart->UART_IER = UART_IER_ENDRX; // enable end-of-receive interrupt uart->UART_CR = UART_CR_RXEN | UART_CR_TXEN; // enable transmitter and rec

@engikeneer Thanks for the confirmation. I Just connected external 5v and no magic smoke was released.

@zapta the example I linked to is for use where Z hasn't been homed.
and the docks typically have a little lip to stop the probe dropping out although its still a possibility if held upside down at the right angle.
STLs for the V2.4 can be found here

@rodokas I can only work with what I see (-;

@gixxerfast said in (EDIT) Already supported in RRF - Mesh probing with Rel Ref Ind:

BTW: The -3 flag to the G30 will produce the same result just the other way around, adjusting the probe offset instead of the read height value ?

Yes, G30 S-1 will adjust the trigger height to match the current Z instead f the other way round.

Use the K parameter on the G30 and G29 commands to select which Z probe to use for each command.

@achrn Yes, and the fan speed is so low it doesn't really matter if they are on on or not. It makes no difference. Estoy muy contento 🙂

@aprz I don't know if you can even do that. Guess it depends on which board you have.

However I can't say if it would help but I think it's a hard way to go to fix something that might be fixed with other motors.

I should have changed a long time ago but I was convinced it was an "upgrade" even though I see now that those motors do not belong on a 2.4 IMHO. The OMC BOM motors are quite affordable.

I hope you can make it work better.

60 mm/sec on a Voron, or really any good corexy, is painfully slow 😉

Cheers

@gixxerfast Thanks for reporting this, I've prepared a bug fix for the upcoming software version 3.4-b5.

@gixxerfast blinking slowly and continuously in time with the one on the main board is good, it means that it has established time sync with the main board. There is a separate green LED that indicates that the 1XD board is receiving CAN commands from the main board.