ahoeben

Sure! I use the Tinkergnome firmware on a UM2 from Cura 2.3. Note that I use OctoPrint (using my OctoPrintPlugin), so I have switched my gcode flavor to RepRap. Note that in 2.3 it is possible again to flash a custom firmware such as the Tinkergnome firmware, so it is easy to switch back if you find a problem with it.

The start-gcode is an issue for both the UM2 and UM2+ printers (my bad!). It will be fixed properly in the upcoming Cura 2.3.1 so the fix by @reweum should not be necessary anymore. @DaHai8: I have added an option not to show the webcam stream. This is a fairly bare implementation; you have to reactivate the printer or restart Cura for the option to take effect. This should be fixed properly with an upcoming release of Cura.

The only thing that would influence cleaning the folder would be if Cura was still running. Make sure Cura is not running, move/rename/remove the folder and start Cura again. That should do it.

In all likelyhood, uninstalling/reinstalling will do nothing. The problem probably lies with the data C:\Users\[you]\AppData\local\cura, and that does not get touched when uninstalling/reinstalling.

Installing again was not necessary. Could you zip up the renamed folder and post it somewhere so that we can figure out what is happening?

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).