I actually have no 5 volt power coming from the pie to the printer so that's not an issue I actually have the 5 volt connection blocked off there.
1 Like
I'm going to search for a different version of marlin for this printer if needed what I'll do is I'll run the stock version with the BL touch version I'm nearly positive vox lab has that and I'll see if the problems continue I don't really care too much about the display and how nice it looks because I do all my controlling from octo print only reason I got the custom firmware initially was I didn't have a BL touch so I was using the mesh leveling and without custom firmware that was not possible so I'm going to do this route first and see what happens thank you for the help I will update once I get some things in motion
Unable to install stock firmware that works with 3d touch the stock firmware looks like it works until I try to run bed leveling then it checks one point and then retracts pin and stays in place.
Installed a beta version 3x3 bl touch Marlin Alexqzd version
[v1.3.5.1 Beta 4]
(Release v1.3.5.1 Beta 4 - Gcode Previews · alexqzd/Marlin · GitHub)
Will update on the few days and see if that did the trick also past this firmware I don't see other custom firmware that works with Voxelab Aquila with G32 chipset
Went back to the stable version of this firmware as this data version had the same issues and installed all plugins that were suggested in the GitHub page to resolve connection issue and display issues. It worked flawlessly for 2 prints then it went back to crashing again at the very end of the third print when it completed. At this point I am out of ideas. I looked online for a different version of marlin for this vox lab Aquila printer but was unsuccessful. I ended up ordering a different motherboard for a pretty good price I have a feeling that's going to be my only solution at this point as it's not an intermittent problem but it does run successfully after some changes are made in the settings but then it goes back to crashing and the logs aren't giving any clear indication to what the issue is. I'm leaning that it is a firmware issue but I don't understand how firmware would allow the octoprint to operate correctly and then two three prints later crash octoprint not the raspberry pi just the October Python program.
Have you seen this?
I came across this but there was no clarification if this is for the g32 chip with a new motherboard on order and it should be here tomorrow I'll test this out I was debating doing this because I don't want to mess anything up with the boards if I flash the wrong firmware but with the motherboard on my way might as well try this last firmware try and see if that does the trick I can probably get four or five prints in between today and tomorrow to test this out before installing that board if issue persists thank you so much.
Just in case anybody sees this thread that link above for the custom firmware is not for the g32 chip I just tried installing it and it did not install it gave me an error it actually deleted the bin file from the firmware folder after the error tried multiple times same issue the creality screen does work but all you see is the creality sign. Ended up going back to the Alexqzd firmware mentioned above but went with the stable 1.3.4 version as a last attempt to see if this will work I even created a new profile in octoprint before connecting to this printer again not that that would make a difference but I figured what the hell right now I'm doing my first test print will update as soon as I get two or three prints under my belt as it will not go past 3 prints without crashing octoprint at the end of printing.
New Creality 4.2.7 board on order as I'm going to be installing that in this Voxelab Aquila to fix this problem hopefully for good will update later.
2 Likes
Hey - I stumbled across this thread cause I'm having similar issues with my Aquila (G32 chip) also. Actually came across this by googling some of the error lines in my log...
Nevertheless, I did see this issue on the Jyer's Github for the Ender 3v2. From my understanding, the Jyer's Marlin firmware for the Ender 3v2 is really the same as the Alex firmware for the Aquila, with a couple configs changed (ie: the G32 has less memory than the STM32, but is otherwise a direct pinmatch to each other).
Long story short - we might have a firmware issue, instead of an Octoprint issue. But considering the popularity of the Ender 3v2 - i'm surprised there isn't more buzz on forums about this problem we're having.
So I have a update on this and it's been a journey to get there I'll just leave it at that.
Past all the steps I took above I installed the creality board on the Aquila on Sunday and shockingly the errors continued and got worse when I hit cancel on octoprint during print octoprint crashed, when I hit cancel on printer it crashed. I flashed Jyers on the Aquila (Ender 3 v2 version) and for the record it runs but you do need to make some tweaks (won't go into details) to make it work.
Once I found out that the issues continued I started to backtrack from the printer to the pi and looking back I should have done this prior do to the fact that the printer prints perfectly just the octoprint issue mentioned. I replaced my USB cable cover the 5v put with electrical tape and problem went away. It's funny I used a brand new cable same exact type I used on my Ender 3v2 that runs flawlessly but this one was faulty. I put the old motherboard back it did ran protune on the heater from the Jyers menu and as of now ran 6 prints with no issues. Running Alex firmware and I actually went through the source code and it's indentical to Jyers Ender 3V2 version when it comes to the configuration.h files. Like down to ever single code.
So on print 10 or 11 no issues then yesterday I installed a dual extruder (simple setup) just adjuster the e steps for Extruder printed 1 print no issues then this morning printed and then octoprint crashed. I'm not going down rabbit hole just yet but I'll keep eye on. Next step will be check power to PI prehaps. I have the Creality board as a backup so in the rare chance it's the board I'll swap out. After Alex/Jyers firmware edit (minor changes) I did get some thermal runaway errors at start of prints . I did PID autotune and that seemed to correct it but I did have 2 pop ups always durring probing.
Is there anything new in the log file when it crashes?
Nope just as last time
Last command before crash is
octoprint.plugins.octoeverywhere - INFO - RepeatTimer thread exit
Here is a section of it
2021-11-19 08:18:28,414 - octoprint.plugins.action_command_notification - INFO - Got a notification: Les Aquila V1 Ready.
2021-11-19 08:18:28,420 - octoprint.util.comm - INFO - Finished in 6333.881 s.
2021-11-19 08:18:28,423 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Finishing"
2021-11-19 08:18:28,440 - octoprint.printer.standard.job - INFO - Print job done - origin: local, path: CE3PRO_2_Inch_Hollow_Ball.gcode, owner: pi2
2021-11-19 08:18:28,549 - octoprint.util.comm - INFO - Changing monitoring state from "Finishing" to "Operational"
2021-11-19 08:18:28,567 - octoprint.plugins.excluderegion - INFO - Printing stopped: event=PrintDone
2021-11-19 08:18:28,570 - octoprint.plugins.filamentsensorsimplified - INFO - PrintDone: Disabling filament sensor.
2021-11-19 08:18:28,588 - octoprint.plugins.octoeverywhere - INFO - RepeatTimer thread exit
2021-11-19 12:20:46,527 - octoprint.startup - INFO - ******************************************************************************
2021-11-19 12:20:46,530 - octoprint.startup - INFO - Starting OctoPrint 1.7.2
2021-11-19 12:20:46,531 - octoprint.startup - INFO - ******************************************************************************
2021-11-19 12:20:47,218 - octoprint.util.connectivity.connectivity_checker - INFO - Connectivity changed from offline to online
2021-11-19 12:20:47,416 - octoprint.util.connectivity.connectivity_checker - INFO - Connectivity state is currently: online
2021-11-19 12:20:47,417 - octoprint.util.connectivity.connectivity_checker - INFO - Connecting to 1.1.1.1:53 is working
2021-11-19 12:20:47,417 - octoprint.util.connectivity.connectivity_checker - INFO - Resolving octoprint.org is working
2021-11-19 12:20:47,485 - octoprint.plugin.core - INFO - Loading plugins from /home/pi/oprint/lib/python3.7/site-packages/octoprint/plugins, /home/pi/.octoprint/plugins and installed plugin packages...
2021-11-19 12:20:49,613 - octoprint.plugins.errortracking - INFO - Initialized error tracking
2021-11-19 12:20:49,751 - octoprint.plugin.core - INFO - Found 24 plugin(s) providing 24 mixin implementations, 57 hook handlers
2021-11-19 12:20:50,049 - octoprint.server.heartbeat - INFO - Starting server heartbeat, 900.0s interval
2021-11-19 12:20:50,060 - octoprint.server - INFO - Intermediary server started
I'm considering just putting the Creality 4.2.7 board in because my ender has none of these issues the Voxelab prints great and the board is a direct fit. I'll see definitely strange I'm running nearly identical firmware on both machines and this one is having all the issues.
I have to say its unfortunate that no one can help me with this. I first thought this was a cable error but its not, I tried multiple firmwares and issue continues. The printer prints perfect, octoprint works without issues and logs don't tell me anything. The octoprint program is the only thing that crashes after print completes. I forcused on the printer being the issue but there is something that is causing Octoprint to crash like this.
Usually when no one helps it's because we too don't know the answer - some things are not covered by a simple fix unfortunately.
This is a fairly wild stab in the dark, but since you had a filament sensor plugin installed, you could be getting segmentation faults. There's a bit of a problem with these GPIO plugins that causes segfaults. These aren't logged, since the process literally just stops dead in its track, which this seems like it does.
It's a long shot, but make sure you have no GPIO plugins enabled.
As well, if OctoPrint crashes, try and capture the output of sudo service octoprint status and that will show us if it was a segfault or not.
That sounds like a great idea I'll try that I do appreciate it I did plan on disabling all of my plugins that use a gpio just to eliminate that possibility because at this point I'm down to anything plugged into the the raspberry pi . Thanx
I removed everything that was plugged into my GPIO ports I had a relay connected for PSU control had a TP-Link smart plug laying around used that instead and also disconnected my filament sensor for now will most likely connect back up to printer directly if this works. Currently I have about 6 prints and no crashes. I would call this a success and mark solved but I have gone nearly 10 prints before it just started to crash so I'm not celebrating just yet. One thing that makes me feel good is that prior to removing all the GPIO stuff I couldn't have gone more then 2 prints without a crash so we are getting somewhere. Will update in the next few days once I get to about 15 prints without crash.
Sounds promising 
1 Like
15 or so prints no crashes. Those GPIO connectors definitely had a part to play in this. I'm marking it solved. Thank you everyone for your time.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.