tinkergnome

Always first things to check: Take sure that both "Safety"-jumpers are still in place and the 24V source is still there (can be measured at the marked connector). Schematics are on GitHub: https://github.com/Ultimaker/Ultimaker2/tree/master/1091_Main_board_v2.1.1_(x1)

Hi Richard, once upon a time... as the UM3 was launched... a lot about the bed level compensation was explained by the developer(s) itself:

BTW: that's a smart idea. I think, someone should copy this for the Mark2 definition...

There's one more thing to do. The setting "Offset with Extruder" has to be enabled. It's easily accessible with the "Printer Settings"-Plugin, or set the value of "machine_use_extruder_offset_to_offset_coords" in the json file. As mentioned - it's not the originally intended way for Mark2, but may be handy for your ideas someday. And be aware that Cura "automagically" compensates the extruder offset in the preview mode. You'll need a different gcode-viewer to actually check it before printing (CraftWare is quite nice for those things). Here is a screenshot from the Simplify3D gcode viewer - sliced with Cura, extruder offset 18mm (just to prove it 😏)

Well, the extruder x/y offsets in Cura and the ones on the printer will be added together in the end. That means: i would use one of them and set the other one to zero, not both at the same time. The Mark2 printer definition for Cura is made with the intention to use only the extruder offsets on the printer (all offsets are zero in Cura). Or you can probably do it like it is made on the UM3, if it better fits your needs: - remove the disallowed area on the left - configure the main part of the x offset in Cura (18.0mm) - use the offset setting on the printer for fine tuning of the last few fractions of a mm (+-) (no guarantee, but that's how it works on the UM3 - and i hope it does not sound too confusing... 😏) And for single extrusion prints with the main print head: use the normal UM2 printer definition as usual, not the Mark2 one. In general... yes. But take sure that you set proper starting values for the extruder offset on the printer first (if you've changed those). IMHO x = 18.0 and y = -25.0 are the defaults of the firmware. And be aware that the provided calibration gcode is in "Ultimaker" gcode flavor fro 0.4mm nozzles. So take sure that you have configured proper material settings for both extruders on the printer. (you can slice your own gcode with the stl files from GitHub at any time though)

Not that I'm aware of... But it seems that you know what you're doing, so what about making a second profile without disallowed areas. You have to be a bit more careful while placing the model, but Cura will be satisfied and slice it as usual. You can do it with the old (UM2) print head. The "plus" models don't have the "spare" holes anymore (at least not in the plastic parts). Yes, with gcode flavor "Ultimaker" there's the one and only printing temperature configured on the printer itself. Cura will not insert temperature commands at all. And because the "temperature magic" of Cura is so useful for multi extrusion projects, "Marlin" is the far better choice. You will get used to the "override" message 🙂, or attach an OctoPi and print via USB - that will solve it too... 🙂 I'm not sure what you're trying to configure? The "extra prime amount" or something like this? I never changed the zero value there. It's a task of the prime tower to even out the material flow before traveling to the model. There may be one or another bug in regard the prime tower in recent Cura versions though....? Others may be know more.

Yes, the top part needs support underneath. But first: remove the internal geometry to make the model suitable for 3D printing. Here you have it:

@Zataras, well, i think you could be more specific about this quote from your post. First of all: which instructions?? How have you merged the "direct register write" into the Marlin 1.1 sources? (only copy&paste will not work, that's for sure 🙂) How deep is your knowledge in C programming for the Arduino? What exactly did not work (what about a code snippet and/or error messages)? BTW: doing your own fork on GitHub is actually a good idea, because it makes collaboration so much easier..

The printer-API is a big playground for those things, doesn't require developer mode and is used by Cura as well. ...and is even made by UM developers! 🙂 http://..../api/v1/printer/led ...works with HSV representation (hue, saturation, value) and gives you any color you want (after you've repaired the hardware of course). Those settings are volatile though, but still...

What about adding the acquired digest authorization to you first command? Something like this should work with 'curl': curl -X [...] --digest --user YOUR_ID:YOUR_KEY [...]

There's another link with instructions in the post from below. The first two steps are probably sufficient to convince the firmware update process ("set date..." and "set time..."). Precondition is, that you're logged in to the printer as root (putty), it seems that you already know this part. The extra validation of date and time should be a thing of the past, once you managed to install version 5.2 (AFAIK). So that should be a one-time effort.

@3DPLAB I have heard before (somewhere here) that "command_util" does not work anymore for users other than "ultimaker", especially not as "root" (current firmware version). I don't know, if this was intended or not. If you log in as user "ultimaker" you will be redirected straight into a working "command_util" prompt.

In Simplify3D? Wie geht das denn? Hab ich was verpasst?

Don't know, if it helps, but once upon a time someone developed a similar thing with PHP, but with the "old" API (that needs authentication). It should be rather easier in your case. Here is a link to the topic:

Great, i assume that's the original / intended way to use this feature. You're welcome! And always stay upright! 🙂

Nein, ja 🙂 ...vielleicht sollte das mal jemand dem Ghostkeeper sagen..., (zusätzlich) stören tut es aber glücklicherweise auch nicht. Das eigentliche Problem schein zu sein, das der ";current layer..." - Kommentar jetzt an einer späteren Stelle im gcode steht als in früheren Cura-Versionen, und damit kommt das Postprocessing-Skript nicht zurecht. Im Beta-Test scheint das niemandem aufgefallen zu sein... Wenn man also nicht selbst "skripten" will, kann man nur machen, was man immer macht: erstmal weiter die ältere Version benutzen und beobachten, ob es irgendwann wieder repariert wird... 🤷‍♂️

Actually there is code on the machine that can do that! 🙂 I don't have the Marlin sources of the UM3 at hand, but usually the so-called "software endstops" are enabled. With other words - it's the normal behavior: the firmware of the motion controller limits all moves to specified boundaries (instead of ramming the printhead into the wall). All moves beyond the limits of the printer are clipped. http://marlinfw.org/docs/gcode/M211.html @dxp if you do it this way, you have to reduce the maximum x coordinate to 215mm as well. I guess the normal way is to simply disable the second extruder with the "official" checkbox in Cura. This should be enough to unlock the "once at a time" option (or does this not work?).

You can do it like Cura and send it to the Cura Connect queue with: http://<IP_OF_YOUR_PRINTER>/cluster-api/v1/print_jobs/ (where <IP_OF_YOUR_PRINTER> is the IP address of a Cura Connect group host) An example with curl for Windows would look like this: curl -X POST --header "Content-Type: multipart/form-data" --header "Accept: application/json" {"type":"formData"} -F "file=@%FILENAME%" %URL% (with the URL from above) There's a Swagger documentation on the printer if you call the base url "/cluster-api/v1" Good luck!

It would be cheaper, if you create a short gcode file by hand and "print" it from the sd-card (just to test, if the printer can reach the height without an error message). Something like this would be probably sufficient: G28 Z0 ;home z G0 F2400 Z230 ;raise z to 230mm

I don't want to say it's impossible, but it's not a quick task for sure... The Marlin documentation provides a list of all relevant keywords you can search for in the source files. But back-porting all the dependencies into the older version will be... not worth the trouble, if you ask me... 😈 If you don't need the "UltiGCode" features, it would be probably easier to adopt the Ultimaker menu system for a newer Marlin version, although this would be a lot of work as well.

Kurz gesagt: ja Offenbar generiert Cura 4.2 den gcode etwas anders als früher und damit kommt das Pause-Skript nicht zurecht. Dieser Bug hört sich nach dem gleichen Problem an: https://github.com/Ultimaker/Cura/issues/6131 Also bleib einfach vorläufig bei Version 4.1, damit scheint es noch funktioniert zu haben... 🤷‍♂️

Quick answers: (1) Yes, easy-peasy (2) Hell no ☺️

Hi @PaulDF, That's a check and an error message of the printers firmware and not related to Cura at all The UM2+ (non extended) has a maximum z position of 225mm My best guess is: There's the wrong firmware installed on the printer. Don't you have a problem with the build plate leveling as well?

Das stimmt natürlich, aber zur Vollständigkeit: Man braucht trotzdem jährlich eine Lizenz von Autodesk, das Dateiformat ist proprietär und es ist eine Cloud/Hybrid-Lösung. D.h. ich muss Autodesk vertrauen, das sie auf ihren (ausländischen) Servern gut auf meine Daten aufpassen und es funktioniert nur so lange, wie die Lizenz zur Verfügung gestellt wird. Das kann man mögen, oder auch nicht...

The fan icon blinks a few times when the requested fan output changes. But this is only related to received gcode commands, nothing else. As a first check I would search the gcode file for unexpected M106 commands.