Under 13.12 firmware for UM2... several forum users have reported that when aborting an Ultigcode print, the filament gets rewound to the original E=0 position from the start of the print.

I have tested it myself (with both Mac and Windows format gcode files) and can confirm the behavior.

It seems that for some reason the G92 E%i line in the abort routine is having no effect, although having looked at it quite a bit, I couldn't see why it wouldn't.

Material properties become messed up after custom entries are added.
Looks like the current changes are stored to a different, wrong place...

On my UM2, My extruder fan is always turning (I mean, not the lateral 12V fans, but the center 5V one), why don't it stops when not printing?

It's my understanding that M0 and M1 are supposed to stop moves, and wait for a prompt on the controller. M0 is used by the Pause at Height plugin, and while the head moves to the specified park position from the plugin, it then immediately resumes printing with no interaction on the controller.

The voltage shouldn't drop below a threshold. The current Mainboards can measure the voltage. If it's on a battery, it should trigger an alarm.

This will make walking around with batteries a lot easier. Does anyone think hot-swapping could somehow be possible? Just hook up a second battery in parallel?

Yesterday I try to change the material after aborting. but the extruder does not work after heating.Could anyone help me?

Hi,
I installed Cura 15.01-RC8 and uploaded the default firmware to an Ultimaker 2. Changing the filament doesn't work properly. The stepper motor that feeds the material goes bonkers:

Removal: https://www.youtube.com/watch?v=1_Ut64OuOzs
Insertion: https://www.youtube.com/watch?v=D8_MJxpzQIc

I switched back to the firmware that is shipped with cura 14.12.1 and the behaviour disappeared immediately.

gcode from SD cards is parsed differently, depending on whether it was created on windows or mac.

Windows uses \r\n to delimit lines. So, in Marlin_main.cpp at line 637, the \r gets treated as the end of the command, and it is buffered. The code then loops, and reads the \n next. This activates the 'empty line' code at line 658, and the parser 'returns', going on to process the gcode in the line it just buffered, monitor timers, etc, before returning to read and buffer the next line in the next pass through the main loop.

On the other hand, on a Mac, only \n is used as a delimiter. Therefore, the 'empty line' code is almost never triggered, and after reading one command, the code loops and reads and buffers the next, and the next until the buffer is full. Only then does it go and parse and act on the gcode in the first line that was read.

As a result, gcode from a Mac will typically keep the buffer full, while gcode from a pc will keep just 1 or 0 lines in the buffer.

I think that the intent was probably to put a 'continue' in the empty line case, rather than a return.

This looks to be worked around in the latest source by flushing the command buffer, but I think that has some issues too...

On an abort, it's ok to flush the command buffer first. And it should probably flush the planner buffer too, so that printing stops immediately.

But there is also some code in there to clean up when EOF is reached. However, that code gets triggered when the EOF gets detected while reading into the command buffer. When in fact, there may still be buffered commands waiting to be parsed. That then interacts with the LCD UI code for 'check print finished', and it all just seems very tangled.

Since the 'get commands' code is only called when there is at least 1 slot in the buffer, I think a better approach for 'end of file' would be to add a single new gcode command to the buffer which later gets parsed to mean 'we're done, sync up the planner buffer, and then run the end gcode'. (which would only be added in the case that we're using ultigcode, and expecting the source file to not take care of it). This would have the advantage of keeping the buffering and parsing logic separate, rather than entwining them quite as much.

Similarly, for 'Abort', just adding a single command to the command buffer, and then allowing the process_commands logic to handle it might be a better option. Again, decoupling the UI and operational logic as much as possible.

Another option that might be considered is adding a second 'system use' command buffer that only the system can write to. That could have a flag associated with it, that indicates how to treat the buffer: 'run the system buffer when the user buffer empties' or 'ignore and empty the user buffer, and run the system buffer immediately' or 'run the system buffer commands first, but then go carry on with whatever is in the user buffer' so that the system buffer can play different roles as needed. Again that would avoid having the buffering, parsing and UI code needing to tromp all over one another quite as much.

The SD file utils seem to have some problems, btw. One subtle issue seems to be that it's a bit vague whether sdpos is the last byte read, or the next byte to be read. The lower level cur_position is the value of the next byte to be read. But for instance, in card.get() sdpos is set before the character is then read and returned - making sdpos the last character read. But then in other routines like setIndex, sdpos is set to the offset of the next character to be read. So, for instance in the error reset code in get_commands, it actually jumps back to the last character of the previous line rather than the first character of the next line. Since that's generally a newline or carriage return, it probably doesn't make much material difference, but it's wrong, as best I can tell.

Wake up with your Ultimaker, go to bed with your Ultimaker... Fade in lights at a certain time.

Possible issues:

• Clock drift needs syncing?
• Clock needs sync
• Numeric Input

So this is why it's in the Icebox, but still the idea is cool.

A couple of people on the forums have reported that if you can make it into the 'Move Material' menu while the bed is still homing from an aborted print, the bed will start to rise until it crashes into the print head (and keeps going).

http://umforum.ultimaker.com/index.php?/topic/3919-ultimaker-2-firmware-bug-causes-machine-crash/

Hi there,
While working with the UM2 I noticed that it might be nice to have a seperate command for loading and for unloading material. If I unload the material, shut down the machine (for example for transporting the machine) then turn on the machine and want to load material, I first have to go through the load sequence.
Thanks!
Cheers,
Bas

here's the error message:
" Wire\utility\twi.c.o: In function __vector_39': C:\Program Files (x86)\Arduino\libraries\Wire\utility/twi.c:364: multiple definition of__vector_39'
UltiLCD2_low_lib.cpp.o:C:\Users\USERNAME\AppData\Local\Temp\build1949403233647085642.tmp/UltiLCD2_low_lib.cpp:181: first defined here
c:/program files (x86)/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions "
How to solve it? Thanks.

Over on the reprap gcode wiki, it is states that M142 is used for Holding Pressure: http://reprap.org/wiki/G-code#M142:_Holding_Pressure

For RGB coloring, M420 is already reserved: http://reprap.org/wiki/G-code#M420:_Set_RGB_Colors_as_PWM
For example M420 R255 E255 B255 (all caps as all gcodes), however W is missing here, which we can extend the current definition with.

The only weirdness here is that E is used rather then G, as G is normally used for regular GCodes. I'm not educated enough to claim to know if this actually holds true.

The Makefile references arduino as the programmer to be used, but this should be wiring (because of DTR/RTS toggeling)

Also the INSTALL_DIR, VERSION and AVRDUDE_FLAGS parameters will always have to be tuned to the specific platform and OS in use, defaulting to somewhat more logical location matching common setup.

This should by no means will replace _do_make.bat used by certain platforms to override this variables anyway

I've developed a device to ensure that filament is constantly flowing into the machine properly. If the filament stops flowing for any reason (i.e. empty, clogged, jammed) the print will go into a pause allowing the user to fix the filament issue and then continue the print.

The change that is needed is to use a GPIO as a digital input that is pulled high. When my device alarms, it pulls that line low (to about .5V). Also a 5V and 0V connection are required, but those are not related to firmware.

I'm a EE and have designed this device to protect the GPIO on the motherboard against shorting to a rail.

I'd love it if marlin could support this device. I think it would save a lot of potential failed prints.

Here's the device:
https://sites.google.com/site/tunelldev/home/filamentmonitor
https://www.youmagine.com/designs/filament-monitor

There should be a way to get out of the menu selection without having to go through the entire leveling process.

Sometime (about 1/5 print) the Z init fails and is too near of the plate ,resulting of a first layer failure (and plate damage...)

Maybe the Z homing is not accurate enough?

Changing the fan speed during print only last until the next layer is starts.
In Cura the "fan full on height" is set to 3 mm. during print we wanted to increase the fan speed bevore reaching 3mm height. The manually set speed is only used when you do not left this menu.

For me the manual set one should overwrite G-Code ones.

(If this is not the right Place for UM2 firmware issues, please contact me)

. If it's connected it should show the signal strength.

• Designing of several icons: Wifi connection possible, AP mode, Connected Strong, Connected Medium, Connected Weak (signal), Wifi unavailable (crossed?)
• We should be able to display a Wifi pictogram in the corner of the screen
• The icon should be changed through status codes coming from the Linux-board

If flow is set to 50% then you do a filament change it only moves half as far as normal.

Person who mentioned this bug thinks it might occur on retractions also (but seems unlikely):
And retractions if set to 4.5mm may actually be half that. Similarly with flows greater than 100%. Of course this applies to G10, G11 only. Retractions done with G0 or G1 commands are supposed to be multiplied by flow rate I would think.

http://umforum.ultimaker.com/index.php?/topic/5391-retraction-length-vs-material-flow/#entry47708

I spent a few days looking for this function and didn't exactly find what I needed. Thank you for your reply.

when looking for this function
SIGNAL(TWI_vect)" function from "libraries/Wire/utility/twi.c

I looked here C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire\twi.c
and found this function.

I deleted this function and was not able to compile still. Is there anything else I should be aware of.
Is it ok that I am working on WINDOWS 7. I can try working with the platform you suggest.

ISR(TWI_vect)
{
switch(TW_STATUS){
// All Master
case TW_START: // sent start condition
case TW_REP_START: // sent repeated start condition
// copy device address and r/w bit to output register and ack
TWDR = twi_slarw;
twi_reply(1);
break;

// Master Transmitter
case TW_MT_SLA_ACK: // slave receiver acked address
case TW_MT_DATA_ACK: // slave receiver acked data
// if there is data to send, send it, otherwise stop
if(twi_masterBufferIndex < twi_masterBufferLength){
// copy data to output register and ack
TWDR = twi_masterBuffer[twi_masterBufferIndex++];
twi_reply(1);
}else{
if (twi_sendStop)
twi_stop();
else {
twi_inRepStart = true; // we're gonna send the START
// don't enable the interrupt. We'll generate the start, but we
// avoid handling the interrupt until we're in the next transaction,
// at the point where we would normally issue the start.
TWCR = _BV(TWINT) | _BV(TWSTA)| _BV(TWEN) ;
twi_state = TWI_READY;
}
}
break;
case TW_MT_SLA_NACK: // address sent, nack received
twi_error = TW_MT_SLA_NACK;
twi_stop();
break;
case TW_MT_DATA_NACK: // data sent, nack received
twi_error = TW_MT_DATA_NACK;
twi_stop();
break;
case TW_MT_ARB_LOST: // lost bus arbitration
twi_error = TW_MT_ARB_LOST;
twi_releaseBus();
break;

// Master Receiver
case TW_MR_DATA_ACK: // data received, ack sent
// put byte into buffer
twi_masterBuffer[twi_masterBufferIndex++] = TWDR;
case TW_MR_SLA_ACK: // address sent, ack received
// ack if more bytes are expected, otherwise nack
if(twi_masterBufferIndex < twi_masterBufferLength){
twi_reply(1);
}else{
twi_reply(0);
}
break;
case TW_MR_DATA_NACK: // data received, nack sent
// put final byte into buffer
twi_masterBuffer[twi_masterBufferIndex++] = TWDR;
if (twi_sendStop)
twi_stop();
else {
twi_inRepStart = true; // we're gonna send the START
// don't enable the interrupt. We'll generate the start, but we
// avoid handling the interrupt until we're in the next transaction,
// at the point where we would normally issue the start.
TWCR = _BV(TWINT) | _BV(TWSTA)| _BV(TWEN) ;
twi_state = TWI_READY;
}
break;
case TW_MR_SLA_NACK: // address sent, nack received
twi_stop();
break;
// TW_MR_ARB_LOST handled by TW_MT_ARB_LOST case

// Slave Receiver
case TW_SR_SLA_ACK: // addressed, returned ack
case TW_SR_GCALL_ACK: // addressed generally, returned ack
case TW_SR_ARB_LOST_SLA_ACK: // lost arbitration, returned ack
case TW_SR_ARB_LOST_GCALL_ACK: // lost arbitration, returned ack
// enter slave receiver mode
twi_state = TWI_SRX;
// indicate that rx buffer can be overwritten and ack
twi_rxBufferIndex = 0;
twi_reply(1);
break;
case TW_SR_DATA_ACK: // data received, returned ack
case TW_SR_GCALL_DATA_ACK: // data received generally, returned ack
// if there is still room in the rx buffer
if(twi_rxBufferIndex < TWI_BUFFER_LENGTH){
// put byte in buffer and ack
twi_rxBuffer[twi_rxBufferIndex++] = TWDR;
twi_reply(1);
}else{
// otherwise nack
twi_reply(0);
}
break;
case TW_SR_STOP: // stop or repeated start condition received
// put a null char after data if there's room
if(twi_rxBufferIndex < TWI_BUFFER_LENGTH){
twi_rxBuffer[twi_rxBufferIndex] = '\0';
}
// sends ack and stops interface for clock stretching
twi_stop();
// callback to user defined callback
twi_onSlaveReceive(twi_rxBuffer, twi_rxBufferIndex);
// since we submit rx buffer to "wire" library, we can reset it
twi_rxBufferIndex = 0;
// ack future responses and leave slave receiver state
twi_releaseBus();
break;
case TW_SR_DATA_NACK: // data received, returned nack
case TW_SR_GCALL_DATA_NACK: // data received generally, returned nack
// nack back at master
twi_reply(0);
break;

// Slave Transmitter
case TW_ST_SLA_ACK: // addressed, returned ack
case TW_ST_ARB_LOST_SLA_ACK: // arbitration lost, returned ack
// enter slave transmitter mode
twi_state = TWI_STX;
// ready the tx buffer index for iteration
twi_txBufferIndex = 0;
// set tx buffer length to be zero, to verify if user changes it
twi_txBufferLength = 0;
// request for txBuffer to be filled and length to be set
// note: user must call twi_transmit(bytes, length) to do this
twi_onSlaveTransmit();
// if they didn't change buffer & length, initialize it
if(0 == twi_txBufferLength){
twi_txBufferLength = 1;
twi_txBuffer[0] = 0x00;
}
// transmit first byte from buffer, fall
case TW_ST_DATA_ACK: // byte sent, ack returned
// copy data to output register
TWDR = twi_txBuffer[twi_txBufferIndex++];
// if there is more to send, ack, otherwise nack
if(twi_txBufferIndex < twi_txBufferLength){
twi_reply(1);
}else{
twi_reply(0);
}
break;
case TW_ST_DATA_NACK: // received nack, we are done
case TW_ST_LAST_DATA: // received ack, but we are done already!
// ack future responses
twi_reply(1);
// leave slave receiver state
twi_state = TWI_READY;
break;

// All
case TW_NO_INFO: // no state information
break;
case TW_BUS_ERROR: // bus error, illegal stop/start
twi_error = TW_BUS_ERROR;
twi_stop();
break;
}
}

I noticed that the X-Y-motor stays powered indefinitely after leveling the buildplate and after running "Home Head".
I don't know if it is considered a bug or a feature but it seems unnecessary to keep them powered.

Customized material settings imported from the SD card disappears from the UM2 internal memory after power cycling in the 15.01 firmware.
If a custom material was selected, the printer will return to stock PLA settings when power cycled.

REMOVED

I selected board #7 and REPRAP_DISCOUNT_SMART_CONTROLLER for the LCD
and it give me this error:

ConfigurationStore.cpp: In function 'void Config_ResetDefault()':
ConfigurationStore.cpp:288: error: 'motor_current_setting' was not declared in this scope

A couple of users (one for me, one for the Swedish support group) have reported printers that previosuly worked fine but then immediately refuse to turn on, after upgrading to the firmware that came with Cura 15.02. Both gave 'Error - Stopped Temp Sensor' errors.

In both cases, the behavior continued after downgrading to firmware in Cura 14.12, but went away when they downgraded to firmware from 14.09.

At least one of these users went through the process a couple of times, and was able to replicate it.

Arduino: 1.6.4 (Windows 7), Board: "Arduino Mega or Mega 2560, ATmega2560 (Mega 2560)"

Wire\utility\twi.c.o: In function __vector_39': C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire\utility/twi.c:364: multiple definition of__vector_39'
UltiLCD2_low_lib.cpp.o:C:\Users\NICHOL~1\AppData\Local\Temp\build6992659436616663863.tmp/UltiLCD2_low_lib.cpp:184: first defined here
c:/program files (x86)/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions
collect2.exe: error: ld returned 1 exit status
Error compiling.

This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.

In the Ultimaker 2 menu structure, you can select ABS as material.
From MATERIAL->SETTINGS->ABS
The temperature is then set to 280C.

However, the firmware seems to have a limit (I'm guessing at 260C since that is the official highest in specifications in User Manual) whenever heating the printhead.

So when you do MATERIAL->CHANGE it first brings up:
"Heating printhead for material removal"
as it comes up in temperature (to 260C I guess)

it eventually stops with an:
"ERROR - STOPPED Temp sensor contact [email protected]"

I'm guessing this is simply about changing the ABS temperature to a lower value?

(It would of course be extremely useful to be able to add other materials and also change temperatures for both ABS and PLA)

A mode for photography and demos, selectable in the advanced menu

• Allowing you to constantly see an Ultimaker logo with your own text, e.g. from display.txt (e.g. to display www.engadget.com under the logo).
• Allowing you to set the RGB colors of the rotation dial and the brightness of the backlight.

Hello,

The following line:

#define DEFAULT_AXIS_STEPS_PER_UNIT   {80.0,80.0,200,282}  // default steps per unit for ultimaker2

Imply that there is 282 steps per mm on the extruder gear, right?
It is a 1.8° stepper motor with 1/16 microstepping, still right?

Which means that there is 3200 steps (200*16) in a full revolution. So:

3200 / 282 = 2 * pi * r

Where r is the radius of the drive gear. Thus:

r = 3200 / (282 * 2 * pi)
r = 1.8 mm

Where am I wrong? I guess the drive gear is really bigger than that

If you pause a print and abort it in the paused mode, the platform and print head remains in the paused state.

If you now go to the Advanced-menu, "lower platform" and "home head" will not respond and if you select "move material", something strange will happen.

The situation can be recovered by selecting the print menu instead, the head and platform will then home.

I was trying to confirm that I would get "unknown command" for M200, but...

SENT: M200 S0.0
RECEIVED: ok
SENT: M1024
RECEIVED: ok
SENT: M9999
RECEIVED: ok
SENT: M99997654321
SENT: M99997654321
SENT: M999976
SENT: M99999
SENT: M9999
SENT: G28

The firmware went out to lunch after I entered M99997654321. It eventually stopped responding altogether (which is to say I couldn't enter any further commands).

Then, after I restarted the printer and reconnected, I entered MGOBBLEDYGOOK and the nozzle moved all the way forward until it collided with the front of the printer!

The reason I think this is an issue that should be fixed is:

1. The printer should not allow itself to be damaged due to bad input.
2. I suspect this is part of the problem with USB printing. That is, if any part of communication fails, the firmware can break utterly.

I understand that garbage in means garbage out, but the firmware should validate its input before executing it, otherwise, printer damaged. :(

Hey guys,

I just recognize that Cura 14.07 (latest official Version and Firmware update) has some problems if the job was canceled.

I just pressed cancel for a job with very long edges. I know that the printing will stop if the printing Que of 20 "walks" is finished.
My problem is that during the "cancel is in progress" screen the nozzle is already cooling down and feeder is pushing also.
I used ABS and the temperature was very fast too low for printing but the Que wasn't empty and the feeder did not stop pushing.

I can think the best solution is to wait until the Que is empty before the nozzle is turned off. Or maybe it is also possible to stop the feeder if the job was canceled.

Greetings
Killerregenwurm

Would it be possible to change the onscreen instructions to remind users which way to turn the screws to move the bed? Given the way it's assembled, it's not really obvious to me which way they turn just by looking at it, and it took me ages to remember that 'right is NOT tight'. Instructions should be something like 'Turn front of screw to the left to reduce the gap between bed and nozzle'. Talking in terms of clockwise and anti-clockwise doesn't help much, because it depends whether you're looking up at the screw or down on it. Otherwise it becomes a bit frustrating, having to turn the screw further than you really wanted, then wait for it to settle, and then see whether it made the problem better or worse.

Setting the flow rate below 100% results in the feeder motor running more or less on/off.
By this I mean that it nearly stops extruding on sections where the head is changing direction often and the flow should just be reduced.
Check this topic: http://umforum.ultimaker.com/index.php?/topic/7764-underextrusion-when-flow-is-set-below-100/?p=72702

Hey, I tried compiling and running the MarlinSimulator a bunch of times, there are some issues related to:

1. SDL on Mac OS X
2. Compilation fails with Clang.

Maybe some small description on how to compile the simulator would be useful. I still could not get it to work.

The "M20" command uses this function to list all files on the sdcard.
The variable "path" is defined as

char path[13*2];

...but it concatenates up to 10 directory names in this buffer during the recursive calls (MAX_DIR_DEPTH):

strcat(path,prepend);

See:
cardreader.cpp - lines 64 to 89

• Print speed menu heeft geen "Return" zoals temperature. Allemaal hetzelfde (met Return? Ook consistent alles met hoofdletters en geen "Back" en "Return" door elkaar.
• Set point in groot font weergeven, de current temp weergeven als: "Current temp: 123 C"
• Add option to the advanced menu to insert filament by rotating the dial in the front. Should heat up to custom temp (configurable) and then allow you to decide how far to retract. If the filament loading and unloading is foolproof, this may not be required anymore... so we can also focus on that.

First run wizard:

• Teksten naar 1e persoon. De Ultimaker mag een persoonlijkheid hebben :)
• Now your Ultimaker knows what kind of material it has and how to use this -> "Thanks! Now I know what material I'm working with and how to use it."

Arduino version: 1.6.5
OS: OS X Yosemite - Version 10.10.1
Board: Arduino Mega or Mega 2560
Processor: Atmega2560 (Mega 2560)

Removed function
ISR(TWI_vect)
from
\hardware\arduino\avr\libraries\Wire\twi.c

IDE output
Sketch uses 116,414 bytes (45%) of program storage space. Maximum is 253,952 bytes.
Global variables use 6,314 bytes (77%) of dynamic memory, leaving 1,878 bytes for local variables. Maximum is 8,192 bytes.
Low memory available, stability problems may occur.

After leveling the bed, the first run wizard moves the head front and center to await filament loading; it moves too far forward, and bangs into the front edge of the frame.

This still happens in the 14.02 firmware.

If my github client speaks the truth, it looks like the 13.12 tag on UM2Marlin got applied a couple of commits early - prior to the buffer-emptying fix. Please can that get updated?

Write identifier file upon SD-card entry or upon start

This can be used by Cura to trigger a question:
"Would you like to switch to the Ultimaker Original profile?"
or
"Would you like to switch to the Ultimaker 2 profile?".

See my observations in this forum thread:

http://umforum.ultimaker.com/index.php?/topic/5453-ultimaker2-too-high-feed-rate-at-first-feeder-movement-after-print-start/

c1e1060 added the electronics test but the Makefile doesn't build the .o causing the linker to fail.

The bed leveling wizard puts the nozzle right behind the front right glass clip. On my printer, the central, horizontal part of the fan shroud is extremely close to catching on the raised back edge of the clip when the head is in that position. Also, because the nozzle is so close to the clip, it is obscured by it, making it very hard to see the clearance between nozzle and bed, and awkward to try to slide a piece of paper in to use as a feeler gauge. It would be better to position it a couple of cm to the left, and back a few more mm, so that it's easier to see what is going on.

When an M42 is called in a marlin-lite equipped board, the board fails to respond and the watchdog timer responds after a while.

I just received my UM2 and already badly need to make some modifications ;)

As seen here and now, is the current code configuration directly usable
in an UM2?

in Cura the fan speed is set to 100% above layer 3.
In the Gcode i can see following lines:

;LAYER:3
M106 S255

The Ultimaker 2 in the Tune menu says "Fan Speed: 49%"

It is possible to change the Fan Speed to 100%, and the speed of the fan changes noticeable.

I would like to comment this new change in UltiLCD2_menu_print.cpp:

static void doStartPrint()
{
  plan_set_e_position(0);
  current_position[Z_AXIS] = 20.0;
  plan_buffer_line(...);

...

Imho, this should be done in the G-code.

The poor machine itself has absolutely no knowledge about what is going to happen.
Yes, maybe we're extruding hot filament at Z0.1, creating some cool, printed stuff.
But maybe someone (...) attached a syringe paste extruder or a freakin' laser there, moving straight into the platform...

Although my UM2 is running in "UltiGCode mode", I always had these few extra lines
built-in right from my UM2 start (re-enabled start/end G-Code panel in lastes
Cura versions):

G01 F6000 X120
G01 F3000 Z50
G01 F50 E75
G92 E0

A standard setup, which I have been using for years now, on almost every printer.
This does exactly the same (In addition, the E75 step also removes all the old
plastics, lacking any plasticizer, but this is another story).

Having the "print" (or freakin' laser (#yeah)) preparations in the G-code just "feels" better, imho...