Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

Personal Information

  1. 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?
  2. 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!
  3. 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
  4. 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!
  5. 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
  6. 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?)
  7. Thanks @smartavionics, that makes sense. I have found the PR (#781) and will try it out from source. Hope it gets merged!
  8. @smartavionics I saw you posted something related in another thread about No Skin combing being troublesome.. is this what you were seeing as well?
  9. 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
  10. 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...)
  11. @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?
  12. 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.
  13. 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
  14. 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.
  15. 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!
  • Create New...