ahoeben

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

Out of curiosity: what's wrong with OctoPrint? There's also AstroPrint, which started as a fork of OctoPrint.

Try G1 F{speed_travel} instead. For all the parameter names, check https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json

The beta has a bug that caused the configuration from Cura 2.1.x not being properly converted, leading to errors. In both the supplied logs I see symptoms of this problem. Could you rename or remove the C:\Users\YourUsername\AppData\Local\cura folder an try again? Unfortunately you will have to reconfigure your printer.

Note that in the 2.3 beta, the print job name prefix has been made optional. There were users on the plant that wanted the feature, others did not. We listened.

Please give us a bit more to go on: What OS, what printer? Did you try only one model, or different models as well? Can you zip up the logs and post them?

When you first set up the software, you were using a previous version (2.1.3?). The Nozzle Setting can no longer be made visible in the sidebar with any version of 2.3. This is by design.