Marlin 2.0 RC1 - TODO

Created on 21 Jun 2019  Β·  105Comments  Β·  Source: MarlinFirmware/Marlin

Let's coordinate the Marlin 2.0 RC1 release and track remaining work for this first release candidate.

AVR

Board|MCU|SD Card|LCD|TMC SPI|TMC UART|EEPROM|WiFi|Max6675|Neopixel
-|-|-|-|-|-|-|-|-|-
RAMPS, RAMBo etc.|AVR|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š

SAM

Board|MCU|SD Card|LCD|TMC SPI|TMC UART|EEPROM|WiFi|Max6675|Neopixel
-|-|-|-|-|-|-|-|-|-
Due,Β RAMPSΒ FD,Β etc.|SAM3X8E|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š
Duet 2 Wifi + X5|SAM4E8E|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘
Duet 2 Maestro|SAM4S8C|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️
Archim 1.0|SAM3X8E|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š
Archim 2.0|SAM3X8E|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š
Grand Central|ATSAMD51|πŸ’š|πŸ’š|⚠️|⚠️|πŸ’š|πŸ›‘|πŸ›‘|πŸ’š

LPC

Board|MCU|SD Card|LCD|TMC SPI|TMC UART|EEPROM|WiFi|Max6675|Neopixel
-|-|-|-|-|-|-|-|-|-
Re-ARM|LPC1768|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š
MKS-SBASE|LPC1768|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š
SKRΒ v1.3|LPC1768|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|⚠️|⚠️|⚠️
Smoothieboard|LPC1769|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š
AzteegΒ X5Β GT|LPC1769|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š
Cohesion3DΒ Remix|LPC1769|πŸ’š|πŸ’š|πŸ’š|πŸ’š|πŸ’š|⚠️|⚠️|⚠️
Selena Compact|LPC1768|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️

STM32F1

Board|MCU|SD Card|LCD|TMC SPI|TMC UART|EEPROM|WiFi|Max6675|Neopixel
-|-|-|-|-|-|-|-|-|-
Malyan M200|STM32F103C8|⚠️|⚠️|n/a|n/a|⚠️|⚠️|⚠️|⚠️
MKS Robin 2.4|STM32F103ZET6|πŸ’š|πŸ’š|πŸ›‘|?|πŸ’š|πŸ›‘|πŸ›‘|πŸ›‘
Chitu3D V3.9|STM32F103ZET6|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘
Longer3D LK1|STM32F103VE|πŸ’š|πŸ’š|n/a|n/a|πŸ’š|n/a|n/a|n/a
SKR Mini v1.1|STM32F103RC|πŸ’š|⚠️|⚠️|⚠️|πŸ’š|n/a|n/a|πŸ›‘

STM32F4

Board|MCU|SD Card|LCD|TMC SPI|TMC UART|EEPROM|WiFi|Max6675|Neopixel
-|-|-|-|-|-|-|-|-|-
STEVAL-3DP001V1|STM32F401VE|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘
[ARMed]|STM32F401VE|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘

STM32F7

Board|MCU|SD Card|LCD|TMC SPI|TMC UART|EEPROM|WiFi|Max6675|Neopixel
-|-|-|-|-|-|-|-|-|-
The Borg 3D|STM32F765ZGT6|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️

ESP32

Board|MCU|SD Card|LCD|TMC SPI|TMC UART|EEPROM|WiFi|Max6675|Neopixel
-|-|-|-|-|-|-|-|-|-
Espressif 32 Wifi|ESP32|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️|⚠️

Teensy

Board|MCU|SD Card|LCD|TMC SPI|TMC UART|EEPROM|WiFi|Max6675|Neopixel
-|-|-|-|-|-|-|-|-|-
TeensyΒ 3.5|MK64FX|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘
TeensyΒ 3.6|MK66FX|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘|πŸ›‘

Legend

  • πŸ’š (good) Working, no major issues.
  • ⚠️ (beta) Working, but not completely.
  • πŸ›‘ (alpha) Not yet working.
  • ❓ (unknown) You tell me!

Checklist for RC1:

  • Compiles and runs on…

    • [x] AVR: many boards
    • [x] DUE: many boards
    • [x] LPC176x: many boards
    • [ ] ESP32: one or two boards
    • [ ] STM32: Needs software serial
    • [x] STM32F1 - a few boards
    • [x] STM32F4 - a few boards
    • [ ] STM32F7 - one or two boards
    • [x] Teensy 3.1/3.2 - Printrbot, et. al.
    • [ ] Teensy 3.5/3.6 - alpha
  • FAST_PWM_FAN (e.g., Native PWM, also good for spindle/laser):

    • [x] AVR
    • [x] DUE
    • [ ] LPC176x
    • [ ] ESP32
    • [ ] STM32
    • [ ] STM32F1
    • [ ] STM32F4
    • [ ] STM32F7 - one or two boards
    • [ ] Teensy 3.1/3.2
    • [ ] Teensy 3.5/3.6
Development

Most helpful comment

I'm not sure what the definition is of a "Supported platform", but we may want to add the Bigtreetech SKR V1.3 board (possibly the most popular 32bit board at the moment) and probably some of the other SKR boards (which use various STM processors and are popular, but possibly not as well supported at present). How well these popular 32bit boards work is probably a good indication of the current state of "real world" 32bit support and should be tracked as best we can. Perhaps those boards should also be a major focus for RC1?

All 105 comments

I'm not sure what the definition is of a "Supported platform", but we may want to add the Bigtreetech SKR V1.3 board (possibly the most popular 32bit board at the moment) and probably some of the other SKR boards (which use various STM processors and are popular, but possibly not as well supported at present). How well these popular 32bit boards work is probably a good indication of the current state of "real world" 32bit support and should be tracked as best we can. Perhaps those boards should also be a major focus for RC1?

The MKS Robin 2.4 (STMF103ZET6) may be a candidate for the list. It compiles via PlatformIO and runs Marlin. I don't know how functional it is.

Alfawise u20/20+/u30 is a perfect candidate! Stm32f1vet6.
Runs perfectly , BL touch and touchmi enabled and tested
Compiles on platformio.
Qvga tft direct 16 bit parallel interface using dogm β€œzoom”
Resistive touch screen based on standard ads7843. ( driver can be improved but it works with 3 buttons Γ©mulation and is software spi controled).
And Hal debugged!!!
Sd card support ok
Fan soft pwm
Flexible BL touch configuration for cpu pins allowing multiple board revisions to be compatible
Serial port 250k through usb. Octoprint ok
Eeprom in the works

In a nutshell : status = excellent!

GTM32 variants are getting close. Just got my hands on a Geeetech A30 (GTM32 mini) today. Geeetech Rostock 301 (GTM32_PRO_VB) is really close (I think it's down to one or two issues - eeprom and temps). I'll do some more testing this weekend.

Does the coming soon BigtreeTech SKR Pro is so much too far from the current Marlin status ?
I still don't have the "big picture" of Marlin V2, so sorry in advance if it's a silly question. In fact, I even don't know if STM32F407ZGT6 already exists in Marlin ecosystem.

Please add your suggestions for the things we should require before committing to a first release candidate.

If we think back to when the v2.0.0 branch was created, its purpose was to provide a place to do the work to get Marlin migrated to 32-bit platforms. And at that time, the original thinking was we needed it solid and working on a '32-bit Reference Platform'. We were thinking that if we could get it moved successfully to one 32-bit board, others would follow.

Then... the hierarchical organization work started. And it just made sense to do that in the v2.0.0 branch because that work needed to be separated out of the normal work flow and usage. That made sense, but it made the v2.0.0 branch dual purpose.

I'm of the opinion the v2.0.0 is ready to release and is suitable to be used to start the next branch of Marlin's evolution. I don't have strong feelings on it, but we have multiple 32-bit processors supported and the hierarchical file organization is pretty well proven at this point.

To my way of thinking, all of the "My favorite 32-bit processor is almost ready, lets add it to the list." comments don't have much merit. We are going to keep a check off list detailing the status of all the various processors anyways. As a particular processor family's status changes... we can update the list.

My personal opinion is: WE ARE GOOD TO GO.

Hmm perhaps to try and get some sort of focus it would be useful to have a feature list that can be used to rate how complete support on a particular board/processor is. So for me some key features are...

  • SD card support
  • TMC SPI and UART driver support
  • LCD support - Graphical and character, plus perhaps some of the new ones like FYSETC_MINI_12864
  • BLTOUCH support
  • EEPROM support
  • USB serial support
  • Support for UART based touch displays (basically a working UART).

I'm assuming that all boards will support things like heaters and basic stepper operation. But I think these days most folks will probably expect to be able to use some/all of the above (assuming the board is capable). I've almost certainly missed some items that should be on the list but I've tried to capture the ones that I know can be tricky to get working.

I have no real idea how well the various HALs stack up against the above list. From my own experience I'd say that the LPC176x based boards support pretty much everything above, but I've no idea about the STM based boards. Such a list might also be of interest to potential contributors giving them some idea of what areas need work. Though I guess most features tend to get added by someone that feels a need for it and that has the hardware.

I think I agree this would be a very good chart to have on the README.md for Marlin v2.0.0. For each processor, detail the status of:

  • SD card support
  • TMC SPI and UART driver support
  • LCD support - Graphical and character, plus perhaps some of the new ones like FYSETC_MINI_12864
  • BLTOUCH support
  • EEPROM support
  • USB serial support

It might also make sense to add information about the point release where that support became solid and trustworthy (on a per line item basis).

Does the coming soon BigtreeTech SKR Pro is so much too far from the current Marlin status ?
I still don't have the "big picture" of Marlin V2, so sorry in advance if it's a silly question. In fact, I even don't know if STM32F407ZGT6 already exists in Marlin ecosystem.

It exists. I have a board on the way. If its just a matter of a pin file, config samples ect and the HAL is good, it just might make it in. Time will tell.

My personal opinion is: WE ARE GOOD TO GO.

The only blocker I see is still getting layer shifts on machines with 2.0 that reverting to 1.1.9 with a matching as possible config resolves. If this got sorted out id say just pick at a bunch of small things for a clean snapshot then go. Ill browse the issue queue for anything else that jumps out this weekend as a potential blocker and post the number here if I come across any.

My personal opinion is: WE ARE GOOD TO GO.

The only blocker I see is still getting layer shifts on machines with 2.0 that reverting to 1.1.9 with a matching as possible config resolves. If this got sorted out id say just pick at a bunch of small things for a clean snapshot then go.

Actually... I agree with this thinking. But my perspective is a little bit different. At a higher level, if we are going to be adding things to a list of things that need to be resolved prior to releasing v2.0.0....

Resolving the Layer Shift issue is at the top of the list.

This is probably off topic, but I'm totally confused about the layer shift issue. Do we actually have any hard examples now (I know we had some that seemed to be down to an STM timer issue - hopefully resolved, when that PR is merged)? So many of them seemed to turn out to be down to users switching to different stepper drivers or making other changes, or just mechanical issues. I notice that the thread has been closed.

I agree with the general consensus, list the boards/machines that work 100% and maybe list what needs work on what boards/machines still. But I think you should make a 2.0 release.

This is probably off topic, but I'm totally confused about the layer shift issue. Do we actually have any hard examples now (I know we had some that seemed to be down to an STM timer issue - hopefully resolved, when that PR is merged)?

Nope! Definitely not off topic. If we are talking about action items that need to be completed prior to doing the v2.0.0 release, this is 'On Topic'.

I think the layer shifts are real. Most of them are caused by various mechanical issues with the printer. Some are caused because people are pushing their feed, acceleration and jerk numbers too high. (And just because it 'seems to work', that doesn't mean with a worst case GCode file the printer can actually handle it.)

But here is the thing... The amount of layer shift issues we are aware of on the vetted 32-bit platforms is almost zero. The bulk of the layer shift problems we are seeing are on AVR processors. And I know I can avoid layer shifts if I scale my F/R settings on the LCD Panel down to 50%. Above 50%, I will some times see a layer shift on a long print.

That sort of points to the AVR processors not having enough muscle to get everything done (at interrupt time) and some how we are losing steps. Right now, the people focused on the problem are not making good headway in resolving the root cause.

Well
Layer shift is solved on stm32f1...

please add support for Bigtreetech SKR v1.3 & Pro v1.1 boards.

well "fixed" with the unmerged PR #14030 but our touchscreen is not in Marlin neither

I'm still having trouble with Max31855 support, on both ReArm and SKR 1.3.

However, since getting the SKR 1.3 I'll be using this as my reference now

This is probably off topic, but I'm totally confused about the layer shift issue. Do we actually have any hard examples now (I know we had some that seemed to be down to an STM timer issue - hopefully resolved, when that PR is merged)? So many of them seemed to turn out to be down to users switching to different stepper drivers or making other changes, or just mechanical issues. I notice that the thread has been closed.

One big indicator is on IDEX machines when we see both X axis heads shift together. Non-firmware issues cant do that. Most likely thats a planner or ISR output issue. These are the scenarios we can be absolutely certain are software and is a solid indicator. We have several examples of prints with a large number of short jerky moves that shift every time. To date every user who has reverted to 1.1.9 has seen these shifts cease immediately. The sheer number of reports from dealing with a particular manufacturer who is shipping machines with 2.0 preinstalled and the distributor for them in my region has been fairly staggering.

please add support for Bigtreetech SKR v1.3 & Pro v1.1 boards.

1.3 is already pretty well supported. See my statement above on the 1.1 boards. Can get an answer sooner if you can get btt hope to ship mine faster!

Could we reserve some "ID" for the longer3D/alfawise STM32F1 board ? to avoid to change it each month ? :p

One big indicator is on IDEX machines when we see both X axis heads shift together. Non-firmware issues cant do that. Most likely thats a planner or ISR output issue. These are the scenarios we can be absolutely certain are software and is a solid indicator.

Agreed! Marlin v2.0.0 has a layer shift bug that is not that hard to duplicate on 8-bit AVR processors.

Should we add its resolution to the check off list for releasing v2.0.0 ?

One big indicator is on IDEX machines when we see both X axis heads shift together. Non-firmware issues cant do that. Most likely thats a planner or ISR output issue. These are the scenarios we can be absolutely certain are software and is a solid indicator.

Agreed! Marlin v2.0.0 has a layer shift bug that is not that hard to duplicate on 8-bit AVR processors.

Should we add its resolution to the check off list for releasing v2.0.0 ?

seems wise to do, you get my vote

and maybe go through the issue list and pick confirmed issues that are serious enough and add them to the list also

i think this one is a good one to look at https://github.com/MarlinFirmware/Marlin/issues/4931

check config at boot and either warn or limit speed so it matches with what the cpu is able to

and this one since it's on the 2.0.0 milestone https://github.com/MarlinFirmware/Marlin/issues/5079.

Even thou this is a feature request https://github.com/MarlinFirmware/Marlin/issues/6199 i think it should be looked at anyway since its so a common bed these days (prusa is not the only one anymore)

and this one has the deisgn concept label and is still open even thou its hinted that its not likely to get implemented, maybe do a quick look at it? https://github.com/MarlinFirmware/Marlin/issues/6295

also with design concept https://github.com/MarlinFirmware/Marlin/issues/8195

@Roxy-3D came with a good suggestion here https://github.com/MarlinFirmware/Marlin/issues/7274 but it has not been confirmed yet

these might also be relavant: https://github.com/MarlinFirmware/Marlin/issues/8497
https://github.com/MarlinFirmware/Marlin/issues/9048
https://github.com/MarlinFirmware/Marlin/issues/9205
https://github.com/MarlinFirmware/Marlin/issues/9403
https://github.com/MarlinFirmware/Marlin/issues/9742
https://github.com/MarlinFirmware/Marlin/issues/9917
https://github.com/MarlinFirmware/Marlin/issues/9931
https://github.com/MarlinFirmware/Marlin/issues/10010
https://github.com/MarlinFirmware/Marlin/issues/10455
https://github.com/MarlinFirmware/Marlin/issues/10459
https://github.com/MarlinFirmware/Marlin/issues/10549
https://github.com/MarlinFirmware/Marlin/issues/10707
https://github.com/MarlinFirmware/Marlin/issues/11262
https://github.com/MarlinFirmware/Marlin/issues/11263
https://github.com/MarlinFirmware/Marlin/issues/13130
https://github.com/MarlinFirmware/Marlin/issues/13201

And we have still the linear advance issue (at least for non TMC drivers) #11205

~Hopefully we can add the MKS Robin Nano & MKS Robin Mini (both STM32F103VET6) to the supported boards list.~

Boards are now supported! :smiley:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Glod76 picture Glod76  Β·  3Comments

Anion-anion picture Anion-anion  Β·  3Comments

Ciev picture Ciev  Β·  3Comments

heming3501 picture heming3501  Β·  4Comments

ceturan picture ceturan  Β·  4Comments