DrinkWater

Ok, googled a bit more and found out. Apparently Cura ignores M140/M104 commands in custom start code if you use these variables. Even though they are correct and working overall. They're just being ignored by parser that decided whether it should insert heating commands or not. According to this issue, I need to use {material_print_temperature_layer_0} and {material_bed_temperature_layer_0}. I tried, it works properly. Cura recognizes these variables in custom start code as heating commands.

Hi. Having the same issue. Cura ignores that I set M140 and M104 commands into the "start code" and still adds these commands BEFORE custom start code. What I wanted to achieve is to start heating up nozzle and the bed at the same time, home the nozzle and then wait for target temps. Instead of waiting for the bed, then waiting for the nozzle, then waiting for the homing. I'm using similar thing to previous message: M140 S{print_bed_temperature} M104 S{print_temperature} do things M190 S{print_bed_temperature} M109 S{print_temperature} Variables are different than previous message but they're correct, according to result. So Cura still inserts its default heating code, which is start heating the bed and wait, then start heating the nozzle and wait. Cura 4.6.1, Windows.

Making small quick prints during printer tweaking. Lens hood for Sony 5018/1855 lenses and compatible. Download: https://www.myminifactory.com/object/3d-print-138468 https://grabcad.com/library/lens-hood-for-sony-5018-oss-short-25-mm-1

Ok, I checked other suspect and figured out that my pre-built firmware for the printer was really garbage. I was trying to do that before but just now made it work. Meantime I was figuring out why vase mode has no issues. That's why I suspected Cura. My bad. Thank you gr5 and GregValian. I asked these questions in other places but nobody gave me anything even close except here. Also I found out that when you use TFT24/35/whatever screen, it processes the g-code and sends commands instead of letting the board process it (unless you stick SD card into the board instead of the screen). And constant connection and data transfer has own issues - it makes main board choke on commands and skip movements if the path is very detailed (many points per mm). This is why direct lines show no issues. So apparently Marlin devs trying to fix that, as I heard from random rumors. And they might succeed, since latest Marlin 2 don't show this problem for me. But I still will print from on-board SD slot instead of on-screen one. Here's comparison after flashing proper firmware with fresh Marlin 2. Models a bit different but it doesn't matter. Since I shared testing model file, it is lens hood for Sony 50 1.8 OSS lens and compatible. Just in case.

No such issues. I checked it recently. And also I didn't change anything related to belts, motors and rails with wheels between now and when it was printing without this issue. Right now I'll try to build the firmware for this board and see if it changes anything. Excluding things step by step. It's weird that it prints vase mode and direct lines in regular mode properly.

I was using 2 walls of 0.4 mm so for in and out surfaces it made 3 walls total at that area, without filling it with linear movement. I didn't expect someone to print it and figure out the issue. Thanks for helping with this investigation. I can't use 0.6 outer line for all the prints. And I remember that it was working without this issue earlier. There's a lot of things that can be different in your and my settings and I don't know which to check.

I'm using this one. Did they fix the main bug in 4.7? BTW, what is the best format to use for Cura? Does it only support STL and 3MF? 112.3MF

Thanks for suggestion. Tried now. Doesn't affect the issue, but didn't make anything worse. Previously I tried jerks at different numbers but not 20 (tried from 6 to 12). 50 mms. I want to make it print as good as vase mode. And the only visual difference will be z-seam. Would be great.

I would understand if there was any geometry deviation. But there is no deviation and inconsistency in geometry. It is circular walls. Also model exported in 3MF to avoid ugly triangulation with STL. I suspect that neither Cura or Marlin 2 supports arcs so it's still getting split into direct lines. By 3MF I'm just trying to minimize amount of splitting it into lines. I suspect that it's not the point of bad model and bad triangulation. It's made in SolidWorks, so it's not a mesh. I saw posts about something similar caused by a bug in Cura 4.7 (that's why I didn't update), but I'm using 4.6.1 and this effect is not that pronounced. Attaching screenshot of speed in Cura. Looks even. I don't understand why vase mode prints perfectly. If there's issue with gcode line buffer, it would affect vase mode too - during 1 full line it have to have more than 16 lines considering it's a circle, not a rectangle.

Hi. Just came here and haven't found anything similar. So I'm having this weird surface on printing in regular mode. But printing in Vase Mode shows that there's no issues with hardware (printer is ok, anyway). In this example it is black PLA at 190 deg, printing speeds are 40 - 70 mms (tried different, doesn't matter). Straight lines are better. The issue seems to be in inconsistent movement during printing. I can see it with eyes, the nozzle moves by the even arc, movement should be consistent because there's no deviations, model is cylindrical (using 3MF files, no insane triangles like in STL). Anyway, at random places nozzle moves faster than in other places. No consistency or correlation with geometry. No dependency on printing settings; only in vase mode it prints nicely and evenly. Printer: Ender 3 Pro with SKR Mini 1.2 DIP + 2208 UART; TFT24. PLA at 190 deg. Cura 4.6.1 First photo - issue; second photo - example of vase mode.