GregValiant

The fan that cools the mainboard on my Ender 3 Pro was wired to the Cooling Blower. So if you turn the cooling blower on at any % then mainboard fan should come on at 100% (it's not variable speed like the blower). I was printing PETG and the blower was pretty much always off so the mainboard fan never came on and the E driver failed. My fix was to cut the plug off the mainboard fan wires and fasten them to the Hot End fan connection. The hot end fan always runs, so now my mainboard fan does too. gr5 was talking about reference voltage. As he says, there may be a little potentiometer next the driver chip (there may be one next to all 4 drivers). With a multi-meter positive lead on the screw head, and the negative on any 24v ground, you will get the Vref value. It is typically around 1 volt with the E driver a bit more. It is adjustable by turning that little screw a touch at a time. If the Vref is too high the stepper motor can overheat (I don't know if they thermally protected or not). If the Vref is too low then the motor doesn't develop enough torque and it will miss steps. When a stepper is running, you should be able to keep your fingers on on the housing comfortably. If there isn't a screw next to the driver chips, then you may be able to adjust the "current" with M906 or M907. When I send M503 to my printer an M906 line is in the response as M906 X650 Y650 Z650 E800. The values are in milliamps and multiplying by 1.3 and dividing by 1000 gives the Vref to achieve that current flow to the steppers. So on my particular machine the Vrefs are .85, .85, .85 and 1.04.

The plugin "Display Progress on LCD" is similar but doesn't have the fudge factor. It does a straight interpretation of Total Time - Elapsed Time and converts the result into hours and minutes. A couple of people who own Delta printers have notice a huge discrepancy as well. Looking at the Cura "03:45" and the printer "04:55" which one is correct (how long will that print really take)? Slicing the same model in Raise3D IdeaMaker, is there a difference in time?

Opening any Cura gcode file configured for my printer, the first two lines are: ;FLAVOR:Marlin ;TIME:10684 That is the only reference to time in the file (EDIT it does show Time Elapsed as a comment at layer changes). I've found it to be pretty accurate. My printer pays no attention to it however. Instead, the printer (Creality) knows how many bytes it has processed, and what the file size is, and how long it's been working. It displays the percentage completed (bytes read ÷ file size) and the elapsed time. When I first started into 3d printing I found it annoying to constantly have to calculate the current layer number. I asked for a "new feature" that would show the layer number on the LCD screen. The person that wrote a plugin for it must have had the same issue you are having because he also added a "time remaining" feature AND that feature has a fudge factor. You can make it very close to reality. The fudge factor is: Cura time in seconds ÷ Actual Print time in seconds. Once you've done a couple prints and have a baseline for an average, put the fudge factor into the dialog box. Here is the plugin "ShowProgress.py" in the zip file. Extract it and put it in the Cura...\ Plugins \ PostProcessingPlugin \ Scripts" folder and it will be available the next time you start Cura. The options are to "Show Layer #" and "Show Time Remaining" and "Speed Factor" which is the fudge factor. Using the above "10684" time and with a fudge factor of 1 this line gets added at layer:0 and at every layer change the numbers are adjusted: M117 1/378 | ETA 2H58M Changing the fudge factor to .91 that line would appear as: M117 1/378 | ETA 3H15M I like it. The layer number displayed is the layer that Cura shows in preview, and I can adjust the remaining time to something approaching real life, and it gets displayed on the LCD. I've never been a huge fan of Reality, but it this case it allows me to know about what time I should get up from my nap. ShowProgress.zip

You don't need my support...I've seen your customs supports. There is a lot of effort into that. I hope @gr5 chips in with his thoughts. I get first shot at it though. This is necessarily a lot of opinion/personal preference so don't take any offense. The 1.4mm line width for the initial layer is huge. That is an effective flow rate of 350%. I know you've got it going very slow at 12 and 15mm/sec, but that's a lot of plastic to push. That amount of plastic flow coupled with an initial print temperature of 170° is making your printer work really hard to get plastic out. At the regular printing temp of 180° the layer adhesion can't be anything to write home about either. I print white PLA the coolest of any material I've used and I print it at 200°. This may be one of those "personal preference" things. You know your machine. "Compensate Wall Overlaps" could be one of the problems you are having with corners. The plan is that when walls pass close together, the extrusion is lessened to prevent over-extruding. That means in some cases that it's under-extruding and doing it on purpose. It's a feature that has a use in specific situations but I don't see a need for it on those parts. Z-hop. At a height of only .075mm, why not just turn it off. The print head is jumping up and down and really not having much of an effect other than inducing vibrations. It can also cause extrusion problems in the area between holes or other features that are on the same layer. Combing. Long combing moves allow the pressure in the nozzle to fall off. When the "prime" comes and extrusion resumes the prime is often insufficient to meet the immediate needs of the next extrusion line. That results in under-extrusion for a bit before the pressure can build back up. This is usually more of a problem at the layer start and at the zseam location because so many prime moves take place there. Finally, you have 50% density gyroid infill coupled with slow print speed and all the combing moves on three parts. It's a 54 hour print. Why not print one at a time? The total print time won't be much different and the threat of one piece failing after 30 hours and taking the other two with it becomes nil. In your photos #2 and #3, that edge needs to be supported. You have given a lot of attention to support on the back side, but on each "front" corner, the printer is air-printing that edge. The printing temperature of 180° may have something to do with the bridging problem in the c'bored hole. In photo #4 those blobs happened when the nozzle made turns at the start of a layer, or at the Z seam. There is going to be some visible "stepping" along that edge since it's a sharp corner along a compound curve. Using up some leftover wet filament (it's why I keep it around), I did a partial print. This is with 0% infill, 200° print temp, 50mm/sec printing speed, combing off, "Compensate Overlaps" off, Z-hops off. I moved the model down 35mm into the bed to avoid all the support. As is typical when I print white PLA, there was some wispiness, but no real stringing. There were no surface blobs. It took 3 hours. Have you printed a temperature tower to confirm that your machine prints well at 180° (as opposed to 195 or 200)?

I printed a vase yesterday in silky blue PLA as a test. It looked really good. It came off the build plate fine (I use a small putty knife and tap it with a tack hammer to break it loose). I presented it to the wife and forgot to tell her "dry flowers only". That turned into another test as it leaked, but only at the transition layers between the bottom and the spiral. That would seem to indicate poor layer adhesion or gaps there. I may do a partial test with the flow kicked up for that transition and then drop it back to 100%. Another leak test might indicate if that provides a better bond. That is also the layer of the speed transition. I happened to be looking at the printer when the transition happened and it was very sudden. Maybe a gap occurred because of that.

Yes the printer is fine. If you don't like printing from the SD (the best choice) the real alternative is Raspberry Pi with Octoprint. Repetier-Host is a possibility. None of the current Ultimaker printers use "Print by USB" so that portion of the software hasn't seen any maintenance in 2 or 3 years and from what I've read, there are no plans to divert resources to it. It looks like the Cura team is very busy with the new Arachne version. Using USB printing there is a problem with the input buffer in the printer suffering from code over-runs (missed lines of Gcode) and under-runs (starts and stops while printing). In particular is the problem with Cura sending M115 to the printer every 3 seconds to check the temperature, and to check that the port is still functioning. If the printer input buffer is almost full, the printer truncates the M115 to M1 which is a stop command. The problem is not unique to Cura as Pronterface/Printrun suffers from it as well. It's possible that something else is going on but Cura sends the same Gcode over the USB as would be on the SD card (except for the interjection of M115's into the data stream). I have taken a look at the Start-Up Gcode in your printer definition file. It looks fine, but maybe there is something in the gcode that is causing the printer to stop. If you would post one of the problem Gcode files here somebody will take a look. All taken with all, USB printing is troublesome and I didn't even get into Windows pushing updates that reboot the computer and cause a print to stop. That is the reason I don't use USB printing on my Ender 3 Pro. I can't count on it. The RaspPi + Octoprint solution seems to be the preference for most people. For me, the SD card is simple and easy to understand. I did find using the LCD to be clumsy so I wrote an app to get around it. I rarely have to touch that dumb knob anymore.

If you would use the File | Save Project command you'll generate a 3mf file with all your settings in it. Post that 3mf file here and somebody will take a look. Without knowing any of your settings it's just guessing.

That sounds about right gr5. Spiralize takes the speed settings and adjusts them during the actual spiralized layers. The base layers print at 100% feed rate. When the spiral starts the speed drops to 50% and by the end of the print is typically at 25%. So Cura is making speed adjustments layer by layer. I printed an RC sailboat hull with the .4 at .6 line width but I thought in that case it just wasn't thick enough. I'll be printing it again with a .6 at .9 line line width. I don't want to sink a bunch of fairly expensive gizmos.

"How fast can I print?" A philosophical question for the ages. On a rainy Saturday morning, here is a philosophical answer. ("Philosophical" in this case equates to "Useless".) You may print "as fast as you want". That isn't the same as "as fast as you can", and is a lot different than "as fast as you should". There is also "as fast as is practicable" which is where you want to be. It's a question of balance. As Carla says, much is dependent on the print core/hot end and how much melted plastic it can deliver through the nozzle in mm³/sec. There is a definite "Upper Limit" for any of them for a given material (and about 100 other variables) and likely varies from machine to machine. Even if the core can deliver enough melted material, there is a point where the pressure in the hot end can't push the plastic out of the nozzle fast enough and the path of least resistance is "up" instead of "out". That's a condition generally referred to as "Not Good" and so choosing a larger print core comes into play. There are so many variables that it becomes impossible to make a prediction. On a small part your print speed can be 1,000,000mm/sec because the Accel and Jerk settings are the limiting factor. On a large intricate part you may be limited to 30 or even 20mm/sec. Going around high resolution circles and curves that are comprised of a lot of very short line segments brings the max computational ability of the printer/processor into play. This is just for reference: I had decided to do an "Extrusion Speed Test" with my Ender 3 Pro. I found that my printer pushes red PLA the best so that's what I used. The part was designed to be all skin that took up the whole print bed in order to remove turns and stops from the equation and to insure that the print head was actually getting up to speed. I set the line directions for Top/Bottom to [0, 90] so all stripes would be the same length. The nozzle was a 0.4, My Accel and Jerk settings are low compared to a high end printer like yours. The extruder started missing steps at 110mm/sec. There is no way that I could print a real part at that speed as mechanical wobble/looseness/backlash would become additional limiting factors. I conducted another test with "no extrusion" at 400mm/sec. It showed an average of 342mm/sec on a 650mm course with two starts and two stops (left-front to right-rear and back on my 230 bed). The agonizing sounds of distress the poor Ender 3 made when starting and stopping at that speed were truly heart-rending. It was "as fast as I can" and was definitely above "as fast as I want".

From Matter Hackers.

Not in Cura but yes, there is a way to start with thicker walls and then narrow them down. It's in "Advanced Gcode Splicing 401" so maybe you don't want to go there yet. As gr5 says, you do need to thicken the walls. With a .4 nozzle I've had good success with 0.6 line width. Vase mode is "single wall only" no matter what the wall thickness setting is. Another problem is that many Silky PLA's just have poor layer adhesion. That problem can vary by color and might be what bit you there (nice looking print otherwise). You may have to bump the temperature up as well. I can run regular PLA down to 195° but silky I always start out at 215° but you could even run it up to 225 at the first layer above the base feature because there aren't any retractions and the print head never stops. It would be really gooey though. Be careful when removing it from the bed and try to get that first layer down without adhesives. No matter what you do it's still a single wall print so it isn't going to be strong.

For the 64 bit version you can stick with mainstream Cura 4.8.

I seem to recall that Win 7 Pro came in 32 and 64 bit flavors. I'm limited to Cura 2.3 on my 32 bit desktop. The SmartAvionics Master version has a 32 bit version and I have that installed as well.

Any hat that requires a video to explain it is ridiculous by definition. I've built 12. The fire helmet has 6-AAA batteries, 1-9 volt battery, 2 music speakers, 1 speaker for the bell, 5 circuit boards, 210 LED's, 70 rivets, somewhere around 60 feet of #26 wire, 11 switches, a variety of ostrich plumes for various holidays, and it weighs just under a kilo. I didn't bother getting the blue-tooth to work since I refuse to give up my flip phone.

What operating system is the PC that doesn't slice? Have you tried re-installing Cura?

@gr5, it's the Y so 20mm below the build plate mid-point. I'm going to ignore the suitability of "Origin at Center". @onr, Look at the Cura origin icon. The green arm is the Y. The Cura origin is showing "+Y" as being UP in the view. Now look at the "part" origin icon. The part origin green arm is point down. I have no idea why that is, but that is the confusion. You moved the part Y-20 in relation to itself, but the "part" origin (not the part itself) is mirrored about the X in relation to Cura. So in that view, the part is sitting wholly in the +Y even though you have it set to -20. I never noticed (realized?) that (I've never used Origin at Center before). I wonder if it's right/intended? @gr5 - have you seen/noted this before? PS I've edited this post about 10 times. My confusion is growing. onr - I've added a comment to your Cura bug report on Github.

@gianluca2021 - Is this still the "won't slice" problem? It opened for me (4.8), the model appears to be OK, and it sliced as it should. (There are things in the settings I would do differently, but that is just personal preference. It would certainly print as you have it set up.) EDIT: I exported the model from Cura, opened the file in 3dBuilder, and it did some repair work. Attached is the "repaired" file with the model only. TabletStandV4a.3mf

"...Ultimaker added these as a way to prevent newbies from damaging their nozzles..." Not Ultimaker. Near the top of your *.json definition file will be a line like this one from my Creality Base definition file: "author": "trouch.com".

When you use a "Grid" infill then there are a lot of crossings. Using "Lines" keeps them from crossing as each direction of lines is on a different layer. If you are counting on infill for structural strength the broken lines are a problem If you are just counting on the infill to hold up the roof above, then it likely doesn't matter. I agree that PETG is much better when printing slower, and your temps are right about where I print. @gr5 mentioned an adjustment...The extruder on the Ender does have an adjustment for spring tension. It is the screw on the inboard side of the spring. If you have the stock plastic extruder I would advise to leave the tension alone as that arm on the stock extruder is prone to cracking anyway.

Typically each model is brought into Cura by Center-of-Geometry and each model would need the same Center-of-Geometry in order to locate them correctly relative to each other. It is possible to use programs like Blender or 3D Builder to impart location data into the STL or 3mf. I haven't played with that very much. To fool Cura into becoming an assembly modeler I do the following. My build plate is 230 X 230. I create a build plate in the Cad program up to 230 x 230 x 5 with the top at Z=0. My real models are above it and oriented the way I want. The build plate gets merged with EACH model individually and then the model is exported as an STL. The build plate now determines the Center-of-Geometry for each model so the 0,0,0 of each model is identical no matter what angle the real model is at, nor what any models Z height might be. As in Tinkergnome's image, parts that are symmetrical about the Center-of-Geometry don't need a trick to fool Cura. Assemblies often do. These models were exported from AutoCAD as STL files and imported into Cura. There isn't any location data in the STL's. The flat rectangle was brought in first and occupies Cura 0,0. Cura placed the others where they wouldn't interfere. If each was moved to 0,0 they would overlap. These are the same models but each merged with a build plate. They are spatially correct when each is moved to Cura 0,0. The 5mm plates are now 5mm below the Cura Z=0. They will print in their correct positions relative to each other. In this example, because I chose to make the build plate the same size as the Cura build surface there is no room for a skirt or brim. Adjustments in the size of the plate would need to be made to accommodate a skirt or brim. An alternative to the above would be to simply merge the models before creating the STL file. In AutoCAD, the models don't have to be touching in order to merge them. The above models would have come in as you see them above but without the build plates. Their center of geometry would be some random point - but it would work well enough to print the parts in their proper relation to each other. As CUQ points out, it isn't always easy.

In whatever you were using previously, check the setting "Experimental | Slicing Tolerance" it should be set to "middle".

It's easier to be fast and loose when there isn't any material in the way. It's a whole different thing when you're removing material with a 2" cutter in an 8" deep pocket. Fast travels through a wall of steel could ruin at least your day (and a lot longer if you caught a cutter shard in an eye).

Upon reflection (I reviewed your other post) I don't think it's what you want. It simply sends gcode line-by-line to the printer and allows alteration of the Gcode stream. Useful, but not really descriptive.

"... I want the grain to go up/down..." That does require horizontal orientation of the holes as you show in the image. As gr5 advises, you are stuck with the "finish over supports" as the material can't "squish" onto the interface, and there is typically a gap between the interface and the first layer above as well. At a Support Overhang Angle of about 55° to 60° the extrusions become self-supporting. That negates the necessity for supports all along the "ears" and the finish will be acceptable where there are no supports. If you were to rotate that part about the CL of the holes and put the flat feature on the bed there would be support required for the area above, but maybe it would be hidden in your assembly? Dimensionally, surfaces over supports are not as good as we have come to expect so doing the ears as you show would be better than having the flats down. That is especially true if you are trying to hold the dimension between the flat the the CL of the holes. The material you use will make a difference. Clamping force drops over time as the plastic cold-deforms from the pressure of the fasteners. I usually use nylock nuts and try not to put much force on the part as they don't like that very much. I typically use the "Grid" for support interface. The "support interface density" and "support interface thickness" have an effect on the surface finish above. A high density interface generally leaves a better surface above but is harder to remove cleanly, and your post-processing of the part may leave it's own tool marks.

Thanks Torgeir. She was a nice girl. All the other men in the county thought so too. Kman - it was mandatory if you wore your hair in a mullet (the only haircut ever banned from bars). And since you made me look up a latin saying, this is my new mantra: "Nunquam credere quis sub sexaginta" For a while I made party hats. Both of you should like this one. It was for my brother-n-law who is Scottish. The Ach Hat and last but certainly not least, my own party hat Greg's Fire Helmet