GregValiant

It's gotta be a setting in Octoprint. Look through the menus and see if you can find M666 which is gcode for "screw up this print". Good luck. I'm sure you'll find what's going on. 3d printing with its gcode, complicated slicing software, and a fussy printer that insists on falling out of tune all the time is enough for me. That's why I don't want to add any more complications like Octoprint or AutoLeveling. As for firmware, I fall back on my personal rule number four which is NEVER upgrade an operating system.

The plug is an over-engineered cork that holds the hydraulic oil in the reservoir. Refilling the oil got the top moving again. The reason that it needed a refill is that the lift cylinder seals leak. I'll watch another dozen videos with a plan that involves printing new seals for the lift cylinders. I have a feeling I should also search for replacement cylinders after my experience with the plug. Pathetic really. It was Phyllis Diller who said "Getting old ain't for sissies." She was right.

Right now I think that your printer has a very low probability of being the problem. There are no firmware retractions in the file and printers only do what they are told. Have you tried printing the file using an SD card instead of Octoprint? If it prints OK from an SD card then you can totally eliminate the printer. You don't have to print the whole thing, just enough to troubleshoot and then you can abort. As I said, blobs can also be caused by the print head stuttering. Just to be clear, you have watched the extruder moving the filament backwards and forwards (retracting and priming)? I don't know Octoprint but is it possible there is a setting within it's interface that could be generating retractions (that would be a slick bit of coding)? Is there a possible data hiccup in your setup that is slowing down the data transmission and causing stuttering?

AHoeben is the expert on this but there may be a couple of things you can try. I use the USB connection for controlling printing from the SD card in the printer (rather than sending gcode files over the USB from Cura which I've found to be glitchy). I haven't had a problem with USB communication through Cura updates from 4.6 through 4.10. I have used Cura USB Printing for troubleshooting posts like this one and Cura has no problem finding my Ender 3 Pro. I have my own app for printing and it uses the Cura port driver. There are a few things you can try to troubleshoot. I believe I understand at least a little of what USB Printing is doing to find a printer and I'll try to explain. With Cura open - click on Marketplace in the upper right. It can take a minute to load. Click on Installed and scroll down to USB Printing and make sure it's checked. Since USB Printing hasn't been updated in about 3 years it would be wise to make sure the only device plugged in to a USB port is the printer. I would use the same physical USB port that you know has worked in the past. When Cura starts it checks the operating system list for a port with a serial connection (in Windows it checks Device Manager). If it finds one listed it opens the port and it runs through the different possible baud rates and asks for a temperature check each time. When it gets a response it understands it populates the Monitor screen. If there are no satisfactory ports then the routine stops. 5 seconds later it checks again in case you have plugged in a printer. Since it checks the operating system for a port the port must be configured as USB-Serial to be noticed. That means the correct driver must be installed. With the printer connected to the computer then Device Manager would say something like: USB-SERIAL CH340 (COM5). Some drivers install on only a single physical USB port and connecting to any other USB port on the computer is not noticed (that happens in Win7). Other drivers adapt themselves to whatever USB port the printer is connected to. Understand that the Monitor in Cura can take up to a minute to populate so don't give up on it after only a few seconds. When you installed 4.10 you should have allowed the port driver to install as well (I think it's the Arduino driver in the installation dialog). I run Windows so you would have to figure out what works in Linux or on a MAC. I hope this gives you a start on things you can check. The USB Printing utility in 4.10 should be identical to the one you had working in previous versions.

I bought the wife a 2004 Mustang convertible. Nice car with only 50,000 miles (that's 80,500 kilometers for most folks...176,000,000 cubits for us old guys). The convertible top quit working (of course in the down position). No problem, U-Tube to the rescue. I watched three different videos until I get to the proper year. They had this one thing in common so I saw and heard this three times... "Take the rubber plug out of the back of the reservoir being very careful not to break it". So here is the thing I made today. A rubber plug for the reservoir of a convertible-top motor of a 2004 red Mustang convertible. Now you understand the title of the post. (Three times I saw it!) PS: I got the top working right before the rain. I guess it is better to be lucky than good.

I think a flogging is in order. .02 lashes will teach em.

Mouser, Digikey and others carry this one - SUNON MF35100V2-1000U-A99. Different "customer number" but it's the same fan for $8.06. Mouser is out-of-stock until 1-1-2022.

This is with a rectangular support blocker covering the threads. Within my gray circled area the threads are being supported as evidenced by the support interface roof lines. I played with the settings and I could not eliminate this. The results were the same with a 34mm diameter x 12 cylinder and with a 34mm diameter x 195 cylinder. Switching from Tree to Normal supports made no difference, the threads were still being supported. Even with the support angle at 75° the threads were being supported and that should have been beyond the (I assume) 60° included angle of the thread form. I've worked with models with similar features but I've never seen this problem. What Cad software was used to design this and how was the STL file generated? (There were a couple minor problems with the model but a repaired STL sliced exactly the same.) Maybe @Torgeir, @geert_2, @nallath, @gr5 or one of the other more experienced people have a better take on what's going on. I hate being baffled before my second cup of coffee. I'm still baffled. This is with a support blocker covering the entire model. Here is the top layer. The support is not supporting anything, and the threads are still supported. So I went back to the "repaired" model and tried again. I had been playing with the support settings for the un-repaired model when I brought the fixed model in. This time I went back to my defaults before bringing the fixed model in. I think it worked. I have now set a personal record for most attachments to a post. SlickUpper_fixed.3mf

I don't know. Here is your posted gcode file printed on my printer. It took half a layer to tune the flow and speed to my .4 nozzle. I don't see any blobs or zits or other flaws. Whatever is going on it's downstream from Cura.

My printer is an Ender 3 Pro with the 1.1.5 board but I print via the SD card. For a while the Creality definition file was way too aggressive for the Maximum Resolution that the mainboard could handle. In Cura under Mesh Fixes is a setting for Maximum Resolution. If that is a really low number like .025 then try setting it to 0.4 and see what happens (I keep mine at .4 and when I opened the 3mf file it says .4 but double check). When the number is low the resolution can be too high for the printer processor and the print head can stutter as it runs out of data due to the billions of lines that are .002mm long. It is especially prevalent on curves and circles and every time the nozzle has to wait for the calculations to catch up it leaves a blob.

Here is a view in Cura. This gets drawn by the GPU and is layer by layer. There is no accounting for the incremental Z moves in a spiral file. Here is the same area as read into AutoCad. You can see where spiralize starts above the bottom layers and that the spiral is there as the individual line segments are exact instead of being an approximation by layer. It's one of the reasons I like it as a tool.

If you change the support density to 100% it will become...not better but maybe clearer.

Hello @Torgeir and @Mlogue9. I sliced the 3mf reviewed the gcode, and read the gcode into Autocad to view it. When Cura puts retractions and primes into a file they are always on their own lines in the form "G1 Fxxx Exxx.xxxxx". There are never any XY or Z values in a retraction line. That makes them pretty easy to search for and there are no retractions in the gcode file I generated. (@Mlogue9 - if you could post your problem gcode file I'll look at it.) Sorry Torgeir - here we see the travel move (magenta) going from the last normal layer to the start of the first spiral layer (it's within the yellow circle). There is a short move .133 long and then spiralize starts. You can see that there is no zhop and within the gcode there is no retraction associated with that location. The snippet starts at gcode line 6767. G1 X112.055 Y93.815 E1602.62293 G0 F12000 X111.985 Y93.702 - This is the end of the red travel move G1 F2281.2 X110.834 Y93.755 Z1.582 E1602.74556 - This is the first extrusion of the spiral G1 X109.558 Y93.766 Z1.584 E1602.88138 I don't see anything odd in the gcode I generated.

Cura never builds useless supports. Questionable supports yes, useless no. If you change the support type to Tree and make the XY distance 0.1 and the Z distance 0.1 you'll see that it's attempting to support the threads. The thread angle is 60° (and the helix angle is involved) and your Support Overhang Angle is 50°. If you change Support Overhang Angle to 63° (or simply turn support off) the problem goes away. Your settings say supports should be required, but "Normal" supports can't get past the internal chamfer and so you get those partial "questionable" supports. The maximum support angle in most situations is 63°. Anything above that and the next layer prints over air. Your threads are pushing that and in the case of your model - if the thread was an M50 you might want supports in there. Internal threads often require a decision by the user regarding supports. If I have a 2.5mm diameter horizontal hole I put a support blocker in it. If the hole is 75mm diameter I probably want to allow support.

You don't have to remove them from Cura. Next to the Slice button is a crossed hammer and wrench. Click on it and you can click on the X next to a plugin and de-activate it. Then use Add a Script and find Show Progress and activate that one. If the crossed hammer and wrench isn't there then go to Extensions | Post Processing | Modify Gcode and select Show Progress there. I'm a VB guy which is kind of like knowing Latin.

De-select Origin at Center. The origin is the left front corner.

The build plate you see in Cura has X=0, Y=0 in the left front corner. +X goes to the right and +Y goes to the back. The actual printer build plate will also have X=0 and Y=0 at the left front corner. Cura and the printer have to match. Auto-Home the printer. The nozzle is at 0,0. Now stand by the machine to look at it - make the nozzle position the left front corner. In Cura, go to Settings | Printer | Manage Printers | Machine Settings. Set the X(width) and Y(depth) to match your printer. If you make a change in those numbers then the virtual plate in Cura will change size to reflect the numbers you entered. Place your models so they fit. It's possible that you may have to set the Home Offset on the printer. The printer doesn't actually know where the build plate is in space. When you level the bed you set the Z and by setting the home offset you set the XY. When the printer reads a gcode file it will put the gcode 0,0,0 at the Home Offset 0,0,0 and not at the auto-home position. That is important to get your prints in the center of the bed.

I use a VBA macro to read any gcode file into AutoCad. My old Acad version requires some tricks to open a text file (I have to go through Excel) but once it's open in the streamreader it can be read and translated line by line. G2 and G3 required a lot of thought but all the G1 and G0 moves are just drawing lines from point-to-point. This angle bracket is a normal gcode file. Travel moves are on their own layer so they can be shut off and ignored. This is a file created using ArcWelder.

Use the visibility dropdown that is next to the Settings Search box and set visibility to "All" In the Travel section is Max Comb Distance with No Retract. When set to 0 there is no retraction on combing moves. Setting it to 10 should work.

What printer is it and which printer definition did you install in Cura? Also, can you explain a bit more about what's going on? Under "Manage Printers" and "Machine Settings" are boxes for Machine Width and Machine Depth. From what I see of the Monoprice IIIP it's 120x120x120 so you really shouldn't be having an issue.

If that is a single wall print it's going to be tough. In Cura use "File | Save Project" and post the 3mf file here. It will contain the model, printer, and settings you are using. If the model is proprietary then load a similar one if you can.

And now you have three. This one is un-official but I like it. ShowProgress.py sends the layer-of-layers, and the time remaining to the LCD with a M117. It has a fudge factor for the "time remaining" which I've found to be 1.1 on my Ender. The form on the LCD is "1/222 | ET 2H32M" Unzip the file and put ShowProgress.py in the "...Cura 4.x.x\Plugins\PostProcessingPlugin\scripts" folder. It will be available as any other post processor. It will not self install if you install a new version of Cura. ShowProgress.zip

Maybe @Torgeir can help. He knows those printers pretty well and he'll get this heads-up. I don't know what continent he's on so it may well be tomorrow.

You need to go back to square one with a set of vanilla slice settings and then change one at a time. There are some conflicts in your settings and I'm not sure which one is causing the problem. I think what you are trying to do is get rid of the Z seam for your mold? I played around a bit and came up with the attached file. The bottom of the mold has a hole that I wasn't able to get rid of. This is layer 6 and is the first layer of the mold. SupportParas.3mf

The file sliced with 4.8 is in Relative Extrusion mode. Viewing the individual lines of extrusion, they indeed reflect Relative mode. The file sliced with 4.10 SAYS it is in Relative Extrusion mode but viewing the lines of code in that file that have extrusions, it is in Absolute mode. That is a conflict and will "absolutely" make a mess. I think what happened is the "M83" in your Start-Up G-Code places the printer into Relative Extrusion mode but within Cura you are in Absolute Extrusion mode and so all the extrusions get misinterpreted by the printer. The fix is to either set Cura Special Modes | Relative Extrusion to "checked", or delete the M83 line from your startup gcode and let Cura handle the setting. My choice would be to get rid of the "M83" in the startup gcode. To fix that existing 4.10 file just delete the M83 line near the beginning of the file.