jaysenodell

If you’re asking that question, don’t try it. App image is the official method for cura use in Linux. Just use that. Keep in mind I’m a nerd who plays with systems for fun (and a paycheck). Cura is not a trivial code base. Make sure you understand how general code building tool chains work before tackling cura. Then be prepared to read, build, fail, troubleshoot, reread, build, fail, troubleshoot, repeat. Patience and asking questions the right way will get you there. not sure it’s worth the effort though.

So... in the old school days, local was a generic fall back for non-standard installed stuff. /bin, /sbin for core OS, /usr/bin, /usr/sbin for system level "add ons" and "user space" stuff. We used /usr/local for third party and self rolled things. There would typically be all the standard directories in there (/etc, /bin, /sbin, etc). Then pure user space files lived in $HOME (because on nis/nix plus, home were often fun things like /users/j/jo/jodell which then mapped to /net/jodell and/or /home/jodell or, my favorite way to torture the not so innocent developer, /net/srv/$HOST/export/$USER/home/insecure/shared (where they had to know which host we happened to create use for their workgroup)(moral .. don't fork with your sysadmins by pretending you know how to directly access raw devices len... otherwise your home direcory gets hard to find and your pasward expires every 8 minutes). Move that into modern *nix and you get a mishmash of file standards about how to properly store user space configs. The POSIX (and I think SYSV) methods would be that software should look in $HOME/.<app>/<vers>/etc $HOME/.<app>/<vers>/local/etc $HOME/.<app>/<vers>/ $HOME/.<app>/etc $HOME/.<app>/local/etc $HOME/.<app> $HOME/etc/<app>/<vrs> $HOME/etc/<app> $HOME/local/etc/<app>/<vrs> $HOME/local/<app> $HOME/<app> /usr/local/<app>/etc/ /usr/local/etc/<app> /usr/local/<app> /etc/<app>/<vers> /etc/<app> I may have missed a directory or ordering in there, but there are standards that "should be" implemented. I'm not going to fuss over it, but linux development is notorious for "we do it our way" which is why I'm not a fan of app impage and prefer building from source when I can. Or just using Mac.

*tentatively aises hand* yes please? I accept all responsibilty for the damage to my sanity and relationships. the problem with people thinking for themselves is that many of them are ... how do i say this nicely... forking morons. That's as nice as I can say it. I'm not saying I'm smart, so when I think your stupid, things are bad.

So two points (because I have a few seconds to reply) Orientation is to minimize potenital for layer separation as force is applied in the "arms" and to reduce the need for support. The infil is just "there" becuse I didn't set it to "off". This thing just hold the rop light onto a ... thing (in this case dock rail). The only strength should be avoiding the sag of gravity on one side of the prong thingies. That said... i should play with patterns. not sure it matters unless I'm using translucent media though.

So I looked back at my notes and my files. From that we can make the following conclusions: 1. You are consistent in this advice. 2. I saw this advise and noted it. 3. I am a forking morning as i didn't follow it IN MY PROFILES. I have no idea how I have managed to get PETG to work prior to this. I'm going with dumb luck. As you can see from the project I attached, the temps and flow are low EVEN THOUGH I HAVE A NOTE TO SET THEM AT THE VALUES YOU PROVDED HERE. A new run with your values and ... oh look at the pretty Yellow PETG object on my build plate! Forking moron living between my ears. I'm going to make an attempt to SAVE THE DAMN PETG DEFAULTS THIS TIME and see if I can stop asking the same questions repeatedly.. Now... while I'm marking this solved by the temp and line adjusts, and I did change my speeds to match yours, When will you be providing "slashee optimized profiles" for starting points for us noobs? Yes yes yes... they will need tweeked for machines and jobs, but clearly I failed at builging my own from scratch.

I've replaced the corrupted file with the file that works.

Not at the he system to validate, but that is a 5.6 project that was used to load several times. If there’s errors mesh tools isn’t complaining very well anymore. I’ll have to try opening it in 5.7 tomorrow as well.

It’s a thingiverse STL and shows no errors in 5.6. I forget the thing id and I’m not at my system right now. I’ll check it again in the morning though.

I don’t like the fact that octoprint just unlock an achievement “must be one of those days” for canceling 10 consecutive prints in a row.

I mean anyone is free to comment, but let's face it, @Slashee_the_Cow must have 20-30 of these creality printers and she LOOOOOVES to deep dive into optimizing print profiles. Slashee, I need your assistence in rationalizing print settings for PRTG (Creality brand but same issue with a random spool that I already tossed). Based on previous slashee wisdom I immediately recognized my blobs as "SLOW THE FORK DOWN" and have been able to get solid prints by just tweaking print speed. But with this last one, I'm down to 10mm and that's just stupid for PETG (and I need to print a pile of these things). The big question is : My failing project is attached. ---- Things I know are right: * Printer is solid. no issues printing this in PLA at 150+ don't ask, I was just seeing if it would work. * Bed is clean * Temps are the same I've been using for this PETG on other projects Thing I know changed * The other projects are printing as nice now * OSX and multiple cura versions don't play nicenice so the 5.7 install may be messing up my 5.6 PETG settings? * It's summer but rel humidity is still 90-98% every day. * New noz (same brand but swapped muitiple) and recalibrated after each swap. * New octoprint server (moved from pi 3b+ to n95 with way more speed/ram, but coppied all config objects) Refresh on my systems nonsense * Creality ender 3 S1 Pro, firmware vs 24S1_301_SWV2.0.8.28F4_F401_FDM_LASER (creality stupid name) from their site * Octoprint 1.10 on Debian 11 (n95, 3.9gHz/8G/256G), Python 3.9.3 * Cura 5.6 on MacBook Air 13 (i5, 1gH/8G/500G) OSX 14 0.5_inch_rope_light_clip_04_PETG_Standard_Quality.3mf

Rel is the same though. You just track the shift between abs and rel and then overlap the models. Now if you start dealing with WCS and need to track all 6 or 8 possible origins then you can get grumpy. 😛

Octoprint doesn’t slice. You misunderstand the entire purpose of the software. There is a plugin to talk directly to octoprint from cura. You need to research things a bit. Just search for the octoprint in the plugins section. I don’t think you actually understand systems as well as you think you do. You use a lot of buzz words but your last post leads me to believe that you either don’t actually understand these tool chains and workflows or you are not actually implementing them… just doing white paper studies of them. Maybe it’s a language barrier thing and there’s a translation issue, but your entire “wrap in a website” and “does rudimentary slicing” is entirely male bovine manure. I hope utilimaker can mark this thread as containing significant disinformation and exclude it from search indexes. The internet is not better with it existing.

Did you know you can accidentally format an sd card with riser fs if you don’t pay attention on one of my playgrounds? Enders don’t like riser fs sd cards.

Some don’t like folders, spaces, only specific file extensions, require specific folder structures, use custom file extensions , and on and on and on. you need to tell us a bit more about your set up including the printer and computer (with os).

click the object in the SLT, then scale it down by 1000. make sure uniform scaling is checked. What software was the STL created in?

I’m be been thinking about this. I’m assuming the corners are actually walls being printed as single extrusion. Meaning the nozzle is moving though the 90deg while extruding with no stop. I noticed that infill just prints straight lines overlapping at the intersection. I wonder if a grid infill with the right wall density would get you better 90s. Not sure the other properties would suffice, but perpendicular lines meet at perfect 90s.

Look @Slashee_the_Cow!!! I didn't say it!

Attempting to repair a sweing tool for a neighbor. I feel this is a bad idea as all the ladies in her group are sitting there with "out of distribution" tools in various states of disrepair... This may be creality quality issues, but what I ran into was that a 0.4 snoz could not reduce the flow enough to prevent closing the gap. A 0.2 managed my 0.15 gap just fine. That said I am relying on "slashee speeds" of "dear god, I could carve this from stone faster!!!" to keep things straight and stuck together. I also had to make sure fans were cranked to for PETG to cool fast enough at the corners to avoid pulling/smudging. See, I've been listening and learnging. Your pontification into the dark recesses of issues pay off! At least for me 🙂

I may be silly, but a small nozzel will let you do thin lines. Thin lines allow thin gaps. The big things in my experience will be slowing way down and running cool/cooling so that the corners stay tight and don't merge. I know @Slashee_the_Cow, what the heck am I doing using small nozzels? i don't know, but I don't like it. I do NOT like it!

I notice you mention blender... I use freecad. i don't get any notifications unless my models are completely unusable (which is more common than I care to admit). maybe the problem isn't in Cura?

@Slashee_the_Cow, the reason I recommended octo is that @chriska416 mentioned the pi in the original post. I assumed (dangerous) octo was involved but it is not mentioned explicitly. my concern with using startup is that it’s not a printer specific embed that might be lost due to an upgrade or system clean. Same is true on pi/octo but most folks are a bit better about backing up pi/octo. Also, you can also in any gcode that is known to work from any date/config without needing to reslice. so yes, sledgehammer, but a very useful one. Less of a sledgehammer if octo is already in the pipeline.

Look into using octoprint to intercept the bed heat ups and replace with the right macro. There’s a section in the octo configuration screen for just this purpose. a couple hints. * read up on storing a variable for the temp so you can put in logic to differentiate between raising and lowering temps. * simpler is better for the above… I’d lower just drop it. * alternatively play with fire and create a hardware solution that switches between ups sourced power and direct line power for bed heating. I like fires. You should probably not do that…

@Slashee_the_Cow, G28 X Y then M114 will tell you the neg limits of XY (limit switch). My e3 has the same mechanical stops to prevent self disassembly. I was hoping for a limit switch style “far enough” set up to protect components. Probably need big dollar printers for that. Or I’ll build them into one. I really enjoy how you jump into all the details. When I grow up I hope to be that passionate about things.

@Slashee_the_Cow, in octo, home x and y. Read the actual position of the head. On the e3s1p it’s -12,-12. 15 (Z wasn’t homed). The edge of the pei plate is right about -8. I can print down the edge fairly easily. Cura sees hardware 0 as 0 still leaving 16mm of plate unused. Cura took another 10mm off that. The e3s1p will gladly grand the belts past the upper and lower limits. You you have stepper shutoff switches?

On my e3s1p the default bed is 5mm shy of full all the way around. This x-3 may be intending to use that buffer to prime/purge while allowing full use of the configured space for printing? Problem is I’m smart enough to resize my bed to get all my space back so… that would be bad. only other thing I could imagine is if they set machine coordinates to offset 0 to the max size of the print. But I don’t see that. Or any transfer to an alternative coordinate workspace. Me thinks thou protest to much on the G0/G1 fiasco. While technically accurate the only real value is if you are setting travel speeds as a universal in G0 then not resetting speed with every move. Since cura insists on setting speed in every motion… I’m not sure it hurts anything other than our desire for adherence to the rules. All said, I agree. Cura output should FOLLOW THE RULES!