search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.03k stars 19.13k forks source link

Marlin 2.0 RC1 - TODO #14345

Closed thinkyhead closed 4 years ago

thinkyhead commented 5 years ago

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

Checklist for RC1:

gloomyandy commented 5 years ago

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?

Bob-the-Kuhn commented 5 years ago

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.

hobiseven commented 5 years ago

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!

Phr3d13 commented 5 years ago

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.

Patag commented 5 years ago

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.

Roxy-3D commented 5 years ago

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.

gloomyandy commented 5 years ago

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...

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.

Roxy-3D commented 5 years ago

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:

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).

InsanityAutomation commented 5 years ago

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.

InsanityAutomation commented 5 years ago

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.

Roxy-3D commented 5 years ago

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.

gloomyandy commented 5 years ago

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.

Phr3d13 commented 5 years ago

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.

Roxy-3D commented 5 years ago

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.

hobiseven commented 5 years ago

Well Layer shift is solved on stm32f1...

Ghenghis commented 5 years ago

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

tpruvot commented 5 years ago

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

Grogyan commented 5 years ago

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

InsanityAutomation commented 5 years ago

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.

InsanityAutomation commented 5 years ago

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!

tpruvot commented 5 years ago

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

Roxy-3D commented 5 years ago

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 ?

boelle commented 5 years ago

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

boelle commented 5 years ago

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

Bergerac56 commented 5 years ago

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

thisiskeithb commented 5 years ago

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

Boards are now supported! :smiley:

AnHardt commented 5 years ago

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

Is looking very implementation/feature centric to me. I'd prefer a more functionality centric view.

To make work a FDM 3D printer (I hope thast's still Marlins main target.) the software (Marlin) and the board (HAL), together, have to reliably support at least.

and eiter

and or

The minimum required security functionalitys are:

and less important if the motors are not powerful enough to destroy the machine

With this functionality, a hobbyist (and off cause a professional system integrator) can build a limited but functional printer. So this could be the minimum required functionality to call a board/system/... supported by Marlin 2.

Everything additional is a comfort feature and is not strictly required. It may be helpful for the users to keep a list of additionally working features per platform (or whatever makes sense).

xC0000005 commented 5 years ago

Do we require a board to build in PlatformIO to be functional? The M200 V1 and V2 are basically fully functioning - these boards will never support Neopixel & other fun hardware addons - they're extremely limited, with fixed drivers, etc. All that's really missing is a few minor LCD fixes to deal with a new timeout feature in the delta and V3. Also, the V1 and V2/V3 run on different processors - V1 is an STM32F103, V2/Pro (and the delta) run on STM32F070.

Hedda commented 5 years ago

BIQU BIGTREETECH SKR MINI-E3 board uses STM32F103RCT6 with TMC2209 stepper drivers:

https://www.reddit.com/r/BIGTREETECH/comments/c0hdht/bigtreetech_skr_mini_e3_done/

FYSETC Cheetah board uses STM32F103 (of an unknown model) with TMC2209 stepper drivers:

https://www.reddit.com/r/3Dprinting/comments/c1lttc/fysetc_cheetah_board_chinaclone_of_th3d_ezboard/

Does anyone know what 32-bit MCU that TH3D Studio's EZBoard Lite use? Said to run at 120Mhz:

https://www.reddit.com/r/3Dprinting/comments/bvsd1q/ezboard_lite_formerly_tough_controller_for/

InsanityAutomation commented 5 years ago

@Hedda Its an LPC1768 on the TH3D board.

Hedda commented 5 years ago

Does not the Duet 2 Maestro use the Atmel SAM4S8C (ATSAM4S8C) MCU and not the SAM3X8E? Typo?

https://duet3d.dozuki.com/Wiki/Duet_2_Maestro_Hardware_Overview

And the Duet 2 WiFi and Duet 2 Ethernet should be using similar use the Atmel SAM4E8E (ATSAM4E8E)?

https://duet3d.dozuki.com/Wiki/Hardware_Overview

trouch commented 5 years ago

Can't wait for RC, keep up with your great work everyone ! I have a Fysetc Cheetah on its way, will keep posted.

Hedda commented 5 years ago

@InsanityAutomation if it runs at 120 MHz then more likely an LPC1769 model then an LPC1768 model

https://www.nxp.com/docs/en/data-sheet/LPC1769_68_67_66_65_64_63.pdf

LPC1769 are the only models in that series of NXP MCU to officially run up to 120 MHz.

Hedda commented 5 years ago

Support for FYSETC CHEETAH board committed FYSETC's own Marlin 2.0 fork on GitHub 4 days ago:

https://github.com/FYSETC/Marlin-2.0.x-FYSETC/commit/4fa345a762717daf81e794f2594978cf052248c1

simon-jouet commented 5 years ago

For the ESP32 there is no commercial board as of now (at least none that i'm aware of). The board that is currently the most "common" is the R1 and the R2 is being worked on:

felixstorm commented 5 years ago

From my personal experience, current Marlin ESP32 / I2S code seems to be working well (with my ESP32 board based on @simon-jouet's R2 and my stock Ender 3), but since I currently do not have much spare time, I only made a few prints yet.

Personal experience so far:

Feature Status
SD card working fine
TMC SPI and UART driver not in use or tested
LCD working fine (Ender 3 stock display)
BLTOUCH working fine
EEPROM working fine
USB serial working fine
Fans working fine (hotend, part cooling and controller controlled separately)
Heater working fine (1 in use)
Heated Bed working fine
WiFi not really used yet

Issues I've had so far:

So my personal opinion: "beta" sounds fine to me for ESP32 support.
Maybe someone else (e.g. @grownseed, @Idorobots) can shed some light on WiFi status?

trouch commented 5 years ago

Support for FYSETC CHEETAH board committed FYSETC's own Marlin 2.0 fork on GitHub 4 days ago:

FYSETC/Marlin-2.0.x-FYSETC@4fa345a

I'm looking to merge that into a bugfix-2.0.x branch before submitting a PR. Lot of changes and several ones conflicting with recent support of TMC2209 here. They also added SD support and other tweaks. GIT diff returns 12 conflicting files, but I can see runtime conflicts as well by digging into changes.

InsanityAutomation commented 5 years ago

@Hedda yup, typo sorry it is a 1769

Idorobots commented 5 years ago

WiFi is usable as an additional serial right now (err, more like two months back, as I haven't had much time to invest into ESP32 port since about then). The UI allows you to run G-code commands, but there's the usual multiple-serial shenanigans going on - some commands print to one of them, some others to both, etc. It's entirely usable without the WiFi.

vivian-ng commented 5 years ago

Regarding WiFi for ESP32, I have been using @luc-github Marlin fork (which is basically Marlin with his ESP3D webUI) in the testing of my board. It works fine for the few test prints I have done, but I have yet to do any intensive testing (in terms of long-hour prints) yet. I think @luc-github has recently filed a FR here about how to merge his work back into Marlin. Coupled with the great work @simon-jouet has done in implementing I2S, and @felixstorm for fixing issues with the HAL, my prototype board can now both use an LCD controller and also a webUI.

ktand commented 5 years ago

The STM32F407 based board ARMED is fully working using the HAL_STM32:

SD card support TMC SPI driver support LCD support - Graphical and character, (FYSETC_MINI_12864 not yet working) EEPROM support USB serial support

OneOfEleven commented 5 years ago

The STM32F407 based board ARMED is fully working using the HAL_STM32:

SD card support TMC SPI driver support LCD support - Graphical and character, (FYSETC_MINI_12864 not yet working) EEPROM support USB serial support

Is there no TMC serial driver (for all the uart TMC'ers out there) ?

Msq001 commented 5 years ago

The STM32F407 based board ARMED is fully working using the HAL_STM32: SD card support TMC SPI driver support LCD support - Graphical and character, (FYSETC_MINI_12864 not yet working) EEPROM support USB serial support

Is there no TMC serial driver (for all the uart TMC'ers out there) ?

yeah, no software serial in stm32 now, but it will be added later

thinkyhead commented 5 years ago

the usual multiple-serial shenanigans going on - some commands print to one of them, some others to both

It would be good to find a savvy developer who has a setup with wifi (or other multiple serial port hosts) and get down to debugging the serial redirection. Command responses are supposed to be directed out to the serial port that sent the command. General machine state output, not connected to a particular command, should go to both serial ports. Serial port redirecting is meant to always be temporary and automatically restored when a block that changed it goes out of scope.

A thorough day or three of attentive testing and debugging of serial port redirection is needed to get that output into shape.

luc-github commented 5 years ago

the usual multiple-serial shenanigans going on - some commands print to one of them, some others to both

Is that specific to ESP32 ? If yes it may linked to Websocket instead. And likely due to usage of AsyncWebSocket which reject message if it cannot proceed it (https://github.com/me-no-dev/ESPAsyncWebServer/pull/411) I do not have such issue on my side since I use another websocket library

thinkyhead commented 5 years ago

We have several examples of prints with a large number of short jerky moves that shift every time.

This is excellent! If there's a G-code file that reproduces the issue at the same point every time, then we can just add a bit of debugging to see exactly what's going on. The race condition from <=1.1.8 was too random to debug this way. @InsanityAutomation — Can you send me the G-code to test?

xC0000005 commented 5 years ago

the usual multiple-serial shenanigans going on - some commands print to one of them, some others to both

Is that specific to ESP32 ?

I have a fork which enables the Malyan M200 WIFI printing (no surprise, it's the ESP8266's Telnet/Serial bridge, configured as a second serial port), and I see the behavior there. Since that doesn't use the websockets code, I suspect it's more likely to do with the redirection code, though the Rememberer template sure looks like it ought to work.

thinkyhead commented 5 years ago

I've updated the OP with some more tables. I could go down to the every-board level, but I'm lazy!

weed2all commented 5 years ago

Screenshot_20190709-082020_Samsung Internet So I get back to this as is unclear for me...marlin 2.0 rc1 states that have fully work tmc uart on due board!so I still have my radds and due board!can I use 4 tmc2208 drivers in uart with it?

jmz52 commented 5 years ago

ARMed Stick is 'powered by the popular STM32F103C8T6 micro controller', so it is not STM32F4 but an STM32F1