Jump to content

boogieman

Member
  • Posts

    10
  • Joined

  • Last visited

Everything posted by boogieman

  1. The search bar is very slow on my linux system. I always found the search to be slow and i'm wondering if this is normal. I takes over 10 seconds to show all settings again after a search. I made an strace log for the situation seen in the .gif. It doesn't explain where all the time is going but it is rather strange that there are over 28'000 failed file stats. There are also a lot of repeated file accesses to some .svg files. Seems like unhiding each line repeats the same file operations over and over again. I'm wondering why there needs to be file access at all for just unhiding the settings. Cura version 4.13 > sudo strace -f -p $(pgrep -x "cura" | cut -f1 -d' ' | head -1) -c strace: Process 1175945 attached with 18 threads ^Cstrace: Process 1175945 detached strace: Process 1175967 detached strace: Process 1175968 detached strace: Process 1175969 detached strace: Process 1175973 detached strace: Process 1175974 detached strace: Process 1175975 detached strace: Process 1175976 detached strace: Process 1175997 detached strace: Process 1176028 detached strace: Process 1176029 detached strace: Process 1176030 detached strace: Process 1176031 detached strace: Process 1176032 detached strace: Process 1197003 detached strace: Process 1200372 detached strace: Process 1200373 detached strace: Process 1200374 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 40,74 1,673923 334784 5 select 24,64 1,012515 2033 498 ppoll 23,89 0,981555 1810 542 poll 6,66 0,273611 136805 2 1 restart_syscall 3,19 0,130973 4 29289 28121 stat 0,39 0,015935 2 5587 access 0,19 0,007663 1 6900 clock_gettime 0,11 0,004584 1 3680 getpid 0,06 0,002333 1 1850 sched_yield 0,04 0,001537 2 556 44 ioctl 0,01 0,000559 4 127 24 futex 0,01 0,000557 3 146 read 0,01 0,000541 6 86 3 openat 0,01 0,000535 3 150 fstat 0,01 0,000479 3 152 close 0,01 0,000447 0 530 getcwd 0,01 0,000282 6 46 mprotect 0,01 0,000219 4 44 madvise 0,00 0,000148 8 17 mmap 0,00 0,000146 8 17 memfd_create 0,00 0,000138 4 29 write 0,00 0,000129 1 79 recvmsg 0,00 0,000078 2 32 recvfrom 0,00 0,000065 3 17 ftruncate 0,00 0,000058 7 8 sendto 0,00 0,000051 0 52 socket 0,00 0,000044 2 18 lstat 0,00 0,000038 2 15 lseek 0,00 0,000024 2 12 getdents64 0,00 0,000021 5 4 writev 0,00 0,000004 1 4 setsockopt ------ ----------- ----------- --------- --------- ---------------- 100.00 4,109192 50494 28193 total cura.strace.zip cura.strace.zip
  2. This solved the problem: https://github.com/Ultimaker/Cura/issues/2452#issuecomment-613903842
  3. Finally, its solved! Thanks guys. This has shown the way and has lead me to http://perlstalker.vuser.org/blog/2011/12/19/setting-default-monospace-font-xfce/ My Problem was somehow in the $HOME/.fonts folder. There were some monospace fonts (.ttf and .otf) of some older Powerline installation. I just got rid of the folder and now the squares in the GCode section are gone! Powerline seems to work as before. 🙂
  4. here they are. The cura.log is just a copy of both stderr and stdout, i guess. What i forget to mention is that i tried to see the file accesses of both the user and root program run. But i couldnt find something promising with lsof so far. I also tried strace which didn't work because it makes cura freeze. But i'm not experienced with strace so i don't know if you could give some valuable information. stdout.log cura(shortened).log
  5. Hi @smartavionics, here are my settings. CFFFP_ring_255_16.3mf
  6. I almost spent two days now figuring this out, but i don't know how to fix it. The problem is i see squares instead of text in the custom g-code box. I run Cura 3.6 under ubuntu 16.4 with xfce window manager. If i start cura with admin rights i can see the text just fine. Any ideas?
  7. Cura 3.6 (and maybe earlier also) has a strange behaviour. It changes the direction of the wall in situations where it is completely unnecessary or even detrimental. There is a simple test object on thingiverse: https://www.thingiverse.com/thing:3439448 It is like it would bounce of an invisible barrier and change the direction, which causes an ugly seam. Continuing in the same direction would absolutely be possible in this case. Slic3r for example does exactly that. No settings in Cura seem to influence it. Does anyone have how to change this behaviour?
  8. Hi there, this is a feature proposal for Cura or a wish for next christmas ?. I haven't found anything on the forum or elsewhere on the net. I think it would be really nice to have a feature in cura that is like the "variable extrusion sizing" in Simplify3D. This would be great for: small details in the print automatically select thick line width for infill or other areas where resolution is not needed, which speeds up the print better print quality at corners / tips, i.e. the tip is filled with line that is decreasing in width better print quality at "tunnels"/spaces between walls that dont exactly match the line width, i.e. a thicker line instead of a wiggely one In cura you can set the infill line width separatly from the wall line width, which is nice but only covers a part of the addressed issues.
  9. The skin are the topmost layer, so the "skin overlap" is the overlap between the wall of these layers and their filling. The "infill overlap" is the overlap between the wall and the infill, i.e. inside the object/ below the skin. In the shell section you talk about, there is the setting for wall overlap compensation. This is for reducing the extrusion in areas where the print head has to go over twice while printing the wall. (see ttps://ultimaker.com/en/resources/20415-shell)
×
×
  • Create New...