ahoeben

And what I am saying is that your understanding is wrong, and I would suggest (again) that these texts are checked by engineers who pick out the crap. The original line, as it is in the Changelog is: " A 3MF extension is now used for project files. The ‘.curaproject’ extension is no longer used. ". The "better compatibility with 3d software applications" is just incorrect embellishment. There was an issue on OSX where Cura would create confusing filenames. That was fixed.

It is the former. The ender seems to be treated as a machine compatible with 2.85mm materials, so those are listed.

Do you perhaps have (m)any postprocessing scripts active? Does this also happen if you save the gcode to another drive (eg to your desktop)?

Note that though it is best to learn to create proper models, you can get Cura to slice this particular model the way you probably intended it. Find the setting "Union Overlapping Volumes" in Mesh Fixes (you can use the Search on top of the settings) and uncheck it.

You did not model it with inverted faces, but probably with too many walls. This happens when boolean operations go wrong, or there was no boolean. I don't know enough about your specific model or inventor to be sure.

Yes, probably. Can you check the model in X-Ray view? If there are red areas in X-Ray view, your model has "internal geometry", and Cura looses count what is inside and what is outside. Care to share the STL file? Note that STL files do not contain units, so Cura can only make an assumption to the unit that was used while modeling. Since Cura can't read your mind, it always assumes the unit is MM (and you probably modeled in CM if you have to scale the model up to 1000%).

From the blog post: There was never a ".curaproject" extension.There was a ".curaproject.3mf" double extension, but there's been a bug since forever on OSX where double extensions would become quadruple extensions. This has nothing to do with compatibility between other 3D software applications. Who writes this, and why is it not checked by anyone who knows it is nonsense?

All plugins have to be updated before they can be used in Cura 3.5, because of some underlying changes. Not all plugins have been updated yet. I don't thinkl the Solidworks plugin is "dropped", but it is not yet ready.

"Soon" Could be today, could be tomorrow. Could be next week too. Not saturday or sunday though, probably not friday.

'doh! I scrolled all the way to the top of the topic to check what printer you were using, not noticing that you are not OP. Sorry for the confusion. Yes, you should be on the latest official release again now.

Resellers generally don't list all parts that are available on their website, because there are too many of them. But even if they don't have a specific part in stock, they can order just about any part from Ultimaker.

Postprocessing scripts are now permanent (since 3.3 or 3.4).

See this conversation:

But then @DangerMouse would need to install OctoPrint first. I am actually working on making it possible to use that plugin from OctoPrint (ie: update the firmware through the Cura interface on a printer that is connected via OctoPrint, if that plugin is installed), but that will not be available until Cura 3.6 Good tip on the legacy version of Cura, that could very well work (if you manually set the port and baudrate first). I have a PR that cleans up firmware updating, and is sort of a prerequisite for finally bringing manual port selection back. Once that work is done, I will also make sure that firmware can be updated even if the printer does not respond printer-like.

Your printer as apparently not responding as a printer would, so Cura thinks it is just another type of serial device instead of a printer. It is sort of a chicken/egg situation; you have to fix the firmware in order to make it behave like a printer again, but you cannot fix the firmware because it is not behaving like a printer. Fortunately there are other tools that are less stubborn (and - truth be told - yours is a somewhat exceptional situation; normally firmware updates are fairly safe). The firmware .hex file is included in the Cura download (C:\Program Files\Ultimaker Cura 3.4\resources\firmware\MarlinUltimaker2extended-plus.hex). AFAIK, you cannot upload a .hex file straight from the Arduino IDE, but if you have ever used avrdude, you should be able to figure it out. If not, you can download the source of the UM2Extended+ here and open that in Arduino and flash it to the Arduino Mega 2560 that is hidden in the printer: https://github.com/Ultimaker/UM2.1-Firmware/tree/UM2.1_JarJarExtended

An UMO with an added heated bed kit is still an UMO, not an UMO+. I think you have uploaded an UMO+ firmware to your UMO, which probably does not work. If you add an UMO to Cura, you will be presented with a dialog to select upgrades, where you can select that you have a Heated Bed Kit. Do that and upload a new firmware using that configuration.

Sorry about my previous message, I was thinking you were using OctoPrint (which also uses the USB port, and hence also needs the gcode flavor changed).

Check if the printer still shows up as a serial port in Device Manager. If so, the bootloader is still alive, even though the printer does not have a working firmware anymore. As long as the bootloader is still working, you can use other applications such as Arduino to upload a Marlin firmware.

The Connect to OctoPrint dialog contains this message:

Just get a Raspberry Pi, or a starter kit (eg https://thepihut.com/collections/raspberry-pi-kits-and-bundles/products/raspberry-pi-3b-plus-starter-kit) Then install OctoPi on it: https://octoprint.org/download/ Note that OctoPrint is not a requirement for using the Z-Unlimited. Once you have done the conversion, you can print as you have always done (it will just take longer and result in awesomer prints)

OctoPrint is free and open source software. There’s no supplier for it, you download and install it.

There is no pausing involved; you place the string while the printhead is moving. The tension is applied by you while applying the string. The shape of the support arms is such that they are a bit below the top of the print, so the string is normally tensioned down a bit. Because the printer is basically suspended upside down above the print, the print is much more accessible so tensioning the string while printing is a bit less timing-critical than it sounds. I have mainly done some vase-like-objects, with an old nozzle that was worn down to a diameter of about .8mm (from .4 mm) with 0.4mm high layers. That way I can print ~1 meter high objects in approximately 5-6 hours: @rooiejoris' elephant is a more hardcore print using his mod. Yes, everything was included in the kit I purchased, except one or three printed parts which I have found to be somewhat optional. Also see the instructions for modifying the printer using the kit here: http://www.rooiejoris.nl/instructions/

I have one. It is pretty complete.

I would suggest not manipulating the support blockers in Layer View. Layer View shows the sliced result, after a lot of calculation. That's why it takes a long time to update after changing the support blockers. In the normal "Solid view", you can see the areas that will get supports added in red. Click those red areas if you don't want those areas supported. Then switch to "Layer view" to check if everything got sliced ok. That's the intended use of Support blockers. Update: a tip on Layer View: set the Color Scheme to "Line Type". That makes it much clearer what is support and what is not.

Have you changed your GCode flavor from "Ultimaker 2" to "Marlin"? Otherwise USB printing won't work with the Ultimaker 2+.