tinkergnome

now the compiler is probably too old... (which version have you tried?) There was a need to change some paths in the Makefile for 1.6.5 and later. This should be the corresponding commit: https://github.com/TinkerGnome/Ultimaker2Marlin/commit/31b016ff886bb509cf5515042ca225ab08180903#diff-04c206a8bd7b5cedd4c30700d062b19a

"eeprom_read_float" was not defined in earlier compiler versions, so it may actually help to use an older compiler. On the other hand: i used version 1.8.1 last time, the difference should not be that big... and the used "weak" pragma is intended as a hint to the linker how to handle this. For newer compiler versions it should be safe to remove the definitions of both functions from UltiLCD2_hi_lib.cpp ("eeprom_read_float" and "eeprom_write_float").

The crucial point is: you need the Arduino compiler (obviously), but don't use the Arduino IDE. In short: you should use Git Bash, mingw32-make and the build script instead. @gr5 published his notes a while ago, you can use it as a starting point.

The wedges are a bit longer than the counterpart on the dock. I think the intention is to improve the grip? There's a picture in the build manual. This is how it should look like once assembled - are yours different?

The UM2Go has no heated buildplate by default. That's why there's no standard firmware from Ultimaker that supports it. What kind of heated buildplate is it (i think there are not that many out there...)? Can you reinstall the former firmware version (which one was it)?

Great - that means: you can update the firmware to the current version and your problem is solved.

Haha no idea, how do I find out? (srsly) There should be an entry in the "Maintenance" menu (on the printer) - it shows a date and a version name.

How old is your firmware? The usable range for Y was 5 -230mm on firmware versions before 07/2016 This changed with this commit and again a few days later, that means - probably for all firmware versions included in Cura 2.1 and later.

I thought that's the main reason why "Slice automatically" can be disabled in "Preferences" for recent versions of Cura. Or does it not help?

it must admit - it took a while... as far as i understand you use the expansion board and right now you are making the cables yourself, right? Be careful with the model cooling fans - these are connected in series (two 12V fans powered by the 24V line). The small 5V fans are using JST connectors, the 12V fans are connected with Molex plugs (AFAIK). The exact types of the connectors are mentioned in the build manual (search for "Making the y-cables"). With the identifiers from there you should be able to find the correct plugs.

Yeah, you may perceive it as a bit finicky, but actually there are possible significant differences between the correct settings for different colors - even from the same material... And after all: it's only a warning that can be overridden, right? But i agree: for users like you and me (with only one printer) it's a step back from the sight of convenience... although i understand the reasons why it is implemented this way nowadays. Oh..., and i nearly forgot this: I don't think so. Only the gcode is sent to the printer by Cura, nothing else. What's the source of this thought (did i missed something)?

There's no easy way (if any) to teach the UM3 your custom material. That's intended (AFAIK) and not a bug. The Cura Connect -Server uses this information to find a suitable printer for the print job. That's obviously not necessary, if you print from the USB-stick (that's why it does not complain in this case). I know, that with Cura it's possible to create custom material profiles, but those are not very useful for the UM3 and the new firmware. Just choose generic PLA in Cura (but keep the current settings), if you want to send the job via network - and the printer is happy.

Bob, if you continue to install mark2 at this pace, 3D printing technology will be long outdated before you start your first dual print... (just kidding)

I sometimes use S3D generated gcode for the UM3 (with success). The crucial change is that the 4.x firmware (for Cura Connect) makes the material-id in the gcode header mandatory. S3D is not able to generate this automatically (AFAIK) but it's very easy to add it to the existing postprocessing script. The easiest way would be to "steal" these (one or two) lines from the Cura generated file. On the other hand: i never noticed significant differences between prints from Cura and S3D. I can't follow your statement about "very bad print quality because it's Cura". It's indeed a "print and go" in my case. Can you explain the issues that you have with Cura prints? Do you have pictures for comparison between prints that are prepared by S3D vs. the same print prepared by Cura? And did you use the standard settings in both cases or what is different?

@SandervG - what about a "kman"-challenge during the downtime? Something like: what can you model in 36 hours to celebrate the forum migration... Let's collect some suggestions for "how to use the downtime as creative as possible"!

You only talked about Cura so far, so first things first: you need to install a firmware for 2 extruders... In case of Marlin this also needs (at least) a second temperature sensor. I've not tried it, but the temp sensor can perhaps be "faked" by using a resistor instead (would be cheaper... and is probably safe as long you don't install the second heater). In short - a bit more tinkering is necessary to get it to work.

Is it possible that not all parts are back in the right place now? Does the nozzle or the heater block touches the fan shroud somewhere? If in doubt: pictures of the printhead would be helpful (from the front and the back). Have you measured the real temperature for comparison or is it just a "feeling"? Is this the "old" UM2 with the spring above the PTFE coupler? Another possible cause is that the PTFE coupler is worn out. It's a consumable part and does not last very long at this high temperatures.

Ich glaube, das sind nicht die Standardeinstellungen, aber es wird so vorbelegt, wenn Infill Density auf 100% gestellt wird (in deutsch vermutlich "Füllung"?). Kann das in Deinem Beispiel der Fall sein? Ich glaube der Hintergrund ist, das die CuraEngine bei 100% Füllung tatsächlich gar keine Füllung generiert, sondern statt dessen durchgehend "Bottom Layers" produziert. Ich vermute, diese Vorbelegung soll dann einfach nur aufzeigen, was im Hintergrund tatsächlich passiert. Ergibt das einen Sinn für Dich? Edit: Mist, ich war zu langsam... ...und wir sind auch gar nicht im deutschsprachigen Teil...

Alles klar. Viel Glück! Nur aus Interesse: Ist denn die eigentliche Ursache schon geklärt? Waren die Einstellschrauben zu lose (die Glasplatte zu hoch), stimmt die Position vom Endschalter nicht, oder funktioniert der Sensor nicht richtig? Sind denn irgendwelche Kandidaten in der Nähe, die als "Störer" in Frage kommen (Trafos oder Lampen)?

Hallo Kai, ich glaube, Deine Frage ist hier nicht so gut aufgehoben. Soweit ich weiß, macht Ultimaker den Service nicht (mehr) selbst, und hier im deutschen Teil dürfte es sowieso kaum jemand wahrnehmen. Der normale Weg wäre das Du dich zuerst mal dorthin wendest, wo Du das Gerät gekauft hast. Wenn der Verkäufer den Service nicht selbst macht, wird er Dich an die richtigen Stellen weiterleiten... Ich hab auch mal gehört, das iGo3D den kompletten Service für Deutschland abwickelt. Vielleicht geht es sogar schneller, wenn Du mal direkt dort anrufst (oder email schreibst). Die Kontaktdaten müssten auf der Reseller-Seite zu finden sein. Viel Erfolg!

I have no idea about Smothieware, but i have to disagree this argument: In case of Marlin, that's simply wrong. A standard Marlin firmware will never do a toolchange for M104 or M109. The (optional) T-parameter is interpreted as the target extruder for the temperature argument and nothing else. If Smothieware behaves different, the "Marlin" Gcode-flavor is probably not the right choice.

I don't know, how large this user group still is, but perhaps it's worth a thought to bring back the former functionality for those cases where there's only one printer in the group?

A possible reason may be that no one else noticed this, or that no one else regularly aborts print jobs... @ReFl3x0r - I think, it's a bit hard to guess, what is meant by "main extruder drives nuts". A few more explanations or a short video would be nice... - main extruder == extruder axis? - or the print head (x/y axis)? - the print was started from sdcard and aborted on the printer? - or are you using usb / octoprint? Take sure that the second printhead is always decoupled (resides in the dock) if you switch the printer on. And: please explain what you have done exactly, what happed, and what you've expected instead. Looking forward hearing from you!

It depends... I assume that you have two different feeders installed now - probably one from the UM2 and one from the extrusion upgrade kit? Regarding the wires: AFAIK there should be two pairs of wires on the connector that are twisted together. One of the pairs needs to be swapped (if you count the contacts - swap either contact one with two or three with four - that's all). Which firmware are you using? -That may be even easier, but i'm biased...

Such a possibility is already there (more or less)... It's not very convenient, but it works. Search the forum for "Support Mesh" and "Anti Overhang Mesh".