Encountered two major bugs when attempting to print with custom settings:
Fans not turning on during print…producing poor quality prints, especially on slight overhangs.
Custom end g-code not executing. Heated bed staying on and no post-print homing, for example.
Any idea why this is happening?
Well, it’s a bit too early to speculate whether these are AstroPrint/Astrobox related bugs or if it is caused by your firmware/printer.
Speaking of which, what kind of Printer are you using?
On your custom slicer settings, which settings did you change?
Also, any screenshots or pictures of your prints (along with the actual link to the STL) can also help 
Let me know!
Rostock Max V2 running Repetier FW. Same config was working fine on MatterControl + OctoPrint. Switching over to AstroPrint disabled the fans and end g-code.
Cooling settings:
Layer fan should spin up at 0.5 mm but doesn’t turn on at all during print (and there is no way to manually switch it on once printing has begun…annoying!).
End g-code is:
M104 S0
M140 S0
G91
G1 Z10.0 E-5. F8000
G90
G92 E0
G28
What actually happens is the hotend switches off, bed stays on, and no homing.
FYI…same behavior on a Kossel mini, RepRap Mendel and Robo3D running Marlin and a LulzBot Mini running stock FW. Seriously doubt the issue is the printers/fw as they were ALL running fine on MC + OctoPrint.
I believe I am seeing the same problem with the fans in code as well
Is this when you create a custom settings profile and then use it or does it happen when you just use the advanced settings dialog for a one off change ?
As a data point…
I use almost the same end code as “Fab_Lab_El_Paso”
Mine works fine…
I would suggest he look at the terminal window when his print completes.
My bet is that he will see and endless parade of resend requests.
If that is the case then the issue seems to be what I mentioned in another thread.
That is that astrobox switches from including line numbers to not including them at some point
upon the termination or completion of a print…
Recent releases of Repetier FW fail when this happens as it now assumes that if you have
a line number once you will always have a line number…while that may be true durning a print
it seems obvious at some point line numbers will stop once the print is done and you are sending
simple cleanup or manual movement commands.
The solution I use is to tweak Repetier as I mention in a previous thread.
Check gcode.cpp (around line 244… it moves in each release)
} else if(lastLineNumber) { // once line number always line number!
if(Printer::debugErrors())
{
Com::printErrorFLN(PSTR("Missing linenumber"));
}
requestResend();
return;
}
delete the complete else part if you want the firmware to accept mixed commands with/without line numbers.
EDIT: I wanted to add that this change in Repetier that requires line numbers if a line number was ever used, was in response to some other problem (I am not sure what that problem was) so removing this code may cause some other issue however I haven’t seen it. I think a better solution (although I am loath to suggest it, as it seems a little kudgy) would be for astrobox to simply prepend line numbers to all lines…I am not sure the firmwares check or care about line number sequence so maybe just putting N0 in front of any line that doesn’t start with Nx would but sufficient and would allow use of current Repetier firmware without possible consequneces.
Saved custom slicer settings. Haven’t tried for one offs.
I can’t reproduce this. Would you be able to see if the GCODE generated by AstroPrint is valid? Look for M106 commands In your GCODE and also look in the end of the file to see if the expected end GCODE is there.
There might other issues while sending the GCODE to your printer but, at least in my tests, the generated GCODE is taking into account end codes and fan settings.
In downloaded G-Code there are no M106 commands included. End G-Code looks fine but not executing.