Not Printing when it says printing

[acousticpunker00]

Did you test the latest release build?

Yes, and the problem still exists.

Bug Description

Just installed the latest N32 firmware on my X2 with the ProUI. I can navigate the UI and bed leveling and PID tuning work just fine. However, when I tell it to print a file, nothing heats up or moves. It just rushes through the status bar in a minute or so and tells me it’s done. What did I miss? Do I need to change anything with my slicer? Sorry if there is a discussion channel somewhere for this that I can’t find.

Printer Model

Voxelab Aquila

Model Type

X2

Your Mainboard

Aquila N32

Other Mainboard Type

No response

Add-ons that could be involved

BLTouch

ProUI?

ProUI

Bed Leveling

BLT - BL Touch Bilinear mesh

Did you include your own configuration files?

• [ ] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Factory firmware as listed in the file for Aquila N32 BLT ProUI with no modifications.

[acousticpunker00]

This was after hitting print on a file. Nothing heated or moved except for the status bar.

[classicrocker883]

If you installed anything from this New Year, please go back to one of the Releases in December. I posted a couple tests which aren't really ready for full release.

however, it appears that the issue maybe from your Start G-code.

take a look in your Slicer, or in the G-code file itself.

you can paste the beginning code before the first layer or the file and maybe I can help.

[acousticpunker00]

My apologies. In all the tutorials I watched before installing the firmware, none of them mentioned changing the start g-code, so I assumed that it worked with the factory g-code for the E3V2 and Aquila. I did finally find the g-code section and I will give the listed start and end g-codes a try. Thank you for your response!

[acousticpunker00]

So the start g-code got the ball rolling and things Start to happen. However, I keep getting a "Bed Temperature Too Low" error and it tells me to shut off the printer. I tried going back to the part of the old g-code that would let things partially warm up before homing, but the error still persists. Why does it think the bed temp is too low? This error occurs as soon as the BLTouch probe touches the bed during the homing process.

Below is the part I changed:

G90 ; use absolute coordinates
M83 ; extruder relative mode
M104 S150 ; set temporary nozzle temp to prevent oozing during homing
M140 S{first_layer_bed_temperature[0]} ; set final bed temp
G4 S30 ; allow partial nozzle warmup
G28 ; home all axis
M104 S[first_layer_temperature] ; set extruder temp
M140 S[first_layer_bed_temperature] ; set bed temp
M190 S[first_layer_bed_temperature] ; wait for bed temp
M109 S[first_layer_temperature] ; wait for extruder temp
M420 S1 Z2; Use a mesh leveling up to 2mm (a valid mesh must be loaded into RAM);

I also tried adding another M190 S[first_layer_bed_temperature] ; wait for bed temp line after the M140 and it still happens.

Any ideas?

[classicrocker883]

you dont really need

M104 S[first_layer_temperature] ; set extruder temp
M140 S[first_layer_bed_temperature] ; set bed temp

if they are right above M190 and M109. these "wait" commands are also "set" commands.

I wonder why it is saying "Bed too low" if it sets and waits for the bed to come up to temp. maybe there is a difference between the first_layer_bed_temperature's, for instance you see one has [0] in it.

how does the result Gcode look, the file which is then created? maybe those numbers aren't correct after its sliced.

but anyway how about a PID tune? thats something you should do at least for the Bed.

[acousticpunker00]

The M104 and M140 were just copied from the github gcode scripts page. It looks like maybe PrusaSlicer is duplicating the limit setting part of the g-code, because I am seeing the M201, M203, M204, and M205 codes in there twice. I can take those out easily enough, but that shouldn't have anything to do with the bed temp.

I see the extra zero in what I pasted in, but in the attached G-Code it looks like PrusaSlicer might convert the values in the [brackets]. I don't see the zero in there at all.

As a side note, or potentially not, is the Marlin (legacy) vs. Marlin 2 setting only relevant for the G-Code preview, or does it need to be changed regardless? (I tried both)

I really appreciate all your help! If there is a discussion channel somewhere I should take this issue instead, please let me know.

Calibration Cube_39m_0.20mm_205C_PLA_ENDER3V2.txt

EDIT: I moved the G28 to before all of the temp commands and that seems to have done it, but that doesn't seem like the right thing to do. Is there somewhere in the firmware settings where a "minimum temperature" is set that would trip the MINTEMP error?

[classicrocker883]

The M104 and M140 were just copied from the github gcode scripts page. It looks like maybe PrusaSlicer is duplicating the limit setting part of the g-code, because I am seeing the M201, M203, M204, and M205 codes in there twice. I can take those out easily enough, but that shouldn't have anything to do with the bed temp.

youre right, those M200+ codes aren't needed and can be omitted.

I see the extra zero in what I pasted in, but in the attached G-Code it looks like PrusaSlicer might convert the values in the [brackets]. I don't see the zero in there at all.

the values in brackets are basically placeholders for the slicer. e.g.: M104 S[first_layer_temperature] the slicer interprets this as (if the temp begins @ 200) - the gcode file should now be M104 S200

As a side note, or potentially not, is the Marlin (legacy) vs. Marlin 2 setting only relevant for the G-Code preview, or does it need to be changed regardless? (I tried both)

it should be Marlin 2

EDIT: I moved the G28 to before all of the temp commands and that seems to have done it, but that doesn't seem like the right thing to do. Is there somewhere in the firmware settings where a "minimum temperature" is set that would trip the MINTEMP error?

well what would cause that error is say you start a print, and it's taking too long for the bed or hotend to heat up.

I think a bad PID tune would also trigger that, basically a PID works by heating, then not heating. if youre familiar with Bang-Bang, this is essentially kind of like that. technically, the heater should heat evenly, like a pulse-width-modulation, which turns on and off the heater faster as to not get too hot too fast.

a bad PID would cause it not to heat fast enough, or if it reaches the right temp, it would shut off and drop below, and cause the error.

besides code related errors, it can be from the heater itself. I would check the wires to be on the safe side. look into replacing the ends that go into the mainboard terminals with ferrules, if that wire gets loose, you can get a bad connection which would cause heating issues and even worse -- cause a fire.

[acousticpunker00]

I have done the PID tuning a couple times, and the bed holds its temperature evenly. The MINTEMP error occurs with the bed at ambient, or at the assigned temperature. I'm not sure what is flagging it as being too low. If Reddit is to be believed, this is a semi-common issue with aftermarket firmwares on Aquila printers. The only "solution" I have found is similar to mine where you just rearrange your start G-Code to move the homing to before the warmup (or add a brief drop to 0 degrees for homing). I guess I'll just keep mine going like that since it seems to be "working", and other than that small hiccup, I love the Pro Firmware and ProUI.

[classicrocker883]

have you tried out the newer release? do you have any issue now?

[acousticpunker00]

I have not had any issues since moving the G28 Home all axis command to before the temperature commands. I also have not tried any of the newer releases. If you think this might correct the issue, I am willing to give it a try, although I am also mildly content to keep my start G-Code the way it is as my "fix" since that seems to be the popular solution.

[classicrocker883]

I think leave however you have the start code arranged. now that I think about it, I thought I was able to Preheat before homing without the error. But that was also a different chip. I'll have to check for myself, maybe I can pinpoint the problem.

as for the new release of this year, yes I would keep up with the updates.

ps. I just realized our Usernames are very similar hahaha

[acousticpunker00]

Thank you for all your help! I'll update to the new firmware soon. Do you know if by any chance it fixes the bug where the progress bar stop counting as soon as the display sleeps? I'll test it, and if not, I can submit a new bug report. Thanks again!

[classicrocker883]

I have not yet tested, the new firmware should work normally since I updated the print timer, but I havent tested that specifically. yes let me know if it does stop counting, a new report is fine.

[acousticpunker00]

I tried the new release and got a bunch of new issues that I’ll need to sort out or go back to December, however I did want to add some insight to this issue. I noticed that when the printer is auto homing, the split second that the probe touches the bed, both the nozzle temp and the bed temp drop into the negatives for a fraction of a second and then bounce back. I don’t know what causes the bounce, but I’m sure that’s why it errors out with a “bed temp too low” error.

[classicrocker883]

I tried the new release and got a bunch of new issues that I’ll need to sort out or go back to December, however I did want to add some insight to this issue. I noticed that when the printer is auto homing, the split second that the probe touches the bed, both the nozzle temp and the bed temp drop into the negatives for a fraction of a second and then bounce back. I don’t know what causes the bounce, but I’m sure that’s why it errors out with a “bed temp too low” error.

im able to make a new release with a couple fixes. what issues would you be having? for why the temps drop could be due to a loose thermistor. check your wires that are both going into the mainboard hotend - even the connectors; sometimes the pins can come loose.

that happening within the firmware is unlikely. I don't think there was a change within the code which would cause such a significant thing like that. I mean, I'll take a look to see if changes made would make something like that happen, but to me as the probe goes down and up sounds more like loose wires. you can also try disabling HS mode (high speed mode) for the probe.

[acousticpunker00]

I’ll take back my issues with the new version. I’m a noob and forgot a few recalibration steps after updating. SORRY!

I think it’s odd that it would drop exactly the same every time, but I’ll be swapping my hot end and thermistor soon, so I can confirm then. EDIT: Actually, considering the fact that Both the bed and nozzle temps drop simultaneously the instant the probe touches, I'm going to say it has nothing to do with hardware and is a firmware behavior.

Also, the timer still doesn’t come back after the screen goes to sleep, so if you’d like me to open a new bug report for that, I can. thanks again for all your help!

[github-actions[bot]]

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.