I have been looking around and searched on the forums to see if I can find an answer but have been unable to so far.
Astroprint installed on an RPi1 successfully connects to my Anet A8. Controls and uploading files etc all work fine. When I try and print a file I have uploaded locally the machine heats up the bed and extruder and then just homes itself with an idle status on the screen. The part does not print at all. It seems at this time Astroprint loses connectivity with the printer maybe?? However if I cancel the print then everything homes itself again so there is some connectivity.
Any tips will be greatly appreciated as I like the interface better than octopi (working fine on same setup).
This is most likely due to faulty or incompatible start gcode. What did you use to generate the gcode ? Can you post the first 15-20 lines ?
Thanks for the reply Daniel.
I used Cura 2.0.4 to do the gcode.
The code is below up to the printing stage, also this printed fine with octopi.
;FLAVOR:RepRap
;TIME:7916
;Filament used: 3.38542m
;Layer height: 0.1
;Generated with Cura_SteamEngine 2.4.0
M190 S60
M104 S205
M109 S205
;Sliced at: {day} {date} {time}
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 ; Auto Home All AXIS
G29 ; Auto Bed Levelling
G1 Z15.0 F{travel_speed} ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F{travel_speed}
M117 Printing...
Is this the actual gcode uploaded or the start gcode on your cura profile?
This code has variables like {travel_speed} that need to be replaced with actual numbers by the slicer. Our cloud slicer would do that but not the astrobox.
If you try to print a GCODE file with unreplaced variables, it will fail as it’s sent to the printer as-is and the printer won’t understand it.
Only the slicer knows what travel_speed should be based on the slicer profile. It’s possible that octoprint replaces it with some arbitrary value and we might do that in the future but the current AstroBox software doesn’t do that.
The bottom line is that the gcode you pasted is not valid print gcode, it’s perhaps valid start gcode that still needs to be processed by the slicer.
Makes perfect sense as there is start gcode handled by Cura and I would hazard a guess that Octopi has these variables as default somewhere too maybe? (like you suggest)
Cura Start Gcode:
;Sliced at: {day} {date} {time}
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 ; Auto Home All AXIS
G29 ; Auto Bed Levelling
G1 Z15.0 F{travel_speed} ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F{travel_speed}
M117 Printing...
I also changed the start code back to default as I found auto leveling to be more pain than its worth.
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F9000 ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F9000
M117 Printing...
Cool. Let me know if everything works after these changes.
Worked a treat - thanks!!!
1 Like