jazzychad
-
Posts
26 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by jazzychad
-
-
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.
-
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.
-
I use Onshape for my modeling, and you can export parts as STL file.
Right click part -> Export -> select STL format and Download option
Drag STL file into Cura
-
I am having some trouble with merged models in Cura 3.2.1 (Mac 10.11.5) - using Ultimaker 3
By way of example, here is what I'm doing:
I am printing some letter tiles. I have several .stl files, but the main process for each tile is:
- add Tile.stl to the build plate
- add {Letter}.stl to the build plate
- select the Letter and change the Per Model Setting to Blue PLA (2nd extruder head)
- select the Letter and the blank Tile and right click -> Merge Models
- Cmd-click the Letter inside the merged model and change the Z position to be correct (so Letter is raised above tile: Tile is 5mm tall, Letter is 3mm tall, but set Z position to 4 so 1mm is 'inside' Tile and 2mm stick up)
Repeat for each letter, and you get something like this:
Now, normally when things are merged correctly the slicing will result in the dual extrusion interface to be printed starting at layer 18 (as seen in next screenshot) - except that sometimes it doesn't! This can be seen in the 2nd column of tiles which only show printing the triangular infill
More curiously, it looks like both extruders are printing in all the layers where the 2 models overlap for the 1mm inside the tile, the screenshot below shows what would be the top layer of the tile, and the 2nd column is again different from the 1st and 3rd column of tiles.
Sometimes if I just move the merged model around the build plate enough it will magically slice it correctly. I haven't found any pattern or steps to reliably reproduce this behavior. It seems like a bug to me, but maybe I am misunderstanding something or am adding too many separate models to the plate..?
Another clue that they aren't quite merged together correctly:
- If I select a correctly merged model and press Backspace/Delete key, it will remove the model from the build plate.
- If I select an incorreclty merged model and press Backspace/Delete key, it will NOT remove the model from the build plate... but if I right click and select Delete Model, only ONE of the pieces of the merged model is deleted, and the other remains on the build plate.
So, it is acting as if the two models are just existing in the same space, and are somehow grouped together b/c I can move them around as a group, but they are not being sliced as if they are a merged model.
-
Update: Hooray, it appears fixed!!
I received some excellent technical help from fbrc8 - it turns out the printhead cable (w/ 10 colored wires from the printhead to the Ultimainboard below the printer) became unseated and was only loosely connected, which caused the intermittent I2C errors.
After reseating the bracket and the cable inside the printhead everything seems to be working properly again!
-
1
-
-
Hi @SandervG - thanks for the reply! I would happy to reach out to a partner or trained support engineer.. how would I find the right person/people to contact?
-
Hooray, the error page url works now, but says only this:
This error refers to a communication error in the printer. Since there can be several causes for this, we recommend to first reboot the Ultimaker 3 by using the on/off button.If this doesn’t resolve the issue, then please contact one of our local service providers for assistance.
Since I have turned on/off several dozen times at this point it looks like I will need to reach out to a service provider (or if there are any other logs that would be helpful here I can provide them. I haven't enabled Developer Mode; not sure if that provides any extra information).
-
Hi @SandervG - my printer is still experiencing I2C communication errors with almost any operation. It is effectively unusable at the moment. I would love any advice from your engineers
-
The connectors on the BB core (and inside the print head behind it) are pristine. But since I have material loaded into the AA core, and I get the error when trying to unload it, I can't actually take the core out to inspect the contacts :(
-
Are both cores mounted properly? Check it especially on the upper end.
Yes, I'm fairly certain. Are you thinking the contacts in the back of the cores aren't touching like they should w/ the print head? I made sure to push them back as far as I could to ensure contact.
I did manage to load material into PrintCore 1 and do a quick print using only PLA... as the print finished and the bed lowered, again the "I2C communication error" displayed.
After that I restarted and tried to begin another print ~10 times, but each time as the print started it would have the same I2C error.
-
Ok, eventually powered off the printer, restarted and successfully updated to latest Test Firmware. Then I took out print cores and reinserted while off as @neotko suggested.
I still get the "I2C communication error" message when doing any Material/Printcore load/unload/change procedures.
Log files here: https://www.dropbox.com/sh/dn0mywt5b9ny5um/AADEnQso3zrqIEwpo4c939D3a?dl=0
-
I am attempting to install the newest Test Firmware (it already had the latest Stable installed). It has been on "Installing new firmware... Do not power off printer" for ~20 minutes. I don't remember it taking quite that long to update during initial unboxing/bringup... How long should I wait before I get worried?
Two color print with dual extruders and only one model file?
in UltiMaker Cura
Posted
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?