Default gcode in UM3 Hardware is a Problem for Restarting Prints

[GCode 0]

It seems that the UM3 hardware includes gcode at the very beginning of every print that is outside of the code generated by slicing in Cura. This includes the wipe, the auto leveling and printcore and bed plate heat checks. I would propose that this part of the hardware gcode be put back into the slicer-generated software gcode to improve the machine's versatility. These are the reasons I am having a problem with hardware gcode:

1. Continuing a print after the filament extrusion fails: When extrusion fails but the gcode keeps executing, the machine operator will often discover the failure after many millimeters of Z stepping has been bypassed in the gcode. To restart the print at the correct spot after the filament has been fixed you can compare which spot the object failed at to the layer number in Cura's preview and just delete all the gcode up until that point. But when you try the modified gcode, the wipe and the leveling ruin it because the nozzle comes down to the bed plate and crashes into your half-printed object. This is especially frustrating with long prints that take days to print because it is so important to be able to attempt a restart halfway through the print when it is such a large amount of time. If the default beginning gcode was completely included in the generated Cura code then it could be deleted in these circumstances, allowing continuation of the print.

2. The second reason to keep default startup code in the software gcode instead of hardware is to allow the printer to be more versatile for other purposes than making an object. I want to use my printer to extrude filament in mid-air for testing the quality of new filament materials with only gcode written for extrusion-speed and temperature . For this I want to be able to write my own gcode and skip the preparation steps - because it wastes time and is unnecessary.

 

I don't see why some gcode needs to be hardwired. The exact same gcode could be generated at the beginning of every slice, which is better for modification. And more importantly it is absolutely needed for restarting long prints with filament failure.

 

 

[Dim3nsioneer 521]

While I understand your frustration about not being able to restart a failed print at a specific height there are good arguments against making those routines available as changeable gcode.

First, it's not all gcode. On both UM3 and S5 those routines are written in Python. Most commands do actually send a line of gcode to the motion controller. But in between them there are commands which use different routines and functionalities not on the motion controller but on the Olimex board.

You also have to keep in mind that those two models are not designed for makers but for professionals. Their main request is to have an automated start-print-procedure which cannot be accidentally changed.

If you want to do extrusion tests, I recommend to build a test station maybe based on a printcore with some simple electronics or even a standard printer control board. You may get some ideas from a project to use a printcore on an Ultimaker 2+ by @ultiarjan:

As for the restart of a failed print: This does not happen on a S5 due to the filament sensor. Running out and printing air is UM3 specific. But please be aware that such a runout does not happen at once but starts with an underextrusion which is getting worse. Depending on the size of the print this can go over multiple layers. Restarting such a failed print might result in a very bad print quality around the layer it started to run out. Finding the right layer might also be a bit too tricky for most users. However, a restart after a short power cut would be a great feature (hint, hint) but I guess it's not what you meant.

We know that it is quite unlikely that it will be possible to upgrade an UM3 with the filament sensor from the S5. But there is a community project driven by @foehnsturm going on which puts a filament sensor to an UM2(+):

As you can see, bringing it to the UM3 is an option but requires that Ultimaker releases the source code of the UM3.

[GCode 0]

I don't understand how the startup g code commands could be "accidentally" changed, especially by a supposed professional. I am 3d printing professionally and this is in the way of being professional. When a print fails 2/3 of the way through, which is several days long this is a professional waste of time. As for restarting a print with new code it is actually much easier than you think. The worst that can happen (if you are a professionally skilled) is the restart layer deviates in layer height by like 50 microns, which is either negligible of able to be easily sanded off. I've even done it with the awkward UM3 hardware by cutting off the under-extrusion layers very carefully with an exacto knife, marking where the base of the model touches the bed plate and then removing the model and putting it back precisely where it was after the startup routine during a quickly-timed print pause. But this is so hard and takes so long. The quality wasn't even that bad with the temporary removal of the whole object. I suspect I could make a  near-perfect startup layer if the Ultimaker3 coding wasn't flawed like this. I think its a huge shame these things are hardwired considering that the annoying parts of the startup are merely X/Y/Z and extrusion movements. Pretty short-sighted considering there is no filament sensor