Jump to content

Adam324

Member
  • Posts

    89
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Adam324

  1. Thanks for the reply. I have been baffled trying to figure out where to 'Select the modifying cube', I don't see that anywhere in the GUI. Anyone know a youtube or article describing that? I am aware of multi-object settings but that is only enabled when there are multiple objects.
  2. I was going to test this but it appears the Z-Offset plugin in the marketplace can not be enabled in 4.0.0 yet. I assume th plugin needs to be updated or maybe the marketplace just doesn't work yet. I depend on Z-Offset.
  3. I print some big objects that need to be sliced to fit on the build plate and then glued back together. The infill and outside walls are usually plenty to glue to. I try to use the no bottom layers feature but that has consequences for other areas of the object if the object has bottom layers further up on the object that need support. They don't get bottom layers either. It would be great to have an option to not print bottom layers only for parts that touch the build plate. I could then get no bottom layers on the build plate (infill and walls only) and still get bottom layers up higher that need support and then just glue my parts together.
  4. I take that back. I just had the problem again today. It was up to 3.2 GBytes.
  5. Make sure you update Octoprint in the plugins(Marketplace). Maybe it matters even if you don't use it but it is enabled. My main memory issue went away when I did that.
  6. It is seems to be communicating with the printer through Octoprint. I can send another print when this is happening based on previous experience and the printer status updated when the print was done. I haven’t recorded memory usage for that scenario though.
  7. Cura crashed yesterday night likely from memory issue. I did another test today and found out where memory starts climbing about 2MBytes in both private and commit memory until it consumes all memory. I created a manual Cura.DMP crash dump file (using task manager) before I quit the app if you want it. If you have a way to look at the crash dump, you might be able to see what memory is leaking. If you want the Cura.DMP file let me know. It is 2.7 GBytes and 1.8 GBytes in a compressed .zip file. Cura 3.6 beta with octoprint plugin enabled but with video/pic disabled so that it doesn't show video. Memory values are shown in MBytes Time Memory private/commit Description 9:25am 407/666 MBytes First launch 9:27am 406/665 Loaded large Snake https://www.thingiverse.com/thing:1776785 9:28am 407/665 Sliced 9:30am 407/655 added post processing Pause at height (Octoprint) after layer 5 and sliced 9:31am 418/547 added post processing Pause at height (Octoprint) after layer 46 and sliced 9:44am 409/536 was sitting idle from 9:31am 9:45am 420/545 After sent/print to octoprint (Now in Monitor view) 9:55am 417/550 No interaction and sitting at Monitor view since 9:45am 12:12pm 142/633 No interaction and still sitting at Monitor view since 9:45am 1:28pm 164/700 No interaction and still sitting at Monitor view since 9:45am 1:35pm Switched to Prepare view (nothing else was done) ---- memory starts climbing about 2MBytes/sec from here in both private and commit memory 1:38pm 598/1050 3 minutes After I switched to prepare view 1:41pm 905/1425 6 minutes After I switched to prepare view 1:43pm 1232/1772 8 minutes After I switched to prepare view 1:45pm 1535/2070 10 minutes After I switched to prepare view 1:47pm 1720/2260 12 minutes After I switched to prepare view ---- Still continuing... it seem like it would keep going eventually consume all memory ---- I created a manual cura.dmp ---- Quit the app
  8. Thanks. I didn't wait long enough the first time. It only showed uninstall but after a few seconds it shows update. I saw uninstall only the first time and just exited the window before update appeared. It will be interesting to see if the memory issue comes back.
  9. I have been using the 3.6 beta and see no memory leak at all now. I have printed a few things and have left it running for a day now and it is still at 260MB private memory and 387MB Commit size. I noticed that Octoprint is disabled though. It shows as unchecked in the Marketplace/plugin but does show installed. If I check it and reboot it stays unchecked. I was always printing by sending it to Octoprint from Cura before using 3.6. It would be great to be able to test it with Octoprint again to see if the memory issue comes back.
  10. After a few prints, It does seem that the big memory leak that occurred within a short amount of time of sending a print to Octoprint (5 to 10 minutes) is gone. There is still a long running memory leak that occurs in the 'Commit size' memory assigned to Cura but I am uncertain if that has been there before or not (I will have to test 3.4 sometime). After a few days of it still running, the private memory is at 199MB but the 'Commit size' is 3322MB. You have to enable the column for 'Commit size' memory in Task Manger under 'Details' tab. By default it is not shown so you might think it is only using 199MB but in reality it is using 3322MB plus 199MB. I bet this is why the extreme commit usage over time hasn't been detected yet.
  11. I just did a print sending it to Octoprint and left it on Monitor view and it completed without any memory issues on my system using the new OctoPrintPlugin... curapackage provided in the last post. I will keep testing but this is the first print that has not caused memory issues on my PC leaving the Monitor window view up. Initial test looks good so far ?. Thanks!
  12. I unchecked 'Show webcam image' but it still shows the webcam video. I even restarted Cura. It is unchecked but the webcam video is still streamed. Memory leak still occurs too.
  13. It happens for me with a machine that was imported from previous version. It is repeatable every time I launch Cura. I plan to test the 'don't show video' thing when I am home later today.
  14. I tested the official 3.5.1 and there is still an extreme memory leak when printing via Octoprint. After I launch a print to octoprint, a couple minutes later my system becomes unresponsive. Committed memory ends up consuming all swap space (virtual memory in windows terms I think). Cura starts increasing in regular Memory for the Cura process before system is unresponsive and also consuming committed memory which is not a visible column in task manager by default. You have to right click on the column title in Details view in Task Manager and enable commit. This is with Windows 10 and 16 GB of memory onboard. This is a picture after finally getting control back after I assume the system started doing something to Cura or Cura did to get things under control again because of low memory. Cura went back down in 'Memory' and I assume Committed too but committed is still around 6.8 Gigabytes. If I switch to Prepare view quickly, the memory consumption stays where it was. If I then switch back to Monitor view which shows the video, it starts climbing about 95 MBytes/sec. EDIT: When I have time I will submit a bug to github if nobody else has. Work has me consumed right now.
  15. No since in showing negative feedback toward developers. Heck... even Microsoft with all it's deep pockets to hire the cream of the crop gets things wrong. They had to pull 2 separate patches this month. One for deleting users files and another because it was making HP desktop PCs either needing a restore or a full reinstall depending on how hard they were hit with the driver bug. We experienced this where I work and it was not fun. We need to encourage and not discourage. The software up to this point has been working really well for me. I have been experiencing issues but I have been using smartavionic's Gyroid alpha master build so I can't verify that any of my issues are in the 3.5 official build but i have been experiencing memory leaks when viewing the 'Monitor' screen after initiating a print through octoprint. It is severe when it happens and locks the PC up. Interestingly, if I catch it before it freezes up the PC, I can click on the Prepare tab and watch the memory go back down. If I switch back to the 'Prepare' screen before leaving the PC it doesn't seem to leak memory from what I have seen so far. That again is a non-official build so I can't comment on the 3.5 build even though it was compiled around the same time as the 3.5 release went official. I probably shouldn't even mention the behavior because of that really. One thing I hope Cura devs do is start releasing more beta builds for us to test before they release a final. Maybe that can help catch things like this. The more eyes the better. I do understand that it would likely increase the work and time that releases are done though.
  16. Yea. You have to put the blocker up in the hole as that is what it is probably trying to support. If you only show 'Show Helpers', It is strange that it just stops. It is not obvious it is trying to go up higher. Definitely looks like a bug of some kind. I tested it on 3.4.1 also and that support doesn't appear on 3.4.1.
  17. When I have seen things like that in previous versions, there was a small hole or crack that the tower was trying to help. Sometimes it would go through the object if there are holes and end up trying to support something further up. It was always issues with the source object when I saw that though.
  18. I loaded a model that fits inside the bed at 80% size (207.7 x 290.4 x 74.6mm on a 300x300x400 bed) and used Arrange All Models but Cura 3.5 says it is unable to slice because it doesn't fit. I had previously figured out that 80% size would fit with Cura 3.4.1 and I am able to slice it in Cura 3.4.1. Reducing it to 80% and with it centered on the bed, Cura 3.5 just gives the error about not fitting the bed. If I look all around the object it is definitely inside the bed area and I used Arrange All Models to make sure. Here are pictures of 3.4.1 and 3.5 as well as the STL file. 3.4.1 that doesn't give the fit error. This is 3.5 and gives an error about unable to slice. Here is the STL. top.stl
  19. Splitting models that have multiple in one STL will be really nice. That will save a lot of time that would be spent loading up into meshmixer to split them when you need them separated. Sometimes models are so close and so many that a straight line cut isn't possible so it can be tricky splitting them in meshmixer. Nice work! Looking forward to it. Let me know if you want some extra eyes testing it.
  20. I use Octoprint with the Octolapse plugin (easily installed through GUI). It uses USB cameras to take pictures and create a video. It automates moving the head to a specific spot after each layer, takes a picture, and creates a video after the print is done or fails. Raspberry pi 3+ is around $32, A case and power supply is around $13 including heat sinks. You need an SD card but most people have a ton of those laying around. Well worth the investment IMHO.
  21. Updated to v1.3 to fix a major issue with it not working properly. I put an incomplete copy of what I was working on in the zip on accident. It was missing an import of UM.Application in the code.
  22. Updated to v1.2. I synced to pull in changes to the original pause at height script upstream in github. There was a bug fix to the original pause at height script as well as some minor sentence changes to the config settings. From the github bugfix in github: https://github.com/Ultimaker/Cura/commit/6740c2bee9a0732daf77224cd4ef34f0eb736364#diff-3e58768c03d7c85bf31b60e0ed2d51eb
  23. There is also the scalable extra prime plugin that you can install. It allows a range of extra prime based on distance traveled when not extruding and you can optionally enable extra prime for all movements... not just retractions. You really need a few prints that exercise movements (without extrusion) to close, medium, and far distance to get it dialed in which can take some time. Different types of filament ooze out at different rates though. I tend to just print regular PLA of the same brand though so it works for me. Maybe that feature should have settings per filament chosen. EDIT: Note that the scalable extra prime plugin doesn't work (doesn't change extrusion amount) until you use an object that has somewhere around 15 or 16 layers (don't remember the exact number) for an object for some reason based on my testing. I don't know if that is on purpose or a bug.
×
×
  • Create New...