Daid

Currently not directly possible. There is a work-around. You can add a line with "T1" on the first line of the start code, and enable the M109 line. This will switch all actions to the 2nd extruder before doing anything.

Interference on your SD card signals will be the main problem.

Make that 2 more words: 1.75mm

Yes it is. Best would be to contact support trough the ticketing system. Holy shit. That's bad. Note that we did some extensive testing on this area. First off, when I finally put my eyes on the firmware over a year ago, I fixed a lot of safety features. So the firmware is already better at detecting problems. But no amount of firmware will protect you against all problems. Next, our power-supply protects against short-circuits, and will shut off. So you can never introduce more then 220W of power in the UM2. (Or 120W in the UM Original) Next, the UM2 hotend, if you just keep heating it, nothing will melt. It will stay in 1 piece. The teflon will deform, and it will smell a bit, but nothing starts to burn. We tested this by leaving the heater just wired to 24V for a day. (This is an important change from the UM Original, where the hotend can melt the Peek and drop down on the printer bed) The heated bed cannot reach more then 110-120C. That's a simple one. The electronics has room for extra safety measures (which completely can switch off the heaters&motors), but we didn't implement those yet.

The comment that I put there is actually wrong. G28 Z0 means "home Z", after that the UM Original had the nozzle on the bed, but on the UM2 the bed is at the bottom then. The UM2 does not really have "start gcode", the procedure to start a print is coded and does a few things special. But it comes down to: G28 G1 F12000 X5 Y10 M190 S{bed_temperature} M109 S{print_temperature} G92 E-??? G1 F??? E0 G92 E-??? G1 F??? E0 Which is, home, put nozzle above bed, heat-up, reverse end-of-print retraction, slowly prime nozzle.

Have you lowered the acceleration in firmware? Jerky movement has little to do with Cura, and more with firmware, as that handles the acceleration.

Compare with: That's the lever that people are talking about.

Printer? 3D Model? USB or SD printing?

250k is best, but SD printing is still better.

The power supplies are from meanwell, they take their supplies quite seriously, also on a safety standard. We tried everything to get them "destroyed", nothing worked. We did have 1 bad supply (in about 100) which died from a short-circuit, but it didn't do anything else then that. It just stopped working. (We tested a lot of the UM2 supplies on short circuit protection after that, never managed to destroy one after that single one) There are 2 possible sources for the noise, one could be bad contact from the cable. Which is no real worry, but could switch off your printer unexpectedly. Another is the fact that it's a switching power supply, those emit frequencies, sometimes you can hear those frequencies.

Those advanced GCodes features are not supported in our firmware. (Due to memory constrains) This is a list of the commands supported and their meaning: https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/Marlin_main.cpp#L59

You don't need to do that. Movement is done in the same way as mills. Z+ is "head up" (thus, bed down on the UM) But I also do not recommend turning the Ultimaker into an CNC mill. A CNC mill needs to "catch" the vibrations of the tool hitting the object. And the Ultimaker gantry is not really suited for that. You rather look into the Mantis mill. It's easy and cheap to construct.

And that's without counting for acceleration, which makes the whole thing a lot more difficult.

Depends on the machine, see the topic about extrusion tests. Most UM2 machines reach about 8mm^3/s and the UM Original seems to reach 10mm^3/s

I think your dampers are only partially hiding the backlash, and only hiding it for "longer strokes" as you can clearly see that the infill and inner square do not connect in the top one.

Might be too late. But this is exactly why there is this eject button in Cura. I took a better look at your photo. And what's actually happening, is that a part of the GCode is skipped. This can have all kinds of reasons, including an incomplete write of the GCode on the card. However, it could also mean your card is corrupted. Without safely ejecting the card, Cura cannot know if the GCode is actually completely physically on the card. It could still be writing to the card. If you pull out the card then, the GCode file will be incomplete (and most likely corrupt). BUT, even worse pulling out an SD card during writing to it can permanently corrupt it. Nothing can fix it, formatting does not help when this happens. Internal logic in the card is corrupt. I do recommend formatting the card before the next use, as it can also be filesystem corruption, which can be fixed by a format. After that, always, always safely eject. I did tons of testing on SD cards for my previous job. No SD card we tried was safe from this corruption, which resulted in SD cards being unfit for what we wanted to do. Testing for permanent corruption is hard, as the corruption does not stay in the same space on the card, it moves around causing all kinds of possible problems.

We don't think in RPM. We think in mm/s, or even better, mm^3/s.

Those circles are quite square. And your infill is attaching to the wall at some points, while being completely lose at others. So, still backlash/play. Sorry. Dampers won't do you good. You need stiffness, not springiness.

Do you always safely eject the SD card?

We notice everything. We are the borg. (sorry, but Cura is developed by a really small team. Most of the work is done by me only) In the very old (skeinforge based) code, the first layer of support was actually printed thicker to get a better adhesion to the bed.

It's still unclear to me what you have tested and what not.

:sad: still no machine photos.

Odd. Can you send me your 3D model and exact settings used to d.braam@ultimaker.com (I keep the model confidential and only use it to diagnose the bug) Note that I've never had a processing of a model take more then 10 minutes. But my laptop is pretty fast.

No. That causes too much disruption in the normal process, so it was decided a long time ago that we won't do local pickups. (Sometimes some rare occasions local pickups do happen, but that's very rare)

Codename Pink Unicorn has about 85 settings. Sure you want 85 columns? Not sure if that gives a easy to use user-interface ;-)