[FR] MMU3 Feature

[eoyilmaz]

Is your feature request related to a problem? Please describe.

I started working on the MMU3 interface, and I wanted to report this feature request to consolidate all future efforts in one place. So, anybody interested please feel free to join the discussion here.

I already have an MMU3 setup, albeit working on an Ender 3 Pro + SKR 3 EZ board with the 1.0.6 firmware of the MMU2s. Just updated the MMU firmware to version 3.0.2 today and I had to adjust some StalGuard thresholds and motor currents so the Idler homes properly. The communication between the boards is not working right now. My setup includes an Arduino Mega 2560 board inbetween the Marlin and MMU boards so that I can intercept the messages between these two boards more easily. The MMU code base is very clean and very easy to read, and it is surprisingly easy to build (I didn't expect that tbh).

So, yeah, let's do it!

Are you looking for hardware support?

Yes, I'm interested in MMU3 support.

Describe the feature you want

Fully working MMU3 with the advertised:

• Full two-way communication with the printer,
• LCD screen integration (status messages, real-time information, error codes)

Additional context

My MMU3 Project Page

[ellensp]

MMU3 Information https://help.prusa3d.com/article/registers-mmu-mmu3_511780
M704 gcode https://reprap.org/wiki/G-code#M704:_Preload_to_MMU
M707 gcode https://reprap.org/wiki/G-code#M707:_Read_from_MMU_register
M708 gcode https://reprap.org/wiki/G-code#M708:_Write_to_MMU_register
M708 gcode https://reprap.org/wiki/G-code#M709:_MMU_power_.26_reset

[eoyilmaz]

@ellensp thanks for the info...

Status update, I was able to communicate with MMU3 last night... The CRC8 stuff is working properly...

For prototyping purposes, I'm currently filtering out the CRC8 stuff from the MMU3 and add back to the commands coming from Marlin...

Next, what I want to do is to obtain the Prusa firmware (the currently shared source code I think is still communicating with MMU2s version 2.1.9, there is a MMU300 branch to be investigated) and see how different it is from the current implementation in Marlin.

[plampix]

@eoyilmaz Anything above 3.13 will only work with MMU3 FW 3.0 and above. 3.12 and below will only work with 1.06 and below.

[eoyilmaz]

We should also consider doing the same to be honest, at least we should remove the old MMU stuff completely.

[thisiskeithb]

we should remove the old MMU stuff completely.

To prevent breaking builds for users who upgrade Marlin, but run an older MMU/MMU firmware, we’d just need to add notes to the MMU config section with compatible MMU & MMU firmware versions.

[eoyilmaz]

@thisiskeithb sure, but I was reffering the MMU1 stuff, the oldest version that nobody is probably using anymore. Of course, we should keep everything related to MMU2/MMU2s.

@eoyilmaz Anything above 3.13 will only work with MMU3 FW 3.0 and above. 3.12 and below will only work with 1.06 and below.

sure thing, I'll base my code to 3.13...

From Marlin's perspective, MMU with a firmware version of 1.0.6 is considered the MMU2s (you need to set the MMU_MODEL to PRUSA_MMU2S to work with it) and anything new (3.x.x) should be considered MMU3 (most probably you need to set the MMU_MODEL to PRUSA_MMU3), I don't remember if Prusa has ever released the MMU firmware 2.x stuff, from the commit messages I see that they renamed the 2.1.9 to 3.0.0.

[thisiskeithb]

sure, but I was reffering the MMU1 stuff, the oldest version that nobody is probably not using anymore.

We don't remove support because something is old. There's no reason to remove it.

[eoyilmaz]

We don't remove support because something is old. There's no reason to remove it.

ah, sure then, it was already too early to talk about this tbh... let's add the MMU3 support, then we can talk about the rest 👍

[eoyilmaz]

Instead of deep diving into the work directly, I would like to approach this in a more structured and professional manner, create an EPIC, investigate it with a SPIKE, divide the work in small manageable chunks etc. as we normally do in our studio. So I'm moving back to my own repository, will create all the work tickets there, I'll update this ticket most probably with the list of feature tickets that needs to be implemented and create PRs as I gone through them.

[eoyilmaz]

Here is some progress on destructing the new protocol: eoyilmaz#2 (comment)

[eoyilmaz]

Hey folks, let me do some progress reports:

• I moved all the MMU3 related source code from PrusaFirmware to Marlin, most of the code didn't require too much modification. But, as Prusa firmware is mostly based on Marlin1 I had to do a lot of detective stuff and find similar functionalities in Marlin2 and there were couple of places where the implementation were just existing in Prusa and not directly in Marlin.
• I had to comment out a lot of EEPROM related functionality coming from Prusa as I'm not experienced with reading & writing from PersistentStore and creating new data structures for that purpose and I need supervision. In PrusaFirmware, they have defined the addresses and the data sizes in an header file contrary to Marlin's way of laying out the data structure.
• Implemented (or moved/modified) the new M-Codes (M704, M705, M706, M707, M708, M709) as they were just wrappers to the new MMU2 API. Reading/writing to EEPROM stuff is currently disabled. So for now, for example the cutter is always enabled.
• For now, I had to disable some of the menus coming from Prusa as the menu system they are using is completely different, but I think I can handle these, but it will require a complete rewrite.
• I temporarily kept the MMU2/MMU2s menus and connected them to MMU3 api if the MMU_MODEL is PRUSA_MMU3.
• Ah yeah, and we now have a new PRUSA_MMU3 value for MMU_MODEL that enables the MMU3 stuff to be compiled.
• I kept the MMU2/2s code intact, setting the MMU_MODEL to PRUSA_MMU2/PRUSA_MMU2S will compile Marlin with MMU2/S features.
• Ah one more thing, I also moved the Spool Join feature, but it is not selectible from the menus yet.
• Some of the paths require C++17, there were a couple of switch..cases that require [[fallthrough]] but it is not available in C++11, converted them to if..else (and as I see we have two more of these cases left, will fix it later on).

Otherwise, I was just able to compile Marlin with MMU3 support and will test it after my current print finishes and I'll report back... I'm not expecting it to work out of the box tbh.

Yeah, that's all for now, cheers...

[eoyilmaz]

Surprise surprise 😄 it is mostly working 🎊

I had to fix the required MMU firmware version in Marlin from 3.0.1 to 3.0.2. As I see PrusaFirmware requires an exact match of the MMU firmware otherwise disables the MMU communication after reporting something like "MMU requires FW Update disabling" or so.

Things are working:

• Marlin <-> MMU initialisation and communication
• The new M70x gcode commands
• MMU status and progress messages are properly displayed on the LCD, so when it loads a filament you can properly see a "Feeding to FINDA" etc. kind of messages in the status screen as it progress through all the stages of loading/unloading a filament.

Things are broken:

• Marlin menus are not working properly after displaying MMU related messages.
• I cannot get any MMU registry values with M707 A00x00 commands.
• Requesting a filament change through T0 is not fully working, but I think it is related to my setup, and the command is properly sent to MMU and a proper response is retrieved back, only the filament is not loaded properly.

anyways, I'm very excited as I was not expecting anything to function not even a little 😄

[eoyilmaz]

Another progress report:

I just completed my first successful print with the MMU3 that had 36 filament changes (very small test print)... The main functions are now fully working, and I'm quite happy with my progress... I still need to work on the LCD reporting & interaction and EEPROM & PersistentStore stuff though...

You can track my todo list here btw: eoyilmaz#3

[eoyilmaz]

Status Update:

Just finished a 540+ filament change print job without any issues related to the Marlin + MMU3 (the only 2 issues I had were related to one of the filaments and my own setup):

[eoyilmaz]

I also worked on the LCD and EEPROM related stuff and it is theoretically done. I'll test and report back. So this is as good as or better than the current MMU2s implementation and I'm very close to creating a PR 👍

[eoyilmaz]

Latest changes:

• Updated MMU Menu:
  • Added Enable/Disable Cutter (this has 3 states, 0: Disabled, 1: Enabled 2: Always, I kept off the state 2: Always from the menus as even Prusa deems this feature to be experimental).
  • Added "Cut Filament" menu if MMU_HAS_CUTTER is set in the Configuration_Adv.h and the Cutter is enabled.
  • Added Enable/Disable Spool Join feature (This still requires M600 AUTO to be implemented).
  • Added "Fail Stats" menu.
    • Added stats menu for the last print job (this is not resetting on every print job start, this needs work)
    • Added stats menu for the total failures of printers life time.
    • Added stats for total material changes done (this is the total material changes during the printer lifetime, I need to add menu item to display material changes of the current/last print).
• Updated settings to store the following data in EEPROM:
  • MMU print & fail stats
  • Cuter Enable/Disable state
  • Spool Join Enable/Disable state
  • MMU Stealth Mode (currently appears to be read-only in MMU firmware and cannot be changed with M707/M708, but we had MMU2_MODE_12V with MMU2s and it was actually setting the stealth mode, so this should be available in the future and I'll keep this).
  • MMU Enable/Disable state
• M503 now prints MMU related data

I'm kind of ready to tidy up the code and create the PR...

And then I have some improvements that I want to make over the Prusa implementation:

• Check hotend before loading filaments to the extruder:
  As far as I see they don't check if the hotend is cold or hot before loading the filament to the extruder, I want to add checks to prevent this as in MMU2s implementation of Marlin, of course, if this is not a design decision of Prusa... I'll do my research before that.. This is not true, MMU3 code checks the hotend temperature before doing things...
• The "Sounds On/Off" option should be added to the menus, which should be fairly easy.

[eoyilmaz]

Here is a video showing the menus and the new fail stats (numbers in the video are fake data 😄 ) and a screen capture for M503 output:

Video showing MMU Menus

[thisiskeithb]

Great progress! I'll have to dust off my MMU2 and pick up a MMU3 upgrade kit.

Check hotend before loading filaments to the extruder:

Tying into PREVENT_COLD_EXTRUSION would be ideal here. Marlin also now asks if you want to continue if the nozzle temp is below EXTRUDE_MINTEMP.

The "Sounds On/Off" option should be added to the menus, which should be fairly easy.

Tying into SOUND_MENU_ITEM / SOUND_ON_DEFAULT would be ideal here.

This video doesn't work in Firefox or Safari for some reason (macOS).

[eoyilmaz]

Tying into PREVENT_COLD_EXTRUSION would be ideal here. Marlin also now asks if you want to continue if the nozzle temp is below EXTRUDE_MINTEMP.

Tying into SOUND_MENU_ITEM / SOUND_ON_DEFAULT would be ideal here.

sure sure 👍

This video doesn't work in Firefox or Safari for some reason (macOS).

Strange, I'm on macOS too... let me upload the original version... oh it is bigger than what GitHub accepts, here is a download link: https://www.dropbox.com/scl/fi/xu2r8mjhy4p8k2s9vyult/IMG_2856.MOV?rlkey=j1e25qas8fwxjbiugy83nhl63&dl=0

[eoyilmaz]

Updated the format of MMU part of the M503 a little:

[eoyilmaz]

@thisiskeithb I have a question, I'm working on enabling the SpoolJoin feature, I introduced the AUTO flag to M600 and it is working fine.

The SpoolJoin feature requires checking a couple of conditions to decide to run "M600 AUTO" or not and one of the conditions is using printJobOngoing() at https://github.com/MarlinFirmware/Marlin/blob/994aa9f6923e2307d13badd26a15e6d57525955f/Marlin/src/MarlinCore.cpp#L342C6-L342C21

From what I understand from the function name and the content it should return true if the print job is on going :)

When I start the job (through OctoPrint by the way) it returns true until my printer homes and starts extruding (or maybe a little before) then it starts returning false. Is there something wrong with that function, my setup, or am I misunderstanding something?

[eoyilmaz]

I was able to run the SpoolJoin, but there is an issue... At least with my setup.

The issue is that, as in my case, if the distance between the extruder gears to the nozzle tip is smaller than the distance between MMU FINDA sensor to MMU pulley gears, when the extruder pushes back the filament it will not be able push the filament back as much so that the pulley gears can grab them. I hope it makes sense... The filament stuck inside the tube between MMU FINDA and extruder, in a position nothing can pull it back or forth.

I modified the code so that it will try consuming the filament completely before loading the next filament instead of retracting it back. I'm sure Prusa people also wanted to do this as one of the functions they are using to decide if it is time to run SpoolJoin, is called check_fsensor(), but it doesn't contain anything related to filament sensor. But I'm sure their intention was to consume the filament completely and they had issues with that as a little bit of filament will be left inside the extruder, I'm hopping that it will not be a problem and I'll add a config option to Enable/Disable this behaviour (if it works at all of course).

[eoyilmaz]

Interestingly, I was able to achieve what I was offering, so the filament change only occurs when the filament is completely consumed, and it is working fine... Except, after MMU loads the next filament a "Purge More" / "Continue" screen appears, I was hopping to skip this screen... Let's see...

[eoyilmaz]

This is working very nicely and I found where the "Purge More" / "Continue" menu is triggered...

[eoyilmaz]

The SpoolJoin is now working as intended.

I had to add two new parameters to the resume_print function to be passed to the load_filament function. Hopefully most of the places that resume_print is used, no argument is passed to it.

I also made the "SpoolJoin Consumes All Filament" an experimental and optional feature and added the following to the Configuration_Adv.h:

    /**
     * SpoolJoin Consumes All Filament -- EXPERIMENTAL
     * 
     * SpoolJoin normally triggers when FINDA sensor untriggers while printing.
     * This is the default behaviour and it doesn't consume all the filament
     * before triggering a filament change. This leaves some filament in the
     * current slot and before switching to the next slot it is unloaded.
     * 
     * Enabling this option will trigger the filament change when both FINDA
     * and Filament Runout Sensor triggers during the print and it allows the
     * filament in the current slot to be completely consumed before doing the
     * filament change. But this can cause problems as a little bit of filament
     * will be left between the extruder gears (thinking that the filament
     * sensor is triggered through the gears) and the end of the PTFE tube and
     * can cause filament load issues.
     */
    // #define MMU_SPOOL_JOIN_CONSUMES_ALL_FILAMENT

[eoyilmaz]

Alright solved the problem by not depending on the START_SCREEN, STATIC_ITEM and END_SCREEN but direclty putting the characters on to the screen with SETCURSOR and lcd_put_lchar():

[thisiskeithb]

That’s a lot of text, especially for a text-based 2004 LCD like the REPRAP_DISCOUNT_SMART_CONTROLLER.

[eoyilmaz]

That’s a lot of text, especially for a text-based 2004 LCD like the REPRAP_DISCOUNT_SMART_CONTROLLER.

This is only displayed when you request more info on the matter, tbh. And there is actually a short web url also displayed as in "prusa.io/04504" to get even more info, which I didn't include yet.

[eoyilmaz]

Finally, I was able to properly implement the "Fullscreen Error Messages & Actions" feature:

IMG_2954_480p.mov

In the "More Info" screen the second page is displayed with a button click, that might not be very Marlin style. If required we can improve it by utilizing the encoder so that the user can scroll between pages and return to the previous screen with a button click... But I'm going to leave it to another issue ticket, and let this be reviewed and hopefully merged soon...

[psharma04]

Trying to run your version on my SKR Mini E3 V3. Do you happen to know the pinout of the MMU3?
I'm trying to use this header


I have changed MMU2_SERIAL_PORT in Configuration_adv.h to 2 in an attempt to get it working, but I currently get the error "MMU not responding".

[eoyilmaz]

@psharma04 you're very lucky :) I was using a SKR Mini E3 V3 before my current board. The issue that you need solve first is that the MMU board is 5V TTL and SKR Mini E3 v3, like many other 32-bit boards, is 3.3V TTL. So you need to use a Level Shifter in between. I used this for that purpose: https://www.amazon.co.uk/gp/product/B095H64XSV/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1

Here is my custom board to host the level shifter: https://oshwlab.com/eoyilmaz/level-shifter

And also connect the RX port of one board to the TX port of the other and vice versa. Do not connect the RST pin, which is not needed.

[ellensp]

the SKR Mini E3 V3 TFT port is using PA2 (USART2_TX) /PA3 (USART2_RX)
both of which are "FT_a" ie they are 5 V tolerant I/O for digital inputs
but tft port will be 3.3v outputs (which is still fine, will be read as a logic 1)
A level shiftier is not required

[microtronics]

A level shiftier is not required

That's correct as per the datasheet and I'm using the same port on a BTT GTR.
Most STM32 pins are 5V tolerant, luckily!

[eoyilmaz]

@ellensp I remember that I checked the datasheet for STM32G0B1RE when I was setting up the MMU. But, I'm not an Electrics & Electronics Engineer and I might have read it incorrectly I thought the TX pin was 4.4V tolerant and the RX was 8.4V tolerant (they give a formula based on VDD etc.). But, that might not be correct, in anyways, I'm happy that I'm using the level shifter between 3.3V TTL and 5V TTL boards, and I believe that's the general suggestion.

[psharma04]

@psharma04 you're very lucky :) I was using a SKR Mini E3 V3 before my current board. The issue that you need solve first is that the MMU board is 5V TTL and SKR Mini E3 v3, like many other 32-bit boards, is 3.3V TTL. So you need to use a Level Shifter in between. I used this for that purpose: https://www.amazon.co.uk/gp/product/B095H64XSV/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1

Here is my custom board to host the level shifter: https://oshwlab.com/eoyilmaz/level-shifter

And also connect the RX port of one board to the TX port of the other and vice versa. Do not connect the RST pin, which is not needed.

I managed to figure it out, turns out the problem was a badly crimped cable (one that I made, not from Prusa). No level shifter needed, it just... worked as is.

For future reader's reference, if you're using the MMU3 cable for the Mk3 (the one with a 5 pin header), the default order is
RX(in) TX(out) GND RESET and then the blank pinhole.

If you'd like an extra test environment, I'm happy to test firmware changes on my machine (Ender 5-based CoreXY).

[SpankyDevil]

Can i get some assistance please.
I am running your PR version of Marlin, i have configured MMU2_SERIAL_PORT in Configuration_adv.h to 1 which is the TFT plug on my BTT SKR 3 and used the wiring as per the above post. Plus connected to 24v. I have not connected the Reset Pin
Note wired Rx to Tx and vice versa
_

For future reader's reference, if you're using the MMU3 cable for the Mk3 (the one with a 5 pin header), the default order is
RX(in) TX(out) GND RESET and then the blank pinhole.

_

I am running firmware MMU3_FW3.0.2+878

The MMU3 receives transmits from the SKR 3 so I can run M709 S1 and the MMU3 turns on and a blue light flashes then I can run a M709 S0 and the light turns off, but the whole time the SKR 3 is reporting it can't communicate with the MMU3 as per below screenshots.

Screenshots:

[eoyilmaz]

@SpankyDevil I'll try to return as soon as I have time.

[SpankyDevil]

Thanks,
Just an update i tried your branch for your printer and all i did was change the board model in configuration.h and tested it still came up with comunication errors but this time the status for MMU was reporting On and by running a M709 S0 i could turn it off then running M709 S1 i could turn it back on again and it reported On/Off correclty. As nothing else is connected to my board i cant find anyway to test further i did try M707 A0x04 but got no response.

I then tried the PR version and set my board model and enabled MMU3 and set Serial Port then enabled each feature as required to build and tested and i could turn MMU on/off but M709 reported MMU as Off the whole time.

I have added a 1K and 2K resistor to the MMU3 Tx line to step the voltage down to about 3.3v just incase this was causing an issue but that was done before trying your branch

Note when MMU is set to on there is a blue flashing light only and when set to off there is no ights, when i power it on the green lights come up then turn off and when set to off the green lights come on again then go off.

From: ESP3D Ecosystem > ESP3D > Version 3.X > Installation

[SpankyDevil]

Just wondering if anyone has this working with the current PR?
Would really like to get mine working.

[rerickson1]

Just wondering if anyone has this working with the current PR? Would really like to get mine working.

I have this working with my printer. I use a MKS_SGEN_L_V2 board though.

[SpankyDevil]

Just wondering if anyone has this working with the current PR? Would really like to get mine working.

I have this working with my printer. I use a MKS_SGEN_L_V2 board though.

Would you mind confirming a few things for me please

• Are you using Baudrate 115200
• What firmware version is installed on MMU3
• Are you connected to the TFT port on your board
• Have you connected the Reset PIN
• Are you seeing any communication errors
• Are you using the MK3S cable or MK4, if using the MK3S are you using this PIN OUT

For future reader's reference, if you're using the MMU3 cable for the Mk3 (the one with a 5 pin header), the default order is
RX(in) TX(out) GND RESET and then the blank pinhole.

[rerickson1]

• I didnt have to mess with baud rate at all. So it must be at some default.
• 3.0.2 firmware installed on my MMU2S
• No TFT, using 10 pin LCD connector
• Yes, reset pin is connected
• Flawless communication, no errors
• Using the 5 pin cable that came with my MMU2S

[SpankyDevil]

• No TFT, using 10 pin LCD connector

This version of Marlin for MMU3 requires you to have a screen enabled, so not having one physically connected but having Marlin think there is one isn't causing you any issues and running your MMU3 off of the EXP Serial.

Are you connecting through USB and manually inputting the codes to control the MMU3 which you would normally access through the Screen?

when you first power on your printer can you advise the LED status on your MMU3

[rerickson1]

• No TFT, using 10 pin LCD connector

This version of Marlin for MMU3 requires you to have a screen enabled, so not having one physically connected but having Marlin think there is one isn't causing you any issues and running your MMU3 off of the EXP Serial.

Are you connecting through USB and manually inputting the codes to control the MMU3 which you would normally access through the Screen?

when you first power on your printer can you advise the LED status on your MMU3

I use an LCD with my printer, just not a TFT touch screen. I control the MMU3 via the LCD menus.

On boot the orange LED pulses because the main board resets it. Then LED5 flashes rapidly while the other LEDs are on and then they all turn off.

[thisiskeithb]

I use an LCD with my printer, just not a TFT touch screen. I control the MMU3 via the LCD menus.

I think the confusion comes from your photo since it looks like you have the MMU3 connected to one of the EXP connectors normally used by the LCD, but you're connected to the 8-pin AUX1 connector (assuming it's an SGEN_L V2 based on your Marlin fork):

[rerickson1]

The header you highlight in the picture is not used by the LCD. The two connectors on the very bottom of that picture are used by the LCD.

[thisiskeithb]

The header you highlight in the picture is not used by the LCD. The two connectors on the very bottom of that picture are used by the LCD.

I know 😄 I was clarifying/highlighting it for @SpankyDevil.

[SpankyDevil]

If this is working for everyone else i must have faulty hardware, which is a real shame since the MMU3 is brand new and brought for me as a birthday gift.

I will connect the mainboard up using MMU2 method today this will eliminate the daughter board and use another cable in case either of them are at fault.

I still find it odd though that the PR branch never acknowledges the MMU3 been on but the Ender 3 branch knows when its Off/On

[SpankyDevil]

OK, wiring the MMU3 without the daughter board and using a different cable has got communication working.
See attached Log
20240723_095741__putty.log

[SpankyDevil]

Has anyone got this working with an MMU3? like one with the daughter board not just a flashed firmware MMU2 ?

I can get it working if wire directly to the MMU3 mainboard (MMU2 Wiring) but if I connect the daughter board Marlin doesn't detect the MMU3
I can run M709 S0 and the MMU3 powers off then M709 S1 and it powers on.

When i go into MMU Menu and click on MMU off to change it to on nothing happens.
when i do this on spool join or cutter it turns from off to on.

I purchased a new screen because my TFT didn't support Marlin Mode thinking maybe this was causing an issue, i have also purchased a new daughter board and cable.
Results are the same.

I am starting to get quite frustrated as I don't understand why it won't work and I've spent a lot of money on this which has been sitting there doing nothing for 3 months now :(

[SpankyDevil]

Thank You @dust Issue resolved.
The post above from psharma04 is an incorrect pinout.

For future reader's reference, if you're using the MMU3 cable for the Mk3 (the one with a 5 pin header), the default order is
RX(in) TX(out) GND RESET and then the blank pinhole.

The correct Pinout is

White Plug from the top gnd,gnd,24v,24v,reset,gnd,tx,rx

5 Pin Header Plug RESET GND TX(out) RX(in) and then the blank pinhole

@eoyilmaz Any chance of getting the PR updated with the latest Bug Fix version of Marlin?

[SpankyDevil]

It's really awesome to finally be able to use this, thank you and great work.

I have noticed a couple of Menu items not working, unsure if this is due to not being implemented yet or just unaware.

• When homing fails you are prompted with a "Retry/Tune/More Information" Menu only the retry option does anything.
• when loading filament fails you are prompted with a "Retry/More Information" Menu only the retry option does anything.
• the standard Unload/Load Menu is still shown on the screen but does not do anything when used.
• Prusa has an option called "Loading Test" can't find this.

[github-actions]

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.