Marlin 2.0 RC1 - TODO #14345
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. 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 ? |
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...
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:
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). |
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. |
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. |
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. |
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 |
|
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 |
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. |
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 |
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 #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 #5079. Even thou this is a feature request #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? #6295 also with design concept #8195 @Roxy-3D came with a good suggestion here #7274 but it has not been confirmed yet these might also be relavant: #8497 |
|
And we have still the linear advance issue (at least for non TMC drivers) #11205 |
|
Boards are now supported! 😃 |
|
What do you guys means with:
I'm working in a Software UART to a side project, for Chibios OS on a STM32F1(Probably works on all STM32), and it may fit, depending on your needs. It uses a Timer that works 3 times the baud frequency, all interrupt code, plain simple but highly effective. Probably will finish until end of month. I'm not familiar with Marlin, so if my question is dumb, just let me know. |
|
Serial (and multiple serials) seems to works properly on the F1. What "could" be missing is the direct USB pins, printers seems to generally use a dedicated usb/serial chip via a serial channel. But i say could because pins are not linked/used on my boards. |
|
Well, if that's the case, it is not a "Software serial" that is needed... odd. |
|
Software serial is useful for talking to devices like the TMC2208 etc drivers (less so with the TMC2209 which allows multiple drivers to share a UART), when you may need five or more serial interfaces (to talk to the drivers) plus perhaps one or more to talk to say a TFT screen and perhaps another to talk to Octoprint or whatever. So you may need 7 UART devices. I'm not sure how many UARTS the STM devices support, or how easy it is to arrange for the pins to be available (they may be shared with other devices that are also needed like spi/i2c/adc etc.). On the LPC176x chips there simply are not enough hardware UARTS available and so we use software serial (@0x3333 you may want to take a look at how it is implemented for the LPC176x, sounds similar to how you are doing things). |
|
@gloomyandy yeah, I thought that was the reason. The LPC176X is using arduino software serial, and it is blocking, isn't it? |
|
@0x3333 No it is written for the LPC176x It uses the same API as the Arduino (so that it can be used with things like the TMC library). Everything is driven from a timer interrupt. It is sort of blocking on output, but only because the output buffer is only a single byte (like the Arduino version), but it only blocks if the previous character is still being sent. The source is here: https://github.com/p3p/pio-framework-arduino-lpc176x/blob/master/cores/arduino/SoftwareSerial.cpp Ignore the header comment, that is from the original Arduino software serial code and I didn't get around to updating it before the code was merged. |
|
Please, to whomever can change this post, grandcentral M4 should have |
I have a printer running on a BIGTREETECH SKR PRO with TMC5160's (X,Y) and TMC2130's (Z1,Z2,E) , everything seems ok except for linear advance, it doesn't extrude properly with LA enabled. Still trying to work that out. |
Be sure to disable spreadCycle on E as this seems to play havoc with LA. |
|
@thinkyhead are you sure you mean disable spreadcycle? From what I've seen it is stealthchop that causes problems and spreadcyle usually works. |
|
@thinkyhead - core function things (LCD, USB serial, SD, Touch, SD-on-eeprom) have been working great now on JGAurora A5S/A1 for a while. Can we add them to the supported list to RC1? Different board, but same chip and status as Robin 2.4. |
|
Are there any plans to include support for the 12bit ADCs on these boards? I've tried to switch from Smoothieware to Marlin on my MKS SBASE but the temps are nowhere near as smooth and none of the settings in Marlin seem to make it as stable as SW. |
|
With respect to the FAST_PWM_FAN; the HAL doesn't support the DUE yet; but does support the LPC176x; as the DUE HAL lacks the |
|
Just thought I'd chip in an say that I've been running 2.0 on an SKR V1.3 for about 2 months now. Configured with linear advance and TMC5160s in SPI mode. No issues at all. It's solid and believe me, I hammer it daily. |
Just an overview of the Status: So things are moving forward :-) |
|
I2C GPIO expanders for Teensy 3.5 would be great. The chip is pretty powerful and could enable shields with more features. |
|
I guess this issue can be closed due to https://github.com/MarlinFirmware/Marlin/releases/tag/2.0.0 |
|
@thinkyhead do you agree with @extesy ^^^ |
|
will close this one as 2.0 is out |
|
I see Duet 2 Wifi + X5 (SAM4E8E) marked as in alpha, is there a HAL for it? Anyone working on it ? |
|
@thinkyhead can you copy and send me your original message (I want it with the Markdonw style), for documentation purposes |
FYI, you can click the three dots (...) in the top-right of a message and choose "quote reply" to copy it. |
I had the same thought but I only get the source Markdown of the list, not tables:
|
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
and others
Let's coordinate the Marlin 2.0 RC1 release and track remaining work for this first release candidate.
AVR
SAM
LPC
STM32F1
STM32F4
STM32F7
ESP32
Teensy
Legend
Checklist for RC1:
Compiles and runs on…
FAST_PWM_FAN(e.g., Native PWM, also good for spindle/laser):The text was updated successfully, but these errors were encountered: