ahoeben

Sorry, it is "AppData" instead of "Application Data". You may have to type in the path, because the "AppData" folder is hidden by default.

Have you tried renaming c:\users\[your name]\appdata\local\cura to cura.bak?

~/Library/Application Support/cura/machine_instances This folder should also be easily accessible through the Help->Show Configuration Folder menu.

With a "custom" printer, you don't get the UM2+-optimized profiles, or the nozzle size dropdown.

If this gcode works for more people, I will amend my gists. I don't have a UM2+ to test with myself.

Ok, I'll get cracking then... You might consider changing the resolution of the image served by mjpegstreamer though. It won't be a very convenient toggle for now though. Switching is likely not going to be instantaneous. No. The video stream is encoded as Motion JPEG (mjpg). This is basically full jpg images concatenated one after the other. If it were encoded with another codec (such as H.264), you would have a point.

I have added some notes on UltiGCode to the readme of the plugin: https://github.com/fieldOfView/OctoPrintPlugin/blob/master/README.md Let me know if that works for you.

Yeah, that's true. Same thing for the UM3 though (Fun fact: the UM3 uses the same software for streaming the camera image. Another fun fact: the OctoPrint plugin is a fork of the UM3NetworkPrinting plugin). Streaming stops when you switch to another printer though. Serious question: is it really impacting network performance? I would say that (on an internal network), it should be hardly noticable; it's not *that* much data. Unfortunately the plugin currently can't tell if you are looking at the monitor tab or not. I would rather not implement a hack in the OctoPrintPlugin for something that really needs to be fixed in Cura itself. As a quick fix I can add an option to not display the video stream (at all) when connecting to OctoPrint. Note that I have code ready to display the streaming video instead of the current high-speed slide-show, but this issue is the reason I have not merged that yet.

Yes, that would be helpful for the devs in case they have not reproduced the issue themselves.

Your guess is correct.

It is not an error, it is a feature ;-) You probably have a brim or raft selected. This prints around the object, so if you would place the object at the edge of the buildplate, it would print the brim/raft partially outside the buildplate. To get the fullest buildvolume, you need: - adhesion type = brim - brim line count = 0 - travel avoid distance = 0 - horizontal expansion = 0 - support horizontal expansion = 0 (if support is enabled) - draft shield disabled - ooze shield disabled - infill wipe distance = 0 Note that in most cases brim with brim line count=0 will get you most of the way there

It would be very helpful in fixing this issue if you could zip up the C:\Users\Allinger\AppData\Local\cura folder and make it available for download somewhere. In all likelyhood, you can get it running if you rename C:\Users\Allinger\AppData\Local\cura to C:\Users\Allinger\AppData\Local\cura.bak.

Look into OctoPrint/OctoPi: http://octoprint.org With the OctoPrint plugin for wifi, you get a pretty seemless experience printing directly from Cura to the printer (no more dealing with gcode files). https://github.com/fieldofview/OctoPrintPlugin

This has been fixed in Cura 2.3.0. You are using Cura 2.1.3 Yeah, unfortunate numbering, I know.

No, there is not. It may return in a future version. Both my printers are detected just fine, so it is hard for us to improve this without being able to test it.

Note that I'm only talking about travel speed in the start and end gcode (ie: while starting and finishing the print), which should have no effect whatsoever to the print quality during printing.

This is planned for a future release.

How badly do you need the travelspeed in your start and end gcode to depend on the setting you can set in Cura? Why not simply hardcode the value in the start and end gcode?

What if you use F{speed_travel} instead? In Cura 2, many of the variable names changed (for consistency). See the names in fdmprinter.def.json Edit: ow, wait, you're already doing that.

The final 2.3 will support uploading custom firmware (I am not sure if the official 2.3 betas already do).

> Layer view speed Could you post the model somewhere so we can see if we can reproduce this? > Settings saving This was fixed last thursday. The fix will be part of the final Cura 2.3 > Concentric infill Concentric infill is a feature that is just not going to work for all types of models. It is up to the user to decide on the best infill pattern for the model. > Double walls Do you have an example/screenshot of this?

We're sorry about the 2.1.99 confusion. An internal build seems to have gotten posted to the public server by accident. The good news for you is that it has a number of fixes in it that the official beta doesn't have. That bad news is that it has some other bugs, and it says that it is 2.1.99.

For 2.1.x, look here: https://github.com/Ultimaker/Cura/#making-profiles-for-other-printers For 2.3, select the Custom FDM Printer when adding a printer. It will give you a window where you can enter the most important values for your printer.

We've been in "string freeze" for a little while now. That is the phase of development where all the strings in the application have been sent to a translation agency, so we cannot change or add strings (which means we cannot add or change features, etc). The last couple of blocking bugs are being fixed. That means we're close, very close to a 2.3 release. We can't say much more than that.

Note that Windows 10 IoT is not going to be helpful in getting Cura to run on the raspberry pi, for two reasons: 1. Windows 10 IoT != Windows 10; Windows 10 IoT does not come with a desktop environment. 2. Windows 10 IoT does not run x86 binaries, so you would not be able to just run the binaries supplied by Ultimaker. If you want to run the full Cura (frontend + engine) on the Raspberry Pi 3, your best bet would be to get the sources for all the components, and build them for the ARMv7 architecture under raspbian or the like. Start here: https://github.com/Ultimaker/cura-build