classicrocker883 / MRiscoCProUI

This is optimized firmware for Voxelab Aquila & Ender3 V2/S1 3D printers.
https://classicrocker883.github.io/
Other
79 stars 17 forks source link

[BUG] Crash and reboot after second time gcode preview #64

Closed Weresk closed 10 months ago

Weresk commented 1 year ago

Did you test the latest release build?

Yes, and the problem still exists.

Bug Description

Crash and reboot after second time gcode preview.

  1. Open file on sd card
  2. Cancel print
  3. Open file on sd card

Printer Model

Voxelab Aquila

Model Type

No response

Your Mainboard

Aquila GD32

Other Mainboard Type

No response

Add-ons that could be involved

No response

ProUI?

ProUI

Bed Leveling

Default - No Probe / No Bed Leveling

Did you include your own configuration files?

Additional information & file uploads

Version: 2.1.3d-2c (try on precompiled and custom configurations)

classicrocker883 commented 1 year ago

can you explain a bit more how this happens? so does it freeze? and reboots after viewing the gcode preview after 2nd time? meaning view it onces, go back, view it again?

if anything, I would suggest try the Manual Mesh - MM version see if that still happens. otherwise i'll look into this and do some tests.

classicrocker883 commented 1 year ago

update

I can confirm this does happen. with all versions. except for 422 and 427. you can disable the preview in Control --> Advanced Settings


otherwise a simple temporary fix is to select another file that does NOT have a thumbnail preview, or you can navigate into another folder/directory and go back.

with some smaller image files I was able to have it load a couple times before the issue happened.

Weresk commented 1 year ago

Aquila board and creality 422 use the same hardware, why for 422 all works. Or I am wrong?

classicrocker883 commented 1 year ago

Aquila board and creality 422 use the same hardware, why for 422 all works. Or I am wrong?

I Have a 427 which is basically the same as 422. there is no issue there because the problem is there isn't enough SRAM memory, and the issue is it isn't clearing properly when canceling the print.

so with the other boards they have more memory available and can store more image "cache". If I can find a way to help clear the memory then it would work how it should.

I tested this a couple ways, I found a gcode file that loaded kinda quick, I was able to select to load, and cancel several times. on the 4th time it froze. but any other file which may take longer to load has more memory to fill, so when I went back to select again it would freeze 2nd time like you said.

for now a quick fix for now is to either go to another folder then back, or select a file without a thumbnail to load and then back.

I've done a couple tests with what I thought would help clear the memory, no success yet.

if I can find out the code that actually clears the ram I think we're good.

classicrocker883 commented 1 year ago

there is an update in the new release for Cura slicer script for viewing Gcode preview.

you should be able to edit the size of the image preview. it's recommended not to be larger than 32kb.

secondly, I haven't been able to find a meaningful fix or workaround. so for now I suggest be careful with how many times you open the file, I was able to get 3 or 4 from 1 and others only 1 or 2. follow the temporary workaround for now.

Nazar78 commented 11 months ago

MRiscoCProUI - Thumbnail Preview https://youtube.com/shorts/uF3UFeyhQ6U?feature=share

I got it working on the N32G455RE with the pro ui ex and toolbar, with the released bins and default 15kb max thumbnails, it will just crash on the second view. Don't think it's not due to the SRAM:

RAM:   [===       ]  26.3% (used 17248 bytes from 65536 bytes)
Flash: [====      ]  43.5% (used 228164 bytes from 524288 bytes)

Think the fault lies somewhere in the libs which I can't say much as it's a private library :( So I instead used the no_pro, with some changes that will also prompt when there's no preview, existing ones starts the print immediately if there's no thumbnail.

And I'm not sure if I should continue using this build now that maple is deprecated. Appreciate much that Andrew is still supporting this. See if I can clean up and open a PR, I have one old issue that I need to dig again, which is after compiling from my archives, the print will crash not till I start from fresh.

classicrocker883 commented 11 months ago

@Nazar78 wait so you had got this to work? but then you say it still crashes on the 2nd view?

classicrocker883 commented 11 months ago

it is most unfortunate that Mriscoc isnt keeping up with the maple builds for the library. I'm sure if enough of us complain over on his channel he might go back supporting it. I explained to him that Aquilas don't work without Maple, he says it's depreciated, but that doesn't mean anything about it being usable. unfortunately we're stuck using maple builds. I mean you can use his without the ProUI, but that means no toolbar and all that other neat stuff.

Nazar78 commented 11 months ago

@Nazar78 wait so you had got this to work? but then you say it still crashes on the 2nd view?

Sorry if I wasn't being clear, the 2nd view crashing was when I tested with your N32 release binary. I then tried modifying the codes and got it working, refer to the previous YT video. Now I changed it further to select Cancel by default and added a no preview thumbnail.

it is most unfortunate that Mriscoc isnt keeping up with the maple builds for the library. I'm sure if enough of us complain over on his channel he might go back supporting it. I explained to him that Aquilas don't work without Maple, he says it's depreciated, but that doesn't mean anything about it being usable. unfortunately we're stuck using maple builds. I mean you can use his without the ProUI, but that means no toolbar and all that other neat stuff.

What I read is that Marlin and PlatformIO is still keeping maple for legacy backward compatibility albeit not for new projects (maybe for newer MCUs and not existing?), https://community.platformio.org/t/maple-deprecation/22888. So yes the author cutting off maple builds is really unfortunate as the deprecation is targeted at newer MCU projects and not the UI itself.

I gotta ask though, where's the original source for the gcode_preview_nopro.*? I couldn't find any reference even back to the original source Marlin and mriscoc/Ender3V2S1.

And before I open a PR for this issue, the question is, going forward are we (Aquila folks) going to continue pulling and adapt the changes from the mriscoc/Ender3V2S1 or are we headed a different way since the deprecation of maple by the author? This is because I also actually managed to compile and flashed the latest mriscoc/Ender3V2S1 N32G455RE based with all the ProUI bells and whistles (edited: refer to https://github.com/classicrocker883/MRiscoCProUI/issues/77#issuecomment-1754516092). But to adapt the upstream changes is a huge challenge since the owner is now using private libraries (saw one of his topic protecting his work).

classicrocker883 commented 11 months ago

"gcode_preview_nopro" was something I made up as well for this fork. I think there was a time when the gcode_preview worked even without PROUI_EX enabled (the extra ProUI library stuff), but now it doesn't. So what I did was since it does work in the base Marlin source code, I copied it over here, and renamed it with "_nopro" as to not confuse it when the PROUI_EX is set, because that loads it from the library.

basically with the gcode_preview files of Marlin source, its like having access to the private lib/proui/[chip]/libproui_xxx.a library. and with that I tried some things as to clear the cache or RAM or whatever so that it can stop the screen from freezing and rebooting after viewing a gcode file too many times. but some preview images you can select several times more than others.

because using a Creality 427 board, with 512K, it has no issue viewing gcode previews. since it has more flash and memory it has no need clearing the image cache after canceling.
I tried a few things to get stop the issue...
like

return delete[] fileprop.thumbdata, 

to no avail.
I posted about it here https://github.com/MarlinFirmware/Marlin/issues/26169#issuecomment-1756601786

I also actually managed to compile and flashed the latest mriscoc/Ender3V2S1 N32G455RE based with all the ProUI bells and whistles.

since the Maple environment isn't available for the latest mriscoc/Ender3V2S1, what did you use? basically anything using ini/stm32f1-maple.ini cant use the ProUI extra library.

can the N32G455RE use something like env: STM32F103RE_creality for the default_envs = in platformio.ini?

Weresk commented 10 months ago

it is most unfortunate that Mriscoc isnt keeping up with the maple builds for the library. I'm sure if enough of us complain over on his channel he might go back supporting it. I explained to him that Aquilas don't work without Maple, he says it's depreciated, but that doesn't mean anything about it being usable. unfortunately we're stuck using maple builds. I mean you can use his without the ProUI, but that means no toolbar and all that other neat stuff.

I found this pdf https://github.com/MarlinFirmware/Marlin/files/10098465/compatibility.sumup.between.GD32.and.STM32_V2.0.pdf Is it enough to change Maple environment?

Nazar78 commented 10 months ago

"gcode_preview_nopro" was something I made up as well for this fork. I think there was a time when the gcode_preview worked even without PROUI_EX enabled (the extra ProUI library stuff), but now it doesn't. So what I did was since it does work in the base Marlin source code, I copied it over here, and renamed it with "_nopro" as to not confuse it when the PROUI_EX is set, because that loads it from the library.

Noted on this.

because using a Creality 427 board, with 512K, it has no issue viewing gcode previews. since it has more flash and memory it has no need clearing the image cache after canceling.

For the N32G455RE, my 1.0.1 board, even though in the specs it says 512K of flash, it seems to be limited to only max 228K. I.e. if the binary build exceeds 228K, it will not run the flash procedure, it will just startup normally, with the firmware.bin removed from the sdcard. It might be limited in the bootloader, without checking it I'm not sure. However we're dealing with the SRAM, 144K-40 for the N32 (128K-40 for CR 4.x boards?) and even that crashed on the second preview:

MEMORY
{
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 128K - 40
  rom (rx)  : ORIGIN = 0x08007000, LENGTH = 512K - 64K
}

I tried a few things to get stop the issue... like

return delete[] fileprop.thumbdata, 

As I said earlier I got it working by modifying the gcode_preview_nopro.*, not the private libs. So the fault should be solely on the outdated private libs.

since the Maple environment isn't available for the latest mriscoc/Ender3V2S1, what did you use? basically anything using ini/stm32f1-maple.ini cant use the ProUI extra library.

can the N32G455RE use something like _env: STM32F103REcreality for the _defaultenvs = in platformio.ini?

The non-maple doesn't work, I'll get in touch with you in a separate discussion. But back to the issue, can I create the PR based on the gcode_preview_nopro.*? This is because the private libs for this fork seems "different" thus I'm not sure if it's possible incorporate the changes from the upstream using the updated private libs. I'm now using the Ender3V2S1 build (mainly for the laser stuffs) and there's no crashing issue with the thumbnail preview.

Weresk commented 10 months ago

I think this can fix maple framework "problem" https://github.com/CommunityGD32Cores/platform-gd32

classicrocker883 commented 10 months ago

The non-maple doesn't work, I'll get in touch with you in a separate discussion. But back to the issue, can I create the PR based on the gcode_preview_nopro.*? This is because the private libs for this fork seems "different" thus I'm not sure if it's possible incorporate the changes from the upstream using the updated private libs. I'm now using the Ender3V2S1 build (mainly for the laser stuffs) and there's no crashing issue with the thumbnail preview.

yes, a PR would be great - by all means do so. as you said the private libs for this fork are older, because they do not have support for the Maple GD32. it seems that mriscoc fixed the issue then for the thumbnail crashing.... in the most recent Ender3V2S1 fork of course.
it would be nice if I were able to swap over to that fork....but those dang private libs.

anyway if you can post anything which may help, I may be able to make some kind of work around.

I found this pdf https://github.com/MarlinFirmware/Marlin/files/10098465/compatibility.sumup.between.GD32.and.STM32_V2.0.pdf Is it enough to change Maple environment?

this is interesting information. its plausible that incorporating these kinds of changes may actually make the non-maple env to work. however, that kind of scope is beyond me, and I wonder if someone actually has implemented those fixes. the thing is, it seems our issue/problem/dilema encompasses only in this case. basically, what other reason would anyone want to make the non-maple env work for Maple chips?? in other words, we are probably on our own.

Weresk commented 10 months ago

this is interesting information. its plausible that incorporating these kinds of changes may actually make the non-maple env to work. however, that kind of scope is beyond me, and I wonder if someone actually has implemented those fixes. the thing is, it seems our issue/problem/dilema encompasses only in this case. basically, what other reason would anyone want to make the non-maple env work for Maple chips?? in other words, we are probably on our own.

I did try implement this fix, but I have not GD32 board now. Can you test this firmwares? https://dropmefiles.com/u2NtY

classicrocker883 commented 10 months ago

I did try implement this fix, but I have not GD32 board now. Can you test this firmwares? https://dropmefiles.com/u2NtY

sure, can you give me some details about these files?

Weresk commented 10 months ago

image This fix start-up time Works?

classicrocker883 commented 10 months ago

image This fix start-up time Works?

@Weresk ill get back to you on that, so it is just supposed to make boot load faster? is there anything else I look out for? or how could I use this fix in my own build?

Weresk commented 10 months ago

image This fix start-up time Works?

@Weresk ill get back to you on that, so it is just supposed to make boot load faster? is there anything else I look out for? or how could I use this fix in my own build?

There are two files, which one works? And i will write what i modified

Weresk commented 10 months ago

Anybody can test this firmwares?? Firmware.zip

classicrocker883 commented 9 months ago

Anybody can test this firmwares?? Firmware.zip

hi sorry for the delay, i had to swap my test rig over to this mainboard type.

anyway I tested both of those files, A + B, and neither worked. neither loaded into the main menu, it hung at startup.

github-actions[bot] commented 6 months ago

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.