zBeeble

I have the DuetRRF printer module loaded. I'm running on win10. I've attached the cura.log. Moving the print sometimes fixed it with 5.6, but does not fix this one on 5.7. Actually... this cube (made in openscad with "cube(20);" as input, slices infinitely. If I pause it and then unpause it, it finishes with the error. The settings are the same as 5.4 and none of them are red. cura.log CalibrationCube.stl CFFFP_CalibrationCube.3mf

So... I run Cura 5.4 just fine. I have a custom printer that I built myself. Roughly following the pursa mendel format and running with Duet2wifi electronics. When I upgraded to 5.6 and now again when I try 5.7, I get this (this is the calibration cube from the Extensions -> Parts for Calibration menu ... but it happens equally with a part that I made. I used the calibration cube so that nobody needed to ask or examine my own part ... for whatever problems it might have. ... so note that it's not indicating any config item. I strongly suspect that the duet printer plugin has something to do with this error ... but I don't know where to start debugging. Another thing ... even under 5.4, after printing at least once, the interface zooms in some random amount and will no longer zoom out past that amount. I don't know what sets the level of zoom, but it means that I re-run 5.4 a lot to be able to look at the part.

So... I'm working on hand compiling Cura --- I want more recent versions running on FreeBSD, and there seems to be no reason why there shouldn't be. w.r.t. that, I'm trying to deal with an error (coming out of protobuf) that is failing due to the compiler being c++11 rather than c++14. I've got it inserting the compiler argument -std=c++14, but I also see it inserting -std=gnu++11 For the time being, I've pulled this out of the FreeBSD ports world and am trying to manually get this going. Once I understand this, I can more aptly make the port work. Anyways... that's the long and short of it. If there is a more apt forum, please direct me. If not, let's roll up our collective sleeves.

After the problem occurs, there is a problem with zooming out --- in other words, a too small maximum distance from the camera to the object.

So... Doing even better today. I'll link in a project file. So... the Otyugh here is best printed on it's side. In general, the teeth are not something you want to support (easy to break) ... but printing it in this orientation on the deck --- only a small part is initially on the build plate. Now, I think there's a problem with using a raft ... so I instead I just decided to have something that is all supported. It works amazingly well. Watching it print, as I sometimes do, there's an obvious change from the big round shapes to the many little fingers in close proximity to the print. This is done well enough that different parts of the print are held accurately enough to join. CFFFP_Otyugh Updated.3mf

OK. WOW. Revelation. I make many smaller models (for a weekly in-person D&D game) ... and this new support regime is ... just WOW. It's easier to take off ... it respects smaller details ... everything is just better. Was printing some Kobolds today. even smaller than usual. Just WOW.

All I can really say in this is that the amount of available zoom changes. It's quite adequate to start and it's very restrictive (leading me to exit and restart) when this happens.

The point is that it's the same with an item on the plate and annoying. I was just trying to eliminate the criticism that the model could be at fault.

The problem is: in that video I'm still spinning the wheel. That's it for zoom until I restart. I can't get any further away from the part.

Hrm. It appears that this happens when I select the part right after printing with the duet printing plugin.

A little more detail. Cura is often staying running on my laptop. This morning, I came downstairs and got to starting a new print. Sometimes, instead of CTRL-N, I select the current item and hit delete. So after running idle overnight, I selected the item and it jumped to the zoom amount that it then won't pass.

Here is a video. https://nextcloud.towernet.ca/s/M3SibPJkrz9JMmF What you're looking at is my laptop. I don't print every day, so it took me awhile to get back into it and to have the bug manifest. What you're looking at here is a video taken on my phone of the laptop cura just after I hit CTRL-N to clear the plate. You'll notice me flicking the zoom in and out --- and the "in" always stops at the same point --- which is uncomfortably close. Then I exit cura, and restart it. After restarting it, I load some zombies and try the zoom --- fixed again. This happens often. CTRL-N is a common cause, but other cura commands cause it too.

urm... so do I need to report this bug there too, or is here sufficient?

I've printed a lot of minis from this particular modeller... I'm a patron. Some of his early works cause Cura complaints, but regardless of error, Cura shouldn't be doing this. Here's the 3mf file. I don't have MS 3D builder. CFFFP_Jackalwere.3mf

So... I'm having a bit of trouble with a miniature I'm printing for my D&D group. I decided on this attempt to use a raft because on a previous print, a couple of the supports had failed to stick to the build plate. Anyways... the print was a complete failure. When I went back to Cura to make some changes, I think that I see why... there's a curious and large difference between the outline of the model and it's actual position. This leads to a large gap between the support and the model. This gap seems to be something along the lines of the thickness of the raft.

Do bugs get acknowledged here? Do we just hope someone notices?

So. firstly, kudos. Awesome stuff. All that. Little bug. When I use cura, if I perform certain actions, and not every time, like say "new project" the camera position is reset. That's fine, but what's not fine is that it will now be limited to how far away I can zoom it. This would be a noise level issue if it weren't for the move mechanic where the arrowheads that perform the action are long enough that they're often offscreen if I don't tilt the camera to some crazy angle to access them. Right now, my work around is to restart cura. I'm running 5.2.1 on windows 10 on two different machines. One has a GTX 3080, the other has both intel integrated graphics and a quadra 2000 --- and the application is set to prefer the 2000.

Actually, reading this again, I have more to add. So... if you have 10 downloads, maybe you have 2 professional-home-educators, 3 home-professionals, 2 home-educators, and 3 plain professionals. You're asking people to self identify in 2018 ... which means, like sex (where there are a _lot_ more than 2 kinds now), people do all kinds of wonderful things with their printers. Once could say your trinary pigeon holes are antiquated and looking at your question as a set of axis is more appropriate for the times.

I've attached my new bath knob. Permissive commons license and already on thingiverse. I was watching the print (3D printers can be so mesmerizing on a lazy Saturday)... and I think I detected one place where Cura can do better (although I don't know if I know where to twiddle... is this possible with a plugin? I'm happy to roll up my sleaves if I'm not wasting my time. I figure this is pretty common. The hole narrows in the middle. It's wider on both sizes and there are good reasons not to fillet (basically... the screw supplied with the original part wouldn't fit properly for one). Your first reaction is that supports would make it print 100% successfully. I'd say supports are hard to remove in there... but also, the current behavior is so close ... it just seems cura can do a tad better... If you print the knob with the outside surface down (seems the sensible way), the hole starts at 12mm and narrows to 5.5mm (I know 'cause I made it). On the first layer of bridging, it starts fine ... going across from the edge of the circule out until it is printing the part of the smaller circle that isn't a contiguous bridge... which continues until it is again. This dumps that non-contiguous material down the hole and leaves two side bits almost-ok. On the next pass, we almost get it right where the 2nd bridge layer is 90 degrees to the first ... and you get the square part of the circle-square being almost right... but still, on this pass, more material down the chute. If you were amazingly smart about this, I'd imagine the best way would be to print this as a series of tangents to the inside circle that began and ended on the solid outside circle. If you were less smart about it, printing the two 90 degree edge bits on the first pass, you might not be dumping the circular inner walls down the hole. Thoughts? BathKnob v6.stl

Doesn't my education count? Really. I learned, for instance, what a PID controller is... and how they're quite common in our lives. A fascinating diversion is how PID controllers were originally constructed as pressurized air devices and used to hold a heading on ships. See... learning... thus I was educated (allbeit by myself, the internet and the practical experiment of building something that works). I don't recall all the items in the list on your survey, but I remember thinking that some would imply the others. That it wouldn't make sense, say, to say you were prototyping without saying you were designing your own things. Maybe you need people to "rank" their uses. I'm actually in favour of you guys getting _more_ information. Yeah... sometimes I do. I've downloaded it multiple times and I'm not sure how many times you want my information. Sometimes I even want to download it without the use of a browser. In general, I like to live by the rule that I only answer surveys when I receive some value in kind. Good news is that you've already qualified in my mind. Your application is well-done and useful.... easily worth a few surveys and some information.

It's entirely possible that I'm not a normal 3D printer user. I've been curious about the technology for some years, but I"d been to busy to really invest. Some of you might balk at that statement, but I stand by it --- my very nature is to treat every opportunity as a learning experience. When I finally had time, I researched things on the internet, ordered things on eBay and set about building my printer from scratch. Along the way, I learned about many things. I'm fairly happy with my first effort. And by that I'm not talking about the first thing I printed, but my first printer. I definitely plan to build a more sophisticated printer in the future. And before I get into the meat of the post, I'd like to say that I fully appreciate Ultimaker/Cura for releasing their slicer to the open source community and this post is not IN ANY WAY trying to pour rain on that effort. That-all-said, the surveys are getting to me. The choices are not good. Education _or_ personal _or_ work. Fairly, I would say all three. In my short time as a 3D printer owner, I've made prototypes for work, learned much about how 3D printers work and made some birthday presents. Similarly, I'm asked to choose among prototyping, production, .... and a bunch of things I forget as for what I'm making. I want to honestly chose about 80% of the answers, not one. I don't have any problem at all with your survey-on-download approach, I'm just bummed by your survey. I'm forced to pick random answers that don't really reflect what I'm doing...

OK. I've beaten down a bunch of errors. There's two things I can't get past. If I checkout the git tree, and after making, there's no option to make install or run in place. I have a different tree checked out that has a cura_app.py to try to run... but there I get: [2:114:414]dgilbert@canoe:~/Cura-master> LD_LIBRARY_PATH=/usr/local/lib/gcc6:/lib:/usr/local/lib ./cura_app.py [MainThread] cura.CrashHandler.show [36]: An uncaught exception has occurred! [MainThread] cura.CrashHandler.show [39]: Traceback (most recent call last): [MainThread] cura.CrashHandler.show [39]: File "./cura_app.py", line 69, in <module> [MainThread] cura.CrashHandler.show [39]: app = cura.CuraApplication.CuraApplication.getInstance() [MainThread] cura.CrashHandler.show [39]: File "/usr/local/lib/python3.6/site-packages/UM/Application.py", line 340, in getInstance [MainThread] cura.CrashHandler.show [39]: Application._instance = cls(**kwargs) [MainThread] cura.CrashHandler.show [39]: File "/home/dgilbert/Cura-master/cura/CuraApplication.py", line 154, in __init__ [MainThread] cura.CrashHandler.show [39]: ContainerRegistry.getInstance().addResourceType(self.ResourceTypes.QualityInstanceContainer) [MainThread] cura.CrashHandler.show [39]: TypeError: addResourceType() missing 1 required positional argument: 'container_type' ideas?

Qt is actually fine. KDE runs well and I've used Qt in projects ... both in python and C++ on FreeBSD. It seems the previous version of Cura was ported to BSD, but whoever did that has moved on.

Well... an appimage might run if I fired off a VM running linux. The linux emulation tends to work fine for binaries that you can run, but the sheer volume of libraries this requires is unlikely to be less work to run under emulation. Besides... its written primarily in Python. The C++ part is already ported (and seems like it was easier to port). I realize that portable software can be difficult to write... but we're dealing with the low-hanging fruit here --- it's written in python. argh. I suppose one big problem is that I'm not familliar with cmake and while cmake exists on FreeBSD ... whatever this cmake does is broken. More tomorrow, maybe.

So... I'm a fairly competent ports maintainer for FreeBSD. I see that someone has already gotten the CuraEngine ported. I thus have been working in the direction of getting the Cura graphical front end going. So... is anyone else working on this? It almost seems like the job of porting things written in python is made nearly impossible by their build systems. I think I have all the requirements built... but I'm still getting rather dumb output from cmake. Help?