Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Marlin 2.0 RC1 - TODO #14345

Open
thinkyhead opened this issue Jun 21, 2019 · 88 comments

Comments

@thinkyhead
Copy link
Member

commented Jun 21, 2019

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鈥

    • AVR: many boards
    • DUE: many boards
    • LPC176x: many boards
    • ESP32: one or two boards
    • STM32: Needs software serial
    • STM32F1 - a few boards
    • STM32F4 - a few boards
    • STM32F7 - one or two boards
    • 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):

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

@thinkyhead thinkyhead added this to the 2.0.0 milestone Jun 21, 2019

@thinkyhead thinkyhead pinned this issue Jun 21, 2019

@gloomyandy

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

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

This comment has been minimized.

Copy link

commented Jun 21, 2019

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 鈥渮oom鈥
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

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

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

This comment has been minimized.

Copy link

commented Jun 21, 2019

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

This comment has been minimized.

Copy link
Member

commented Jun 21, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

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.

@Roxy-3D

This comment has been minimized.

Copy link
Member

commented Jun 21, 2019

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

@InsanityAutomation

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

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

This comment has been minimized.

Copy link
Member

commented Jun 21, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

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

This comment has been minimized.

Copy link
Member

commented Jun 21, 2019

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

This comment has been minimized.

Copy link

commented Jun 21, 2019

Well
Layer shift is solved on stm32f1...

@Ghenghis

This comment has been minimized.

Copy link

commented Jun 22, 2019

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

@tpruvot

This comment has been minimized.

Copy link

commented Jun 22, 2019

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

@Grogyan

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2019

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

This comment has been minimized.

Copy link

commented Jun 22, 2019

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

@Roxy-3D

This comment has been minimized.

Copy link
Member

commented Jun 22, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2019

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
#9048
#9205
#9403
#9742
#9917
#9931
#10010
#10455
#10459
#10549
#10707
#11262
#11263
#13130
#13201

@Bergerac56

This comment has been minimized.

Copy link

commented Jun 22, 2019

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

@thisiskeithb

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2019

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

Boards are now supported! 馃槂

@xC0000005

This comment has been minimized.

Copy link
Contributor

commented Jul 18, 2019

We need an icon for "not applicable."
On the Malyan M200 V1/V2/V3/Pro and M300 printers, there will never be TMC in either flavor (these are fixed driver boards). There's no free SPI output, so no Max support. on V1s there's not even a free GPIO to hook a Neopixel to once the Arduino Core and library support it.

Summary of different Malyan M200/M300 printers:
Malyan M200 V1 - SMT32F103
LCD has minor bugs.
EEPROM, SD, work.
Max, TMC, Wifi, Neopixel aren't possible.

Malyan M200 V2 - SMT32F070
LCD has minor bugs.
EEPROM, SD, work.
Max, TMC, Wifi aren't possible.
Neopixel needs work (lots and lots of work).

The V3 is essentialy the V2 + an auto-level sensor, in the same state (same MCU). I'd list it as V2/V3.

@MS1987

This comment has been minimized.

Copy link

commented Jul 19, 2019

Description
Initial MKS Robin Lite and MKS Robin Lite2 (STM32F103RCT6) support brought over from Makerbase's Robin Lite repo and Robin Lite2 repo

Benefits
Brings MKS Robin Lite/Lite2 board support into Marlin.

Related Issues
None.

@berezovskyi-oleksandr

This comment has been minimized.

Copy link

commented Jul 21, 2019

@thinkyhead first message mentions that FAST_PWM_FAN works on Due.

At Marlin/src/HAL/HAL_DUE/SanityCheck.h there is condition preventing build:

#if ENABLED(FAST_PWM_FAN)
  #error "FAST_PWM_FAN is not yet implemented for this platform."
#endif

Error in message or in code?

@thisiskeithb

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2019

How much proof of life do you need for the SKR 1.3? I can confirm that SD Card (onboard & on LCD), LCD (2004 & 12864), TMC SPI (2130 & 5160), TMC UART (2208/2209), and EEPROM work well on the two SKR 1.3 boards that I have.

@rusnob

This comment has been minimized.

Copy link

commented Jul 21, 2019

add kinematics delta robot on marlin 2.0 RC1
http://www.cim.mcgill.ca/~paul/clavdelt.pdf

https://www.youtube.com/watch?v=v46Gh64aN_o
https://www.youtube.com/watch?v=1aBubz6Mk2M

smoothieware and reprap firmware supports these kinematics
waiting for washed down on marlin: (

@pinchies

This comment has been minimized.

Copy link

commented Jul 23, 2019

Just want to add the jgaurora A5S and A1, I鈥檝e been debugging marlin 2.0 with both and most things are working great. Bltouch not working yet since servos not working. SD card reliability I would describe as 99%, but that could be due to wire shielding issues. EEPROM on SD working fine. This is all on ZET6 like robin and alfawise. LCD touch working via same method as for those boards too, just a different calibration for screen touch values.

@RiRilot

This comment has been minimized.

Copy link

commented Jul 23, 2019

I'm testing 2.0 on an SKR V1.3 with TMC5160s on all axis and BLTouch. It's all working well apart from the wierd layer shift issue. Happy to test any fixes you might have for that. This is my deveopment printer so can be up and down as needed.

@coreyfaure

This comment has been minimized.

Copy link

commented Jul 23, 2019

I'm testing 2.0 on an SKR V1.3 with TMC5160s on all axis and BLTouch. It's all working well apart from the wierd layer shift issue. Happy to test any fixes you might have for that. This is my deveopment printer so can be up and down as needed.

Have you been able to get Linear Advance working on your end, or is that something you've tested at all? I can't seem to find a whole lot of results for other tests with Linear Advance on the SKR 1.3. I'm using TMC2208s on the X, Y and Z axis and an A4988 on the E and the calibration patterns won't produce anything usable.

@RiRilot

This comment has been minimized.

Copy link

commented Jul 23, 2019

It's next on my list to test actually. Might have some data tomorrow.

@RiRilot

This comment has been minimized.

Copy link

commented Jul 25, 2019

Linear advance working fine on SKR V1.3. K factor came out at 0.8 with my Bowden setup after calibration.

@coreyfaure

This comment has been minimized.

Copy link

commented Jul 25, 2019

Linear advance working fine on SKR V1.3. K factor came out at 0.8 with my Bowden setup after calibration.

Which drivers do you have?

@RiRilot

This comment has been minimized.

Copy link

commented Jul 25, 2019

TMC5160s in SPI mode on X, Y, and Z. A4988 on E0.

@thordarsen

This comment has been minimized.

Copy link

commented Jul 26, 2019

On my SKR1.3 Linear Advance works fine with my Titan Aero setup. (2208 XY, A4988 ZE; 0.13 PLA, 0.18 PETG, 0.26 TPU) I've not had much luck when using a Bowden setup, but never tried anything close to 0.8 either.

On another topic, is there a good way to figure out the pins for STM32F1 (03RCT6)? I got an XVico X1 dirt cheap mostly for parts. The main board is discussed here: https://tinkerfiddle.blogspot.com/2019/
I've dug a little further - I know its running DLion firmware - V4 or later. And its based on the DLion Mini board ( https://item.taobao.com/item.htm?spm=a1z10.5-c-s.w4004-17760143202.4.256738f4qt6iZ8&id=592299690248 ) which is I think made by logeek.cn. They make the DLion source available (V04) but the board schematic and pins.h are for the non mini variant. And my extensive use Google Translate has run into a wall getting the info for my board. (I can post the pins.h file and schematics for the non Mini board if anyone wants it)

@coreyfaure

This comment has been minimized.

Copy link

commented Jul 26, 2019

On my SKR1.3 Linear Advance works fine with my Titan Aero setup. (2208 XY, A4988 ZE; 0.13 PLA, 0.18 PETG, 0.26 TPU) I've not had much luck when using a Bowden setup, but never tried anything close to 0.8 either.

Could you share your config files for your SKR 1.3 and 2208 setup? I've been wrestling with this issue for three weeks and I'm very curious as to what's setup wrong on my end.

@thordarsen

This comment has been minimized.

Copy link

commented Jul 26, 2019

On my SKR1.3 Linear Advance works fine with my Titan Aero setup. (2208 XY, A4988 ZE; 0.13 PLA, 0.18 PETG, 0.26 TPU) I've not had much luck when using a Bowden setup, but never tried anything close to 0.8 either.

Could you share your config files for your SKR 1.3 and 2208 setup? I've been wrestling with this issue for three weeks and I'm very curious as to what's setup wrong on my end.

Here you go. My 2208's are currently in standalone mode because I haven't wrangled up a soldering iron yet (why couldn't they just put a jumper/DIP switch there for UART?)

Configuration.zip

@coreyfaure

This comment has been minimized.

Copy link

commented Jul 26, 2019

On my SKR1.3 Linear Advance works fine with my Titan Aero setup. (2208 XY, A4988 ZE; 0.13 PLA, 0.18 PETG, 0.26 TPU) I've not had much luck when using a Bowden setup, but never tried anything close to 0.8 either.

Could you share your config files for your SKR 1.3 and 2208 setup? I've been wrestling with this issue for three weeks and I'm very curious as to what's setup wrong on my end.

Here you go. My 2208's are currently in standalone mode because I haven't wrangled up a soldering iron yet (why couldn't they just put a jumper/DIP switch there for UART?)

Configuration.zip

Thank you for this. I duplicated your settings (even down to putting my drivers back in standalone mode) and I'm still getting strange behavior. Do you happen to have a 24V power supply or 12V? I've got a 24V and I can't help but wonder if something is wrong regarding that.

@thinkyhead

This comment has been minimized.

Copy link
Member Author

commented Jul 28, 2019

Grand Central support has arrived with #14749

@simon-jouet

This comment has been minimized.

Copy link

commented Jul 28, 2019

Tests

Okay now that I have a new ESP32 board, I went through the list to check what is working and what's not. All of these tests have been done against fec52e6

  • SDCard: working fine managed to complete a print without problems.
  • LCD:
    • SSD1306 OLED over I2C is working. thanks @Idorobots
    • HD44780 from a RepRap Smart Discount controller is working fine, the rotary encoder as well. But I wouldn't really recommend this as it uses a lot of pins which are quite precious on the ESP32. For this to work I had to remove LiquidCrystal from the platformio lib_ignore. I think this should be removed by default as it's not causing issues.
    • I might try an ILI9341 over SPI at some point (#14578)
  • TMC SPI: Working fine with TMC2130, currently running TMC2130 in X, Y, TMC2130_standalone in Z and a DRV8825 in E. The SPI bus is shared with the SDCard.
  • TMC UART: Cannot test, I was planning to order TMC 2209 but looks like most shops are out of stock
  • EEPROM: It does work but we should move the current implementation from SPIFFS to NVS
  • WiFi:
    • OTA: is working fine (and it's very very nice), this should probably be improved to not allow firmware upload while printing.
    • WebUI: is not great, it kinds of work, I started the SDprint from that BUT some messages do crash the socket (e.g M115). The current UI doesn't auto reconnect to the socket. Anyway, I need to get back to @luc-github about this to see how we can go forward (probably replace current code).
  • MAX6675: I can't test
  • NeoPixel: Working fine
  • FAST_PWM_FAN: The ESP32 uses ledc hardware PWM already so this should work fine, we just need to implement the set_pwm_frequency and set_pwm_duty in the HAL

Example OTA config for platformIO

upload_protocol = espota
upload_port = 10.66.0.102
upload_flags = -p 3232

SSD1306 deps changes

I should create a MR for this but in the meantime

 lib_deps =
+  ${common.lib_deps}
   https://github.com/me-no-dev/AsyncTCP.git
   https://github.com/me-no-dev/ESPAsyncWebServer.git
 lib_ignore  =
-  LiquidCrystal_I2C
   LiquidCrystal
-  NewliquidCrystal
-  LiquidTWI2
   TMC26XStepper
   c1921b4
-  SailfishLCD
-  SailfishRGB_LED

RepRap Discount Smart Controller

IMG_4027

NeoPixel (ws2812b with a dodgy setup)

IMG_4030

@GMagician

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2019

Only things that really are tested in AGCM4 and that seems to work are: onboard SD and onboard eeprom
LCD is not working yet (missing u8 libs code), servo have some issue with original library (doesn't work, doesn't compile but there are some PR that should fix these) while tmc may work but are not tested because I don't have any shield and any stepstick to test.

@Idorobots

This comment has been minimized.

Copy link

commented Jul 30, 2019

SSD1306 OLED over I2C is not working because u8glib doesn't support the ESP32. Using u8g2 would solve this but it's not currently used in Marlin

I did implement that support in the Marlin fork of u8glib here: MarlinFirmware/U8glib-HAL#7 Unlike on LPC (see #13550) on ESP32 it does seem to be stable.

@simon-jouet

This comment has been minimized.

Copy link

commented Jul 30, 2019

SSD1306 OLED over I2C is not working because u8glib doesn't support the ESP32. Using u8g2 would solve this but it's not currently used in Marlin

I did implement that support in the Marlin fork of u8glib here: MarlinFirmware/U8glib-HAL#7 Unlike on LPC (see #13550) on ESP32 it does seem to be stable.

Thanks I will check that at some point, I managed to compile fine when I did the tests but I had a crash loop when Marlin tried to initialise the screen. I assumed it was because of u8glib compatibility but apparently not. The crash was in u8gInit if i remember correctly.

EDIT: working fine with @Idorobots changes

@0x3333

This comment has been minimized.

Copy link

commented Aug 1, 2019

What do you guys means with:

STM32: Needs software serial

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.

@tpruvot

This comment has been minimized.

Copy link

commented Aug 2, 2019

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.

@0x3333

This comment has been minimized.

Copy link

commented Aug 2, 2019

Well, if that's the case, it is not a "Software serial" that is needed... odd.

@pinchies

This comment has been minimized.

Copy link

commented Aug 3, 2019

@thinkyhead - core function things (LCD, USB serial, SD, Touch, SD-on-eeprom) are working great now on A5S/A1. Can we add them to the supported list to RC1?

@gloomyandy

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2019

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

@0x3333

This comment has been minimized.

Copy link

commented Aug 5, 2019

@gloomyandy yeah, I thought that was the reason. The LPC176X is using arduino software serial, and it is blocking, isn't it?

@gloomyandy

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can鈥檛 perform that action at this time.