rimbo

Final evening trial, I think, shows that's not Z wobble at least and that barely decent surface is still achievable on this printer... Project file based on clean Cura default Draft profile, then top layer removed, Wall line count 1, infill removed. (E steps 180 ; changing to calibrated ~185 again tomorrow) One of the initial knobs on the left for comparison. Zwob knob F-5 Radar projekt 01 16-05-2024 evening.3mf EDIT: Also Z wobble test towers with banding that has barely anything to do with Z wobble. Also Flow Rate % in cura from 100 to 120 showed no discernable differences. Further, RAW G-CODE test cubes shipped with the printer from factory. The semi-transparent one is almost 1 year old. The gray one is from today. While the seam is massive and I don't remember whether I used E steps 180 or 195, the walls are very nice, with no trace of wobble influence. kostkaNowaLUME.gcode

Aim: Please help me home in on the culprit causing waviness of the side walls Cura 5.6.x / Cura 5.7.x (currently) My printer is a smoothieware LUME+ https://lumeplus.wixsite.com/lume/produkty In February this year I refurbished my bootleg printer and got amazing results. I calibrated eeeeverything... Ot one point some heavy irregularities started appearing. Analyzing my photos I can see that the problem comes in and out. Recently it's all I'm getting unfortunatelly! Take a look at the Squid model and the Ultimaker bot. Those are perfect for a printer worth probably less than $100. But there's a glimmer of hope. I noticed some of my test pieces today came out without those irregularities! Note: The green knob has been printed with an extreme layer >height< of around 1.25*nozzle0.4 INITIAL knob or that - left console Bc knobs and holders projekt 2c the big knob Ironing ON - Copy.3mf INITIAL knob this - left console Bc knobs and holders projekt 2b the big knob Ironing ON - Copy.3mf Z-wobble_test_Duplicator_7_DLP projekt 2 z knob F-5 Radar projekt.3mf

The fact that I don't need most of the prominent octoprint features and I do need Printrun (Pronterface) has given me an idea: I should test printing via USB with Printrun. I think I haven't mentioned it - my printer has no functioning Ethernet module. I even tried the jumper soldering method described on Smoothieware github.

See? That's a useful piece of information. I thought someone would be interested in reviewing the log so I could assist further ending in, hopefully, an issue entry. Since it's "if it works, it works", I'm going to continue priming Cura with Printrun. I do many small prints. USB connection getting alive for me with Cura was a godsend. It saved me hours upon hours and is probably the only reason that printer hasn't ended up in a scrapheap yet 😄 Also, the issue is new. I've been using USB for the past 2-3 months. The issue started surfacing just this month.

Whenever I'm trying to use Cure over USB without first establishing a connection through Printrun the USB connection is lost in the following way: - print job continues - bed and hotend heating is disabled - Pause and Abort buttons are greyed out - no controls work in the MONITOR tab - the extruder motor obviously stalls as it is commanded to feed the filament completely cold cura.log I've completed *multiple* print jobs yesterday, between 30min and 1h30min each yesterday. Today I wanted to confirm whether it was all my imagination. I'm pretty sure it wasn't. I'm not interested in advices against using USB. I know my setup, I know my use case. My printer is a smoothieware LUME+ https://lumeplus.wixsite.com/lume/produkty

Thanks for chiming in. I did just that and I'm testing currently. Is there a way to extract pure text printer definition out of a 3mf project file? If so, one would be able to just feed it to https://github.com/Ultimaker/Cura/wiki/Definition-Files-Explained

This is my biggest gripe with Cura, right from the start. Over the months I was figuring out the right offset and head polygon settings to finally have it how it should be. Now each time I reach for an older project file I risk literally damaging my printer if I fail to remember to verify and MANUALLY re-enter the correct values in a cumbersome interface (it takes multiple clicks to even get there plus it manifests some quirky behavior). Is there a way to override this?

How can I change the display name? https://www.thingiverse.com/<username>/edit#makerbot_account_settings field "Username:" Right now I get error 404 when I click Save.

Id gladly mark this thread as solved but it isn't. To quote my previous post: It will often refuse to slice due to "bed overcrowd" triggered by no other but the damn modifier blocks.

What if one faces a case like mine - the bed is level to "piece of paper tight between the nozzle and the bed" yet printing always seems to start a whole layer too high?

You speak wisdom, through and through. But you seem to be missing that part. I do ignore them. Cura doesn't! It will often refuse to slice due to "bed overcrowd" triggered by no other but the damn modifier blocks. @GregValiant Wow, thanks! Is there a "know workarounds thread" with pieces like that somewhere?! On that note, do we have any means at all to influence the printing order? I've been testing for an hour to only one cocnlusion - it's all random.

@Slashee_the_Cow I don't mind the physical limitations. After all my print polygon assumes printing tall models. The head itself is of average size in my opinion. Especially that almost the entire hotend fan fits right under the stepper motor. By helper blocks I mean the non-physical blocks e.g. support blockers. They should not affect the physical size of the printed model. They should shrink it if anything! And yes, I created them as support blockers first. "In your second last picture (the one that shows the "unable to slice" error), your models are too close together. " There may be some confusion with the stl because it has a pair of earings as one, so they are both printed as one model. To achieve "One At a Time" printing I blocked 1 earing in each pair. The part I underlined is my main gripe here. Cura 5.6 I've attached the project from the OP, as well as another project I think I did pretty good with as far as packing goes. That said look at the actual printing order, what the hell! 🙂 cardboard_rivet_washer projekt 2.3mf Earring_Honeycomb_noSupports projekt.3mf

Cura extends the collision zones unnecessarily, considering helper blocks as physical objects.

Thanks for sharing the postprocessor! A solid piece of work. Carrumba! I've just noticed I've got only the following settings visible Fan speed Regular fan speed Regular fan speed at layer But there's another! It was hidden in my installation, what the hell?! Initial fan speed Now I can use: Fan speed 100 Regular fan speed 100 Initial fan speed 0 Regular fan speed at layer 2 And this should work. I'm going to print some delicate models soon so it's going to show.

I'm not a developer but to me it's hardly "intended". The "Regular/Maximum fan speed threshold" should only affect the transition time between the speeds. In my mind my setup should be interpreted to "Up to and including layer 2 inhibit the fan to 0 RPM, then run at full RPM". The threshold should apply only around layers 2-4 or something like that. In the current implementation however, how do I alter the setup to achieve my intended behavior? "Up to and including layer 2 inhibit the fan to 0 RPM, then run at full RPM" While we're at it, it is worth noting that the fan speed settings are reversed! If I put Fan speed 0 Regular fan speed 100 at layer 2 the result will be: layers 1-2 fan speed 100 layers 3-... fan speed 0 At least from my experience. I might refrain from using those settings altogether to see whether Cura applies some automatic sensibility now 🙂

Resliced without changing the previous settings. New 3mf and g-code attached. Do you have some g-code analyzer better that allows you to make a quick "at a glance" scan on a G-Code. I think Prusa has a g-code line preview while viewing G-code in UI. I haven't seen anything like it in Cura. SCP_xyz20Calibration_cube1278865 N04r02 FORUM comment-328234.zip

Wait, so actually Cura devs don't consider it a bug?! https://community.ultimaker.com/topic/44613-cura-55-turns-off-fan-for-top-layers/

I still haven't got an auto update notice? Does it even work?

I've seen it already but it was pretty clear while printing the 20 mm XYZ calibration cube. Cura shut down the fan completely for some 10% of the top layers. I could clearly see the entirety of the infill rising up. In other models, especially for dome-like shapes the tops may turn out as outright gaping holes. Printer https://lumeplus.wixsite.com/lume temps: bed/nozzle 60/200 Generic PLA xyz20Calibration_cube1278865 N04r02.3mf G-CODE xyz20Calibration_cube1278865 N04r02 t200b30-60 fan0-100od2war wLc2 t14m 3g.zip

THIS is the answer I was looking for! Thanks again!

But that's not how I roll 😄 I'm going to compromise on the insanity and fiddle with the firmware only after I print all the files I need for the project I bought the printer for in the first place.

That link is golden as well! I have only seen singular pages of SR. BTW, I failed FW upgrade once and I reverted to the first ancient FW from like 2017 from the printer manufacturer. Was I lucky or is reflashing old smoothieware versions a standard operating procedure? I'm asking because it's tempting to try to flash a firmware that is 5 years newer than the one installed.

Thank you all so much! A nice change from constant ghosting or having a legitimate issue marked as spam in some other forums! Here's the fixed link for my curious Polish startup printer ;) https://lumeplus.wixsite.com/lume That link for smoothieware definitions JSON seems interesting. I don't know what it is yet though :)

Hi! I've got an MKS SBASE v1.3 smoothieware based printer called LUME Plus that is not in the printer list of any slicer software I know of. I have Marlin G-Code selected right now. Should I change it to something different? There's no "smoothie*" on the list. https://lumeplus.wixsite.com/