tinkergnome

If you want to do this, you have to connect with an ssh client to the printer. In developer mode you can access, delete and change any file on the printer. That means you can completely mess up your device - so be very careful. If you have no clue what ssh is or how a linux system works... you should better ask your reseller for assistance - give him/her the link from the topic that is mentioned above (better safe than sorry...) As a minimum for the DIY approach: read the first paragraphs of this topic about "developer mode" and "what does it do" before you start: BTW: what is the output for the "Hardware type ID", if you scroll down on this screen?

Your printer has an identity crisis...? - the question is... why? Did it got a new mainboard recently? This topic may help:

What does this exactly mean? How do you initiate the pause (manually on the printer?) How do you change the material (with the menu function on the printer or...)?

The schematics are published on GitHub: https://github.com/Ultimaker/Ultimaker2/tree/master/1249_Ulticontroller_Board_(x1) This should be the encoder: https://www.alps.com/prod/info/E/HTML/Encoder/Incremental/EC11/EC11B15242AE.html

here are elaborate explanations:

Here is an explanation / discussion: https://github.com/Ultimaker/Cura/issues/4222

Ultimaker hat die STL-Dateien veröffentlicht: https://www.youmagine.com/designs/ultimaker-3-spool-holder

If you swap the plugs on the mainboard TEMP1 <-> TEMP2 the error message should change to: [ERROR] Error:0 then you know, it's the sensor.

Also just to clarify: The 'product owner' is a role in agile software development, in this case probably just a different person (not mentioned by name) that is working for the company though. At least we know that it's not Marco... Not every employee of Ultimaker is active on this forum, it's meant as a forum for the community, not as a support forum of the manufacturer. The best way is indeed to bother your reseller with those problems (the more the better...). The network of resellers (pun ?) is the "voice of the customer" the product owner is responsible for. ? Edit: It doesn't hurt to mention issues here on the forum though - but this voice is far less powerful... ?

Yep. That means the temperature reading for the second nozzle is higher than 275°C (the "1" in "Error:1" is the tool number - T1) There's either no PT100 plugged in TEMP2 or the sensor / cabling is faulty (assuming that it is not that hot in your room... ?).

If you're logged in as "ultimaker" you are already in the command util (there's a "(Cmd)" prompt, correct?) - and you can just type the "sendgcode..." commands. The instructions from @CarloK are complete:

My best bet is that the second temperature sensor is not connected or gives false readings. In this case you will get this error with any dual extrusion firmware, but not with the single extrusion variants. The sensors are connected directly to the main board (if i'm not wrong....?), so this is unrelated to the expansion board. To proof my assumption you can connect the printer via USB to a serial console (e.g. printrun/pronterface). This will show you a more detailed error message. The extruder number (0 or 1) and the error type (MINTEMP or MAXTEMP) is written to the console. Once the printer starts normally one can change the print area and the steps/mm in the preferences menu.

The message looks weird... If you compiled it yourself, i guess that something got messed up? Do you get the same errors with the pre-compiled Mark2 firmware?

Phew - i think, @gr5 is right... Here is a screenshot from Meshmixer - every dot is an error in the mesh: It would probably work regardless, but the main problem is that the transition between the body and the neck is not smooth. There are a lot of small triangles that stick out to the inside and Cura tries to support them. Simplify3D does the same btw. I guess there is a small step between the two parts in your original model? It's hard to see in a 2D view, i have selected a few:

The "cura.log" file in your configuration directory should give you some hints about the reason, perhaps only some odds-and-ends?

I don't have it in front of me at the moment, but i think, it's more like a feature... ? The preheat menu handles the nozzle (pre-)heating on its own (if it is enabled), but only if the target temperature is zero. The choosen temperature depends on the printing temperature of the selected material. There's no gcode to enable/disable the pre-heating, but any other target temperature than zero (whatever you send via USB) "overrules" it. I think you can use either the preheat menu or serial commands for pre-heating but not both at the same time (at least not in this way).

Probably... it may be a bit outdated, but i think it's basically still the same. There are newer instructions by @gr5 , especially if you want to use the simulator:

one idea: Take a look at the machine settings for the selected printer in Cura. Carefully compare these settings too. Especially the option "Origin at center" (or "Machine Center is Zero" - the labeling depends on the exact Cura version...) Still no settings changed?

UMO+ uses the main board 2.1.1, right? There are two "Safety"-Jumpers that (dis-)connect the 24V line if (not) installed - i would check those first (between LED- and endstop-connectors). And AFAIK there's a relay for the 24V line near the power connector - this may be faulty - (measure the voltage there).

Das hier ist der relevante Teil in der Ultimaker-Firmware, der Kommentar erklärt, warum es so umständlich ist: https://github.com/Ultimaker/UM2.1-Firmware/blob/UM2.1_JarJar/Marlin/temperature.cpp#L552 Wenn Du die Ansteuerung vom Servo hinbekommen hast, kannst Du ja mal berichten, wie es funktioniert. Man kann nie wissen, wo man das mal braucht... ?

No - all your files do this.... ? Marlin has a motion buffer of (up to) 16 line segments. And if printing these buffered line segments takes long enough, this can happen. It's just a coincidence that there are a lot short moves at the end of the other half of your files, so that it doesn't hurt that much...? The obvious solution is to remove the "M104 S0" from the end of the files. An additional "M400" right before this line would also help. Where does the M104 come from? Does Cura 2.3 insert these line or have you added this yourself to the end-script? Cura 3.5 does not add this line (anymore?).

Die Fehlermeldung ist ja ziemlich eindeutig. Irgendwo in der Funktion "void move_nozzle_servo(uint8_t)" wird etwas mit dem Namen "MOVE_SERVO" verwendet, das wurde aber nicht gefunden. Du musst nur herausfinden, was "MOVE_SERVO" ist (vermutlich ein weiteres Makro), und wo das deklariert bzw. definiert ist.... Die aktuelle Marlin-Firmware ist zu großen Teilen aus Makros zusammengesetzt, das ist keine leichte Kost für den Anfang... Ich hab keine Ahnung, was man für den Servo noch so alles braucht. Soweit ich das auf die Schnelle sehen kann, wird "MOVE_SERVO" nur definiert, wenn das Makro "HAS_SERVO" "true" ergibt. Und letzteres prüft u.a., ob mindestens ein Servo-Pin definiert ist. Dabei wird allerdings "SERVO0_PIN" geprüft, nicht "SERVO0_PWM_PIN". Also vielleicht solltest Du "SERVO0_PIN" (auch) noch definieren, zu "SERVO0_PWM_PIN" hab ich überhaupt nichts gefunden, wird das überhaupt irgendwo benutzt?

The MINTEMP error is normal is it reads 0°C or less on the nozzle. UMO+ uses the same mainboard as the UM2 and this works with PT100 temperature sensors, is this right? But the resistance would be somewhere between 100 and 200 Ohm in this case (not kOhm). I guess you are using something different, but then it's not an UMO+... ? You said " modified UMO+ " - what does this mean? Which kind of mainboard is used and which type of sensors? And which kind of firmware is installed on the (new?) board - is it modified too? And does the configured sensor type match the actually used sensor type?

I think so...? It looks like a start script for Simplify3D, not for Cura? Have you inspected the generated gcode? The variable names are different for Cura and curly brackets are used: ; for example: ; M190 S{material_bed_temperature_layer_0} ; M109 T0 S{material_standby_temperature, 0} ; M104 T0 S{material_print_temperature_layer_0, 0} ; AFAIK all variable names that are defined in "fdmprinter.def.json" can be used.

Hi Link, the Marlin PID autotune never worked well for me. But if you want to try it - i would use a target temperature that is close to the usual printing temperatures. Here are some links with the default values from Ultimaker: Heated buildplate: https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/Configuration.h#L250 Nozzle heater UM2 (25W): https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/Configuration.h#L201 Nozzle heater UM2+ (35W): https://github.com/Ultimaker/UM2.1-Firmware/blob/UM2.1_JarJar/Marlin/Configuration.h#L206 "Heater timeout" switches the nozzle heater off, if the printer is inactive (not printing or paused and no user interaction). This was actually a feature request from a makerspace, where sometimes users startet the material change wizard or heated up the printer and then went away - and the printers were "cooking" the material for hours or over night... It just adds some more security.