Hello, new user here with a small problem.

Hello, new user here with a small problem.

I rencently installed GCodePrintr on an old Trekstor tablet to use as an interface with my homebuilt CoreXY printer. I chose Other RAMPS as my printer “type”. The printer runs latest Marlin on Arduino/RAMPS-combo and connects via USB. I use Slic3r for slicing.

The problem is that after the print finishes and my ending G-code executes it starts to home Z-axis when it should turn of the motors. I want the Z-axis to move to Z.max (almost) and stay there.

Here is my ending G-code:
M104 S0 ; turn off extruder temperature
M140 S0 ; turn off bed temperature
M107 ; fan off
G28 X Y ; home X Y
G1 Z210 ; raise Z 210mm
M84 ; disable motors

I have not had this problem before starting to use GCodePrintr (printed from computer). I have looked for settings in the App but see non that explains this. Can anyone help me fix this?

Best regards / Erik

Hi Erik, this sounds strange. There is an option to home X/Y after finish, but not Z. I’ll try your ending gcode to see if I can reproduce the problem. In the meantime you might want to enable debug logging and see if the console shows anything helpful.

Thank you for the reply. I find it strange too. I will try debug and see if anything comes up.

I tried your ending gcode and it works fine for me. No Z-homing at the end. Once you have the debug output please send me the console output through the App (console -> send email). Thanks

Hello Mathias, thank you for your reply. It seems I was a bit to fast when describing the problem. It actually does not home Z. It restarts the print.

When I saw it starting to move Z against 0 I stopped the print (fear of crashing) and posted here. After some more testruns I now see it restarts and that is why it homes Z (wich is correct) but still a problem.

Any idea why it restarts the print? I have been uploding files via the web-interface. It says something like “added to print que” Could this have something to do with it? That it moves to the next file in the que?

Sorry for being to hasty with my first post and thank you again for helping me out!

@Erik_Edelbro_Jakobss no worries. Its good to know that you used the web interface to upload. I could imagine that hitting the upload button twice or somthing like that could cause such a problem. I will try to recreate the problem. Which version of the app are you using ?

@Erik_Edelbro_Jakobss I found the problem. When uploading a file through the web interface it will be added to the queue, but if you start the print over the tablet UI it will add it to the queue again. (it will not happen when starting the printer over web interface too). I will work on a fix and publish a new version soon.

Ah, fantastic! That must be what is causing this. Now I know how to adress it until a fix comes out. I am very impressed with your support for this app!

Is there somewhere I can see/manage whats in the queue? When I add a file via the web interface it just says added to print queue in the command lines but doesnt show up anywhere as far is I can tell.

Allso; shouldnt there be an option to either proceed with the queue automatically or that you have to manually start the next print in queue (it could load and all but need a manual “start-command”. To avoid the next print crashing into the old if it hasnt been removed yet.

@Erik_Edelbro_Jakobss the queue is just for queuing the gcode lines. It is not supposed to queue multiple models. The fix will make sure that there is only one model in the queue at any time.

Ok, then I understand :slightly_smiling_face: I have heard of printers that auto-remove a print from the bed and start a new one but it’s a rare feature so it seemed odd to have a queue function as standard. But I see now that was not the case :hugs: