burtoogle

Within the next hour a 20200525 release for Windows-64 should be on Dropbox. It heeds the user-defined z-seam hint position when outputting surface mode lines. YMMV.

I did do a test where the surface mode lines took into account the user-specified z-seam position and it worked for most of the lines in that model but not all. As I mentioned somewhere (on github, I think), something weird happens around layer 215. Anyway, I can make a new release with that change in if it would be useful.

However, looking at the code in CuraEngine, it appears that in surface mode the lines in each layer can either be closed loops (aka polygons) or they can just be lines that don't join up. The polygons will be printed taking into account the z-seam position but it appears that the lines ignore the z-seam position. Perhaps that could be changed, although it's not immediately obvious what the right strategy would be.

So, to recap, the problem is that the Pi 4's graphics hardware does not have enough resources to render the lines in the same manner as more powerful hardware can. It can display the line segments as 2d slabs rather than the 3d diamonds that is normal but as you see above, when viewed from the side, the slabs have no thickness. I came up with a solution that works surprisingly well, it flips the orientation of the slabs as you change the view angle. So when looking at the scene from above (or below) it renders the lines as horizontal slabs. That's what is being done in my previous post. But when you look at the model from the side, it now renders the lines as vertical slabs. Obviously, as the view is tilted it flips from one orientation to the other but, it's not that disturbing and looks better than it sounds! Anyway, if anyone wants to try this out, today's (20200523) release has this feature. You need to use replacement graphics libraries that I have packaged into mesa-21.tar.gz. Download and unpack that (sudo tar xzf mesa-2.1.tar.gz), it puts the libraries into /opt/mesa-2.1 so it won't overwrite any existing system files. All feedback is welcome.

Here's a tease of what I have been working on recently... Yes, it's the simulation view running on the Pi 4 with working layer and line sliders. It doesn't look too bad from that angle but, unfortunately, looking from the side it is rather ugly... So it's not really the full 3d view, but rather, a 2.5d view. The problem is that the Pi 4's graphics hardware isn't as powerful as most "grown up" computers and it's running out of resources when trying to render that view. I'm still working on it and haven't given up hope (yet) but it may be that a 2.5d view is the best it can support. I will make what I have here available in a future release. Stay tuned...

There are several ways that plugins can be installed. The easiest is to install it from the Cura marketplace dialog.

It's probably because the model isn't watertight. Install the mesh tools plugin from the marketplace to get these warnings...

It does save the settings into ~/.config/cura/master/cura.cfg. It also writes to files in ~/.local/share/cura/master.

That's not my work, try @ahoeben.

It catches people out all the time, that's why!

Reduce the min layer time in the cooling settings?

Thanks for the project file. One possibility is that because the top/bottom speed is lower than the wall speed, it will tend to overextrude compared to the walls. That is because unless your printer has non-linear extrusion rate compensation (most don't I believe) then as the extrusion rate increases, you get more and more under-extrusion. So, you could try an experiment and use the same print speed for walls, infill and top-bottom layers and see if you get more consistent thickness. Hope this helps!

Sorry, that's not a project file, please do File->Save, not export. Thanks.

Hi @zqk, please save the project file (File -> Save) and then attach the .3mf file to this thread so we can see your model and settings. Thanks.

On linux look in ~/.config/cura and also ~/.local/share/cura and ~/.cache/cura.

Hi @tinkergnome, thanks for that input!

Yes, although there's a lot of differences between those files, I can't see anything obviously bad in the 20200510 file.

Thanks for the gcode file. When I look at that, I can't see any gcodes for setting the temperatures, is that because the printer handles all of the temperatures (and also the prime in the left hand corner)? Otherwise, the gcode looks pretty much what I would expect.

Hello @EvilHag101. I've never used Cura to drive a printer using USB so I can't really help there. Have you tried using a different program to send the same gcode to the printer? Have you tried octoprint?, pronterface? Anyway, could you please attach a sample gcode file produced by 20200510 to this thread so I can check it looks sane? Thanks.

Hi @Smithy, thanks, glad you like it.

My guess as to why a single model could possibly be considered manifold but replicated models fail that test is due to rounding errors introduced during the model position/orientation transformations. @fieldOfView, do you think that is possible?

The manifoldness is determined long before walls and infill are created so the settings for walls and infill make no difference to whether a model is manifold or not. I guess it could be possible that some wall/infill settings could make a non-manifold model print acceptably.

Setting combing to "not in skin" helps

UM are working on their own solution which should see the light of day soon...

I think there's a clue in the last lines shown in the error message above. It's got some permission error trying to open a log file. Please make sure that the AppData\Roaming folder exists for that user and it is writable.