tinkergnome

Which version do you use? I think this was corrected / changed for V17.10: https://github.com/TinkerGnome/Ultimaker2Marlin/commit/8e22b1c50520e8f3ea8509d6f94422c9b1e514fa

I think, it depends on how you start Cura... Usually it's the main folder of Cura in "Programs". Just to be sure: right click on the Cura icon in the start menu and choose the last menu item (Properties). There's a working directory defined. That's your target. And take sure, that you copy the file from "C:\Windows\system32", not from anywhere else. If in doubt: right click on the file "vcruntime140.dll" -> Properties -> Details ...share a screenshot and we can compare... Another test: open a command prompt and change to the Cura program directory, set an explicit PATH without all these (x86) stuff and try to start cura from there. I'm not sure about the correct installation directory, but it should look similiar to this: C: cd "C:\Program Files\Ultimaker Cura 3.1" set PATH=C:\Windows\system32 cura

I think, it's worth a try - but which file(s) exactly? Do you have a link or a term to search for?

It's not that hard. From your "System Info" screen (from above) choose "Advanced System Settings". This opens another dialog and there should by a button somewhere that is labelled "Environment Variables". Search for variables with a name that starts with "QT_..." and let us know, if you find something interesting... Alternative: open a command prompt and type: set >> %TEMP%\environment.log Afterwards, type "%TEMP%\environment.log" in the address line of the Windows Explorer - this should open notepad with the generated file loaded. Post the content and let's take a look (if you want). On the other hand... enjoy Linux!

Sure - I think that's clear by now. The error 0xc00007b (INVALID_IMAGE_FORMAT) indicates that at least one loaded DLL has the wrong image format (32 bit instead of 64 bit). In your case obviously a dependent file, that Cura 2.7 does not need... Unfortunately there are many possible reasons for this. It's quite common on Windows that installation programs overwrite system files or are setting weird environment variables. Your best chance is to check for any QT related environment variables, or change the order of the entries in the PATH variable (even more detective work and 'trial and error').

@ToPi auf den Produktbildern ist gut zu sehen, wie die Lösung von Ultimaker aussieht - und ja: es hat durchaus einen Grund, das die Abdeckung nicht flach ist... https://ultimaker.com/en/resources/49881-how-to-install-the-front-enclosure Wenn Du auf ein paar Millimeter vom Bauraum verzichten kannst, kann man die Programme im Slicer aber sicherlich auch so erstellen, das der Druckkopf nicht so weit nach vorn fährt. Edit: Die Abdeckung aus dem 'Advanced Printing Kit' ist ca. 14mm 'tief'.

Nope, fortunately FreeCAD is quite good in exporting correct stl-files. But your screenshot from above gives a hint... It's not a 'phantom' layer, it's the 'ironing' layer. Disable ironing and it should disappear. It seems that 'ironing' without a top layer does not work (I don't know, if this is the intended behavior).

@gr5 - i have no clue, what is meant here @wong - where are these numbers from? And which parameter do you want to change? Perhaps the "Z_MAX_POS"? But this doesn't depend on the extruder count... the z-offset is most likely not that huge... and the translation "second platform" is even more confusing...

I think so. 4.2.5 is the only (stable) version with a name that begins with "4.2", and the "full name" of the predecessor was 4.1.4

Just to be sure: If you want a "Z hop" on every travel move, take sure that "Combing Mode" is deactivated (because an enabled "Combing Mode" suppresses most of the retractions).

Usually there's a corresponding post in the "News" section of the web page, not on the forum. For example - this are the announcements and release notes for: Version 4.1 and Version 4.2 Is it this, what you're looking for?

As @ahoeben said, for prints from sdcard your possibilities are limited. There's gcode M105 for the temperatures and M27 gives you the current (byte) position of the printed file. I see no other available information that would be useful for your use case. At least you could use it to make your own statistics and predictions.

Erin made a great article about this: https://ultimakernasupport.zendesk.com/hc/en-us/articles/115004187086-The-Button-Won-t-Click

...or in case that Cura 3.1 won't start.... delete this folder to clean up: %APPDATA%\cura\3.1 (Cura itself does not add any registry entries AFAIK - so these cleanup tools do not help much)

The link from nallath explains, that you should type "%APPDATA%\cura\3.1" in your Windows Explorer - and look for a file named "cura.log" - why is this unrelated? Ok - it explains it a bit cryptic and with other words... but still...

If i remember right, the nylon profile adds a large brim to the model. Switch to the custom settings and check the settings in the section "Buildplate Adhesion". Reduce the size of the brim until it fits into the build volume. Good luck!

The question is how the forum software detects a 'revisit'. Are you permanently "signed in" to the forum, or do you use the "Sign out" link after your visits? Just a guess, but it's at least possible, that "currently signed in" counts as a "revisit"...

Looks like the option "Avoid printed parts when traveling". It's in the "Travel" section of the settings, you can also specify the distance to the part. But you have to make these settings visible first like described in the manual.

detailed instructions with pictures: How to clean the bowden tube

Cura generates move instructions for the e axis (G1) with the specified distance and speed. Like any other move. Easy to find in the generated gcode of you search for lines that only move the e axis, like "G1 E12.546 F1500", or simply for "F1500" (1500 mm/min == 25 mm/s). If those lines are there, your printer ignores them for some reason. Does the "volumetric trick" from your linked topic still work? Smoothieware seems to be able to use volumetric e values, so this would probably the easiest way to go?

What about the retraction speed? Does it match the values that are usually used for your printer? Does it have a bowden setup? I ask, because a retraction distance of 6.5mm is quite long for 1.75mm filaments. Same question - does it match the values that are usual for your printer?

As far as i can see this script inserts a M600 command at the beginning of the specified layers. That's something that the UM2 printer family does not support and does not need. M600 does nothing more than retracting the filament and pausing the printer. I guess it's there to support printers that do not have a builtin "Change filament" function. For the UM2 you can just use the pause script and change the filament with the help of the printers menu functions.

There's an option in Cura preferences: "Automatically drop models to the build plate". You should be able to position your model wherever you want, if you switch this off. BTW: which Cura version? The option exists for Cura 2.7 and newer - I'm not sure about older versions.

This depends only on the revision of the main board. On the older boards (Rev. 2.1.1) the 5 Volt supply for the small fan is hard wired and not switchable. This has changed for newer boards, that are used for the UM2+ (Rev. 2.1.4). A cheaper option for older machines would be a bimetallic temperature switch and a bit of tinkering, see here: UM2-RearFan-Automatic

I don't know, if it is documented in public somewhere. The lights have changed over time because of one or another firmware update. So don't worry. gr5 is right, currently it's "ultimaker blue" in idle mode, (kind of) "glowing orange" during heatup and simply white during printing. The file "/usr/share/griffin/griffin/led/controllers/headSlotController.py" is responsible for this behavior (you can double check it, if you connect via ssh to the printer).