RepRapFirmware 3.0 port for LPC1768/9 based boards

That depends how you wish to use the WiFi module, as an access point or to connect to your local network. To connect to your WiFi network follow the instructions for the Duet WiFi here:
[duet3d.dozuki.com]

Guys, thank you very much) Everything worked out and works))))

Can this port only be used if you have the WIFI module ? I have the one that comes for the SKR board. And I have an MKS one as well. I have 2 raspberry pi's a 3 and a 4. Is there another way to make it work with any of these options ?

Deleted.

Edited 1 time(s). Last edit at 06/03/2020 02:14AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

@mrenz999

It doesn't need a wifi module to function.
You have a few options.
You can use an LCD and control the firmware that way.
You can use a USB connection to control the firmware using something like pronterface.
You could connect a raspberry pi 3 or 4 and use that to host DWC.

If you used anLCD or USB, you won't be able to directly modify the config.g file, so you will have to remove the SD card and edit the file on your PC before loading it back in, which will make calibration take a little longer.

The best way to get the most from the firmware is to use a method that allows printing of the file from the SD card rather than being streamed over USB

---

Based in Darlington, North East

ok I am back with another question to the Z-probe.

I am using Precision Piezo Orion v2.0 connected over the digital output to the zmin on the SKR v1.3

Quote
; Endstops
M574 X2 S1 P"xstopmax" ; configure active-high endstop for high end on X via pin xstopmax
M574 Y2 S1 P"ystopmax" ; configure active-high endstop for high end on Y via pin ystopmax
M574 Z2 S1 P"zstopmax" ; configure active-high endstop for high end on Z via pin zstopmax
;M574 Z1 S2 ; configure z probe for low end on z via pin zstop

; Z-Probe
M558 P5 I1 C"zstop" H10 F400 T2000 R0.20 ; Piezo Precision Orion v2.0 Z probe with 10mm dive height
M557 R115 S20 ; define mesh grid

The thing is that the z probe is triggered instantly after I issue the "G30" command and I believe that I have to just invert the signal but I cannot figure out how. The "I" parameter seems to be not working at all.

Edited 4 time(s). Last edit at 06/03/2020 04:02PM by jafido.

The "I" command is no longer supported in RRF3

This is an extract from the duet wiki for M558 [duet3d.dozuki.com]

Invert the input by prefixing the input pin (C parameter) with ! character, when using an NPN output inductive or capacitive sensor or using an NO switch (not recommended, use a NC switch instead).

---

Based in Darlington, North East

Quote
jay_s
The "I" command is no longer supported in RRF3

This is an extract from the duet wiki for M558 [duet3d.dozuki.com]

Invert the input by prefixing the input pin (C parameter) with ! character, when using an NPN output inductive or capacitive sensor or using an NO switch (not recommended, use a NC switch instead).

@jay_s: You are my hero dude. I was not able to find this info inside the reprap.org/wiki and the other sources. Thanks again. I have to report that the "G32" command works as expected and now is a time to try real printing.

in case somebody needs it here is the final working config

Quote
G31 Z0.2 ; set z probe 0.2mm height offset
M558 P5 C"!zstop" H10 F400 T2000 R0.20 ; Piezo Precision Orion v2.0 Z probe with 10mm dive height

Edited 4 time(s). Last edit at 06/04/2020 01:31AM by jafido.

hi everyone and nice job. I have anet am8 with skr 1.3 and 2208 drivers in uart mod with marlin 2.0. I am interested to install RepRapFirmware on it. I have assembly the wifi adapter with esp8266 on a second board. Now i am trying to convert my marlin settings to reprap but i am over my head. Does anyone have manage to run it on anet a8? Is the transition worth? Any help it will be appreciated. tnx

There seems to be a few forum posts over at the duet forum where people have converted anet am8's to RRF. [forum.duet3d.com]
As the printer is similar to an ender 3 in terms of kinematics, it may be worth reading through the ender 3 guides [duet3d.dozuki.com]
You will need to take into account the differences between RRF2 and RRF3 but it will give you a start.
If you need any further support or guidance, just ask.

---

Based in Darlington, North East

@gloomyandy

Is it possible to download your new test version 3.1.1-8?

Thanks.

Over the last few weeks, I have been looking at improving the core code and speeding things up a bit. See the attached binary firmware.bin (RRFv3.1.1 build with Ethernet support) if anyone is interested in testing out an early build with these new changes (make sure you using the pin naming scheme as mentioned in the first post of this thread). With the extra memory requirement in V3.1, the ST7920 is no longer compiled into the Ethernet firmware build. Due to changes in the heating system, do take extra care to ensure there are no unforeseen issues.


CoreLPC Updates

• New Software PWM implementation:
  
  • This new version creates up to 7 software PWM channels and no longer uses the RI Timer.
  • Each channel has its own interrupt status bit so this makes the handler a lot simpler and faster (i.e. no linked lists etc etc) and typically runs within 1-3us.
• DMA for UART0 (default AUX serial):
  
  • Circular RX Ringbuffer implemented entirely with DMA (zero interrupts).
  • TX data is sent out in a block via DMA rather than using the interrupt driven ringbuffer. Since the data comes from output buffers in RRF, and it attempts to write as much as possible each attempt this method seems to work well (and only 1 interrupt at the end of each block of data sent).
• Updated ADC prefilter:
  
  • Now uses a DMA burst driven circular linked-list triggered by ADC at the end of every ADC burst scan - zero interrupts and frees up Timer1.
  • This is now enabled by default (can be disabled in board.txt).
• Updated DMA interrupt handler.
• Updated Ethernet driver:
  
  • Fixed issue where link was speed being detected as 10Mbit instead of 100Mbit in certain cases (this happened when packets arrived before the auto-negotiation was complete).
  • Fixed issue with RX buffer starvation in certain cases that would result in unnecessary dropped frames.
  • Fixed issue where if network drops out (or unplugged) it would occasionally not detect when it comes back up again.
  • Changed behaviour where if dhcp fails it tries again instead of disabling the network.
• Enabled the Brown-Out Detection (BOD) interrupt
  
  • BOD interrupt is now enabled to count the number times it's called, and also reported in M122 to help those that might have power supply issues. The docs say that the BOD interrupt will trigger when the VDD falls below approx 2.2V down to approx 1.8V.
  • Note: As per the errata, "initial" revision CPUs require Vdd to be above 3.0V. They also mention that initial and revision "A" CPUs also require the Vdd to be above 3.0V when using USB.

@sdavi

Any chance you can commit your changes to github?

---

Based in Darlington, North East

Hi SDavi,
that looks like some interesting improvements. I've also made some updates in similar areas and you may want to take a look at my changes, they are on a separate branch to the main 3.1.1 version of my repo. I'll be pushing some more changes later today (mainly USB updates), so watch this space!
[github.com]

Quote
gloomyandy
Hi SDavi,
that looks like some interesting improvements. I've also made some updates in similar areas and you may want to take a look at my changes, they are on a separate branch to the main 3.1.1 version of my repo. I'll be pushing some more changes later today (mainly USB updates), so watch this space!
[github.com]

I also have been working on some new USB code but it is probably a while before its ready

@SDavi My USB changes are fairly minor, more cleaning things up and a slightly more efficient way of using the buffers. I did consider switching to using DMA, but I wasn't convinced that how I would do it would really save that much time and would need more memory (for DMA buffers) or delay things more. I came to a similar conclusion on the UART side of things, but it seems like you may have found a better way to do that, so I'd love to see what you have come up with.

On the ADC changes one problem I see from time to time with my printer is that after a reboot some of the temperature readings are completely wrong (probably some sort of full scale reading), but it only happens very infrequently and a reboot of the board seems to fix it. I've never been able to pin down what is going on. Have you ever seen this?

Did you see the changes I added to the USB interrupt handling, that allows different interrupt levels for the different devices sharing the DMA controller? It is a bit of a hack but it makes some things so much easier. I really need to be able to run the software UART code at a high priority interrupt but pretty much everything else is happy running as a lower level.

Quote
gloomyandy
@SDavi My USB changes are fairly minor, more cleaning things up and a slightly more efficient way of using the buffers. I did consider switching to using DMA, but I wasn't convinced that how I would do it would really save that much time and would need more memory (for DMA buffers) or delay things more. I came to a similar conclusion on the UART side of things, but it seems like you may have found a better way to do that, so I'd love to see what you have come up with.

On the ADC changes one problem I see from time to time with my printer is that after a reboot some of the temperature readings are completely wrong (probably some sort of full scale reading), but it only happens very infrequently and a reboot of the board seems to fix it. I've never been able to pin down what is going on. Have you ever seen this?

Did you see the changes I added to the USB interrupt handling, that allows different interrupt levels for the different devices sharing the DMA controller? It is a bit of a hack but it makes some things so much easier. I really need to be able to run the software UART code at a high priority interrupt but pretty much everything else is happy running as a lower level.

Yeah the usb changes im looking at (with a different driver that is using DMA) is significantly faster than before. The descriptors, endpoints etc are manually defined up front and stored in flash so it saves a little bit of RAM there but i haven't compared memory usage to the old version yet. I just have a issue that crops up at the moment with the new CDC code that I need to track down.

I have seen that ADC issue, it only seems to appear very rarely (i've only seen it a few times) after the firmware has just been flashed. I've never seen it on a normal (re)boot before, but if it happens after a normal boot then it is something to look into.

Edited 2 time(s). Last edit at 06/18/2020 08:04AM by sdavi.

@SDavi, one problem that I've seen a couple of times with the LPC and USBCDC is that of sending zero length packets. The CDC spec requires that if you send data that ends with a full packet then you must send an additional zero length packet to terminate the transmission. If you don't do that then some systems (Windows for sure) will not pass on the data until either you send another partial packet or you close the connection. It looks like things have hung, but it is just waiting for the extra packet. For some reason a a lot of the LPC CDC implementations do not handle this case. I suspect it is because more often than not they never send full packets and so do not hit the issue. Probably not your problem, but worth mentioning just in case...

It could well be that I only see the ADC issue after flashing the firmware. I tend to update things a lot to test changes etc. and it may easily be only after a flash that I see the problem. I'll keep an eye on things to see if I ever see it after a normal boot.

Quote
gloomyandy
@SDavi, one problem that I've seen a couple of times with the LPC and USBCDC is that of sending zero length packets. The CDC spec requires that if you send data that ends with a full packet then you must send an additional zero length packet to terminate the transmission. If you don't do that then some systems (Windows for sure) will not pass on the data until either you send another partial packet or you close the connection. It looks like things have hung, but it is just waiting for the extra packet. For some reason a a lot of the LPC CDC implementations do not handle this case. I suspect it is because more often than not they never send full packets and so do not hit the issue. Probably not your problem, but worth mentioning just in case...

It could well be that I only see the ADC issue after flashing the firmware. I tend to update things a lot to test changes etc. and it may easily be only after a flash that I see the problem. I'll keep an eye on things to see if I ever see it after a normal boot.

Thanks, i'll look into that tomorrow. As it happens, my issue is with the CDC getting "stuck" ( RRF is still working normally and reconnecting the serial it is ok again). I only noticed it today when i was doing some extra testing with it.

A really easy fix (that I used on the Marlin DMA CDC implementation) is to just make the max packet size 63 bytes rather than 64, that way you never send a full packet and never need a zlp. I think some of the processors used on the Duets may have hardware support to automatically send the zlp when needed.

Sorry if I've missed that, but is there already support for TMC5160? I've ordered the new SKR 1.4 Turbo with TMC5160. Those have SPI or UART interface.

EDIT: Okay seems like it: src/Duet3_V06/Pins_Duet3_V06.h:#define SUPPORT_TMC51xx 1
I'll investigate how to enable those when I have the board

Edited 1 time(s). Last edit at 06/18/2020 01:04PM by avion23.

I doubt if that TMC51xx support will work without a reasonable amount of work. The Duet 51xx support expects to use hardware SPI and it is all for a different set of processors (various SAMExx versions) which have a different hardware SPI unit to the LPC17xx used by this port. It certainly won't be just a case of setting the compiler option. What aspects of the 5160 do you need? Have you considered using 2209s?

@sdavi

Just loaded and tried quickly your 3.1.1

So far looks OK
Unfortunately the DWC is still slow to load via Ethernet cable . No change compared to ver 2 (see related thread).

On the other hand, the T° spikes on the Temp Chart that I and others noticed (and were likely to trigger heater error faults) are gone !

No WiFi on my Sbase board.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
gloomyandy

On the ADC changes one problem I see from time to time with my printer is that after a reboot some of the temperature readings are completely wrong (probably some sort of full scale reading), but it only happens very infrequently and a reboot of the board seems to fix it. I've never been able to pin down what is going on. Have you ever seen this?

I am working two days (in short periods) trying to set it up into a skr 1.3 with 4 tmc2209 and one lv8729 for the extruder, so i am rebooting many times and I have the same problem.
But appart from this bug, everything is working but lv8729 that doesn't anything.
thanks for this port!!! and sorry my english.

Edited 1 time(s). Last edit at 06/19/2020 01:38PM by ESTIMULO.

@Estimulo

Try the LV8729 with timings similar to the A4988 from here [github.com]

---

Based in Darlington, North East

Thanks, i Will try tonight

If you are going to use a mixture of drivers I would recommend that you group the 4 tmc2209 drivers as drivers 0 to 4 and place the other driver in slot 5. You should then modify the board.txt file to set the number of smart drivers to be 4. If you don't do that then RRF will be expecting all of the drivers to be TMC devices and you will be getting timeouts and possibly other problems.

yes!! that is my actual configuration (lv8729 into slot 5) and already done in board.txt
Thanks

Hi all,
I've installed firmware Wi-Fi version 3.1.1 on my Ender 3 Pro with Micro Swiss Direct Drive + Micro Swiss All Metal Hotend and SKR v1.4 Turbo Board with 4 TMC 2208 in UART mode on X, Y, Z and E motors.
Sometimes disconnections happens, especially when I try to make long time print, (eg. an 8 hour print), after about 30 mins printer stopping printing and I see a disconnection error on DWC2.

My Slicer is Cura v4.6.1 and I've set RepRap as G-code flavor.

When problem occurs, on diagnostic M122 log I see:

Last software reset at 2020-06-18 22:10, reason: Watchdog timeout, spinning module GCodes, available RAM 212 bytes (slot 0)
Software reset code 0x08a3 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0442d010 BFAR 0xe000ed38 SP 0x10007fa4 Task MAIN
Stack: 00005ed7 00009dd8 0100502d 2007d9b8 2007c1dc 2007d9af fffffffd 10007fe0 e000e014 e000e010 10000010

Below complete diagnostic log after printer was stopped printing

=== Diagnostics ===
RepRapFirmware for LPC176x based Boards (biquskr_1.4) version 3.1.1 running on LPC176x at 120Mhz
Used output buffers: 1 of 16 (10 max)
=== RTOS ===
Static ram: 3876
Dynamic Memory (RTOS Heap 5): 2824 free, 2800 never used
Exception stack ram used: 304
Never used ram: 380
Tasks: NETWORK(ready,632) HEAT(blocked,1360) MAIN(running,1460) IDLE(ready,80)
Owned mutexes:
=== Platform ===
Last reset 00:00:38 ago, cause: [software]
LPC Flash Slot[76]: 
Last software reset at 2020-06-18 22:10, reason: Watchdog timeout, spinning module GCodes, available RAM 212 bytes (slot 0)
Software reset code 0x08a3 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0442d010 BFAR 0xe000ed38 SP 0x10007fa4 Task MAIN
Stack: 00005ed7 00009dd8 0100502d 2007d9b8 2007c1dc 2007d9af fffffffd 10007fe0 e000e014 e000e010 10000010 
Error status: 0
Driver 0: standstill, read errors 0, write errors 1, ifcount 15, reads 650, timeouts 0
Driver 1: standstill, read errors 0, write errors 1, ifcount 15, reads 649, timeouts 0
Driver 2: standstill, read errors 0, write errors 1, ifcount 15, reads 649, timeouts 0
Driver 3: standstill, read errors 0, write errors 1, ifcount 15, reads 649, timeouts 0
Date/time: 2020-06-18 22:11:18
Slowest loop: 4.45ms; fastest: 0.27ms
=== Storage ===
Free file entries: 3
SD card 0 detected
SD card longest read time 1.6ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0, FreeDm: 100, MinFreeDm: 100, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0, chamberHeaters = -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is ready with "M122" in state(s) 0 0, running macro
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 8.07ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0)
HTTP sessions: 1 of 2
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23-01L-D
WiFi MAC address cc:ce:1e:e7:55:75
WiFi Vcc 64.00, reset reason Unknown
WiFi flash size 4194304, free heap 33912
WiFi IP address 10.0.0.41
WiFi signal strength -36dBm, reconnections 0, sleep mode modem
Socket states: 0 0

Here board.txt configurations

// Board Hardware configuration file for SKR v1.4
// generated by RepRapFirmware Configuration Tool (LPC Version) v2 
// on Mon Jun 15 2020 18:47:53 GMT+0200 (Central European Summer Time)

//Note: Each line should be less than 120 characters.
//    : Unwanted options can be commented out or set to NoPin. Lines commented out will get default values
//    : for pins the default is NoPin.
//    : Values for Arrays need to be contained within { and }
//    : Comments can be defined with // or # (comments are not supported inside arrays)
//    : Each config entry must be all on a single line.

lpc.board = biquskr_1.4; 

//wifi pins
8266wifi.espDataReadyPin = 0.28
8266wifi.lpcTfrReadyPin = 1.30
8266wifi.espResetPin = 1.31
adc.prefilter.enable = true

//TMC 22XX Config
stepper.numSmartDrivers = 4

//LED blinks to indicate Platform is spinning or other diagnostic 
//Comment out or set to NoPin if not wanted.
//leds.diagnostic = 1.18;
leds.diagnostic = NoPin;

//Internal SDCard SPI Frequency.
lpc.internalSDCard.spiFrequencyHz  = 25000000;

//Only supports 1 External SDCard
//externalSDCard.csPin               = 0.16;
//externalSDCard.cardDetectPin       = 1.31;
//lpc.externalSDCard.spiFrequencyHz  = 4000000;
//lpc.externalSDCard.spiChannel  = 0;

//LCD Pins (only ST9720 SPI currently supported)
//setup the Software SPI Pins for LCD
//lpc.softwareSPI.pins = {1.20, NoPin, 1.18}; //Set to GPIO pins to use as SCK, MISO, MOSI
//lcd.spiChannel =     2;
//lcd.lcdCSPin =       1.19;
//lcd.lcdBeepPin =     1.30;
//lcd.encoderPinA =    3.26;
//lcd.encoderPinB =    3.25;
//lcd.encoderPinSw =   0.28; //click
//lcd.lcdDCPin =       NoPin;  //DataControl Pin (A0) if none used set to NoPin
//lcd.panelButtonPin = NoPin; //Extra button on RRD Panel


heat.tempSensePins = {bedtemp, e0temp, e1temp}; //Max of 3 entries
//heat.tempSensePins = {0.25, 0.24, 0.23}; //tb, th0, th1
//heat.spiTempSensorCSPins = { }; //Max of 2 entries

and last config.g file

; Configuration file for SKR v1.4 (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v2.1.4 on Mon Jun 15 2020 18:47:53 GMT+0200 (Central European Summer Time)

; General preferences
G90                                            ; send absolute coordinates...
M83                                            ; ...but relative extruder moves
M550 P"SKR Ender 3 PRO"                        ; set printer name

; Network
;M552 S0                                       ; disable network
M552 S1                                        ; enable network

; Drives
M569 P0 S0 T0.1:0.1:0.02:0.02                  ; physical drive 0 (X) goes backwards using TMC220x driver timings
M569 P1 S0 T0.1:0.1:0.02:0.02                  ; physical drive 1 (Y) goes backwards using TMC220x driver timings
M569 P2 S1 T0.1:0.1:0.02:0.02                  ; physical drive 2 (Z) goes forwards using TMC220x driver timings
M569 P3 S0 T0.1:0.1:0.02:0.02                  ; physical drive 3 (E0) goes backwards using TMC220x driver timings
M584 X0 Y1 Z2 E3                               ; set drive mapping
;M92 X80.00 Y80.00 Z400.00 E93.00              ; set steps per mm default
M92 X80.00 Y80.00 Z400.00 E143.10              ; set steps per mm after E steps tuning
M566 X900.00 Y900.00 Z24.00 E300.00            ; set maximum instantaneous speed changes (mm/min)
M203 X6000.00 Y6000.00 Z180.00 E6000.00        ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z100.00 E5000.00          ; set accelerations (mm/s^2)
M906 X800 Y800 Z800 E1000 I30                  ; set motor currents (mA) and motor idle factor in per cent
M84 S30                                        ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z0 S1                               ; set axis minima
M208 X235 Y235 Z250 S0                         ; set axis maxima

; Endstops
M574 X1 S1 P"xstop"                            ; configure active-high endstop for low end on X via pin xstop
M574 Y1 S1 P"ystop"                            ; configure active-high endstop for low end on Y via pin ystop
M574 Z1 S1 P"zstop"                            ; configure active-high endstop for low end on Z via pin zstop

; Z-Probe
M558 P0 H5 F120 T6000                          ; disable Z probe but set dive height, probe speed and travel speed
M557 X15:215 Y15:195 S20                       ; define mesh grid

; Heaters
M308 S0 P"bedtemp" Y"thermistor" A"Bed" T100000 B4092 ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bed" T0                              ; create bed heater output on bed and map it to sensor 0
M140 H0                                        ; map heated bed to heater 0
M143 H0 S130                                   ; set temperature limit for heater 0 to 130C
M307 H0 B0 S1.00                               ; enable bang-bang mode for the nozzle heater and set PWM limit
M308 S1 P"e0temp" Y"thermistor" A"Hotend" T100000 B4092  ; configure sensor 1 as thermistor on pin e0temp
M950 H1 C"e0heat" T1                           ; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S290                                   ; set temperature limit for heater 1 to 290C
M307 H1 B0 S1.00                               ; disable bang-bang mode for the nozzle heater and set PWM limit

; Fans
M950 F0 C"fan0" Q500                           ; create fan 0 on pin fan0 and set its frequency
M106 P0 S0 H-1 C"Nozzle Side Fan"              ; set fan 0 name and value. Thermostatic control is turned off
;M950 F1 C"e1heat" Q500                        ; create fan 1 on pin fan1 and set its frequency
M950 F1 C"HE1" Q500                            ; create fan 1 on pin fan1 and set its frequency
M106 P1 S1 H1 T50 C"Hotend Fan"                ; set fan 1 name and value. Thermostatic control is turned on

; Tools
M563 P0 S"Hotend" D0 H1 F1                     ; define tool 0
G10 P0 X0 Y0 Z0                                ; set tool 0 axis offsets
G10 P0 R0 S0                                   ; set initial tool 0 active and standby temperatures to 0C

; Custom settings are not defined

; Miscellaneous
M501                                           ; load saved parameters from non-volatile memory

May help me to understand what causes the printer to crash?
Thanks in advance.

Edited 1 time(s). Last edit at 06/19/2020 04:27PM by morganfw.

---

== Customized Ender 3 Pro ==
- SKR v1.4 Turbo + TMC2208 in UART Mode (and parked TMC2209) -
- Micro Swiss Direct Drive + All Metal Hotend -
- Noctua fans everywhere -
- ...and other modifications... -

Can you install the latest test version 3.1.1-8 from gloomyandys post a few posts back?
There's been a number of fixes since that release

---

Based in Darlington, North East