Jump to content

burtoogle

Expert
  • Posts

    1,529
  • Joined

  • Last visited

  • Days Won

    19

Posts posted by burtoogle

  1. Thanks for the file. The problem is that the model consists of 6 meshes. You need to merge those separate curved side pieces into the main model to make a single mesh.

    Here's a close up of the meshes, you can see that the triangles that make up the curved side piece are not integrated into the main mesh.

     

    Screenshot_2020-06-29_21-48-23.thumb.png.8893f766e800c4868c20c6d326b01385.png

     

    And here's Cura's display with one of the sub-meshes highlighted.

     

    Screenshot_2020-06-29_21-45-52.thumb.png.98fc029e44e6eef2b1c81f91c9cdc0cf.png

     

    You should install the Cura Mesh Tools plugin from the marketplace to get the ability to check meshes and split them.

     

    Unfortunately, I don't know if Cura can merge these non-overlapping meshes so it would be best if you did that before loading the model into Cura.

     

     

     

  2. 56 minutes ago, Adam324 said:

    Has anyone taken the time to find settings to make it behave close to the original settings but just put fan at 100% during bridging? 

     

    Just set all the bridge wall/skin speed/flows/density to 100% and the bridge wall coasting to 0%. Turn off bridge has multiple layers. I think that should be sufficient, I don't have cura in front of me right now, sorry if that's not quite right.

  3. 3 hours ago, mkoic said:

    I was wondering why Cura defaults to line width = nozzle dia?

     

    For at least some of the UM printers, the default is 0.875 * the nozzle dia, so for a 0.4 nozzle, they use a line width of 0.35. I guess they must have evaluated different line widths and decided that is what works best for them. On my non-UM printers I still use a line width of 0.5m (with a 0.4mm nozzle) unless I really need a thinner line for some specific model.

    • Like 1
  4. Hello @saxonpaul92, what I mean is that tar file should be unpacked with a command like "sudo tar xf mesa-20.1-date.tar.gz".

     

    As mentioned above, there's a problem with running that 32 bit AppImage because it requires some 32 bit system libraries to be present. It's probably possible to gather all the required libraries from a 32 bit Pi but that is an experiment that I am not going to do (yet) because I don't have any Pi 4's running the 64 bit OS and I won't be bothering until it becomes more mature. At the very least it has to support VNC server which I don't believe it does yet.

     

    I expect that I will do a 64 bit release for the Pi 4 but it won't be for a while.

     

    Finally, as all the source code that my releases are built from is freely available (of course), it doesn't stop anyone else from building a 64 bit release using that code.

     

    • Thanks 1
  5. Hi @kentisevil, I may make a 64 bit release in the future but right now I don't have a 64 bit OS installed and I think I will wait a little for it to mature before I try.

     

    Is it worth copying all the files in the /usr/lib/arm-linux-gnueabihf directory on a 32 bit installation to the 64 bit machine and adding that to the LD_LIBRARY_PATH? Maybe also need some from /lib/arm-linux-gnueabihf as well?

  6. Thanks for the gcode file. Near the bottom of that file it has this:

     

    G1 Z250;        Move bed to 250

     

    AFAIK, RepRap/DWC calculates the number of layers in the print by looking for the highest Z value and dividing by the estimated layer height, hence the 2499 layers. Perhaps someone on the Duet forum can provide a solution?

    • Like 1
  7. I understand that SketchUp is notoriously bad for creating models that have problems. Install the Cura Mesh Tools plugin from the marketplace and use that to check your model for watertightness.

    • Like 1
  8. Hello @netminder, thanks for your feedback, it's nice to know one's efforts are not wasted.

     

    Now,  bridging. I think it's always a compromise in the sense that it is difficult to get super tidy bridges with minimal artifacts introduced. The fundamental cause of problems with bridging I think stems from the fact that in the bridge region (walls and skin) you often need to use quite different speed and flow and fan than is used for the rest of the model. Big changes in print speed and extrusion rate are always going to introduce artifacts into the print. e.g. if the bridge wall is printed slower or has a lower flow rate than the non-bridge wall there will be a tendency to over-extrude at the start of the bridge which can cause a loop of filament drooping down right at the start and then at the end of the bridge, the wall that follows will tend to be under-extruded which will leave a visible indentation which may extend for many cm around the model.

     

    The default values that you get when you enable the bridge settings should produce reasonable bridges, at least with PLA.

     

    What exactly are the problems you are seeing? Got any photos? Perhaps you could attach a sample project file that isn't working as well as you would like?

     

×
×
  • Create New...