jazzychad

Wow, magic. This works!! I was waaay overcomplicating it. Thank you! Next issue is, seems like the prime tower is printing black (and white) on all the white-only layers all the way up, which seems unnecessary... I guess the prime tower isn't strictly necessary in this particular case, but is there a way to improve it?

To give the concrete example, I have a piano keyboard model. I tried multiplying the model, then adding a support blocker as a cut mesh to each instance which would prevent the "wrong" portion of the model from being printed in that color. So far so good, but if I try to merge or overlap the models to align the keys, the support blockers of each overlap the other model and everything cancels out, leaving nothing to be printed!

Let's say I have been given an STL model to print (i.e. I am not the designer of the model and don't have access to the original design files). This model is supposed to be printed in two colors, and the instructions say to do a filament change at a certain height. I know I can do an actual filament change (using the post-processing plugins), but since I have an Ultimaker 3 with dual extruders, I am trying to figure out if it is possible to use Cura to slice the model such that it uses one print core for the first X layers, and then uses the other print core for the remaining layers? Yes, usually for dual extrusion you have two models and merge them together, but in this case I only have one model file and the color change is completely in the vertical direction. I have tried doing various things with duplicating the model and using support blockers to "selectively" print part of the model for each print core, but that doesn't seem to work (unless there is a way to do this I haven't discovered). Is there any way to do this?

For the last several weeks the Cura Connect Print Jobs page - http://192.168.x.y/print_jobs - has been stuck showing me the same finished print and never updates with new print jobs. In the networking console I looked at what http://192.168.x.y/cluster-api/v1/print_jobs/printing is returning.. it's showing 4 jobs, and the one it's showing on screen is the first one in the array (the J_relief_-_Part_1_1 job). The fourth object in the array is my actual current print job, but I guess the Print Jobs page only shows the first one returned? Anyway, I've done dozens of print jobs since this started happening, and it's strange that these first three seem to be "stuck" being returned from the /printing endpoint. Is there a way to clean these up?

And if you want to see the actual CAD project, here is the Onshape link: https://cad.onshape.com/documents/4899a3f9c6be77ec2f1168ab/w/2cb57853ef162ccce58c4fce/e/0f13698b1078e5af565662e3 Must get some sleep now.. thanks for all the help so far!

Looks like there may be a few cross-wall travels, but not exactly sure... I'm attaching the STL files here in case you want to play with them also. MuniFaceplate Dual Color - Faceplate.stl MuniFaceplate Dual Color.stl

That's what I thought. Luckily I had just tried that, and it worked! Here is what I've found for this particular print with your fix branch (I can't print the model again until tomorrow, so this will have to do for now): Pre-fix (latest master): Post-fix (your branch): I will try this print again tomorrow with your branch... looks promising!

Argh, I build the CuraEngine from source and I am getting this error when slicing... (I am using latest 3.3.1 Cura frontend app on macos... do I need to build a more recent one from source?) 2018-05-27 00:57:09,557 - DEBUG - [Thread-23] UM.Backend.Backend._backendLog [90]: [Backend] [ERROR] Trying to retrieve unregistered setting with no value given: 'support_wall_count' 2018-05-27 00:57:09,557 - DEBUG - [MainThread] CuraEngineBackend.CuraEngineBackend._onBackendQuit [765]: Backend quit with return code 255. Resetting process and socket. 2018-05-27 00:57:10,528 - INFO - [MainThread] UM.Backend.Backend._onSocketError [201]: Backend crashed or closed. 2018-05-27 00:57:10,530 - DEBUG - [MainThread] UM.Backend.Backend._createSocket [213]: Previous socket existed. Closing that first. 2018-05-27 00:57:10,532 - DEBUG - [MainThread] CuraEngineBackend.CuraEngineBackend._terminate [276]: Attempting to kill the engine process

Will do @smartavionics .. back to my original question, which lines in the layer view mean a retraction will happen? (or, if the colors don't indicate that, is there a way to visually inspect when a retraction will happen before actually printing?)

Thanks @smartavionics, that makes sense. I have found the PR (#781) and will try it out from source. Hope it gets merged!

@smartavionics I saw you posted something related in another thread about No Skin combing being troublesome.. is this what you were seeing as well?

Now that the print is done I can show you what I mean. I have Combing set to "No Skin" but no retraction is occurring and I get these travel lines (I do have retraction enabled) Here are is the Line Type layer view for the top layer Here is the finished print

I am wondering what the different colors of travel lines represent when viewing "Layer View > Line Type" There are Light Blue/Lavender lines and Dark Blue lines. I am guessing one is a retraction move, and one is a normal travel move. Which is which? (I have a guess, but I am seeing some odd behavior with Combing set to "No Skin" and no retractions happening at all in the skin layers...)

@cjs howdy! I'm not sure how I achieved this. I haven't manually edited those values in the sidebar. It says 70 mm/s no matter what profile I select, even tho (presumably) they have different actual values than that. Any info or logs I can provide to help diagnose?

In the sidebar, all of the profiles' Print Speeds and Infill Speeds say 70 mm/s, but those speeds show differently in the Preferences->Profiles screen of Cura; I'm worried there may be other settings like this which mismatch the actual Profile values. Has anyone seen this behavior before? Screenshot is from 3.3.0, but the same thing happens in 3.3.1 as well.