GregValiant

Did it all wire up correctly? The unit itself is fine. Well made and complete. It just made a mess. It's been a while since I played with it. Something did happen at the beginning and it wouldn't extrude but I seem to recall I made a simple change and it worked. It has to be closed and up to temperature and the steps/mm need to be correct. You also have to disable the "Cold Extrusion Preventer". I found the config files if you want them. The startup gcode has to include: M302 S0 ; Turn off Cold Extrusion Preventer. M92 E750 ; set the Esteps/mm

"The post-processing scripts ... assuming that they work at all." I don't want to toot my own horn, but I might be the best at post processing scripts that barely work. I don't collect them per se. They just magicly appear from the ends of my fingers.

One thing to consider is that Simplify, PrusaSlicer and Cura calculate volume-of-extrusion slightly differently. Cura considers a simple rectangle LayerHeight x LineWidth x Length. PrusaSlicer considers that the left and right wall of any extrusion will be a radius What I've read is that Simplify adds a simple fudge factor of a couple of percent to the LH x LW formula. The differences are subtle, but there. I've looked at your profile and there are a couple of things that are frankly personal preference, but it's because I didn't like the results I got when I use them. "Coasting" is at the top of the list and "Retract Before Outer Wall" is on the list. They both effect the start of the next extrusion. My Ender doesn't like them. I get filament from Matter Hacker. It is consistently 1.72 diameter. I enter that into Cura's Printer Settings because at 1.75 diameter I would be suffering about 4% under-extrusion right-out-of-the-gate. Top skins are the best for checking "flow". I picked up a microscope at a garage sale for cheap but a decent magnifying glass will work as well. What @Dustin and I are seeing in your image are gaps between the extrusions of the top skin. If you zoom in you see that the edges of the extrusions are not welded together and you can see the cross-hatch pattern (of the layer below) through the gaps in the top layer. That is definite under-extrusion and when you add a bit of material shrinkage, you get the gap you see around the hole and material being pulled into the center of a circle. The simplest thing to do is increase the flow in Cura. The project below has a FlashForge Dreamer NX as the active printer as it is the only FlashForge printer that was available in Cura. There are three identical models with different Per Model Settings. The model on the left has the flow at 100%, the middle model has flow at 110% and the right model has the flow at 115%. I set the Line Directions to [0, 90] to make it easier to check while they are printing. Open the project and switch to your printer. I started out with your MyDraft profile but go over all the settings to insure they are what you have been using. Watch during the print and when they are done check the top surfaces with a magnifying glass and see what you see. I don't know your printer, but pretty much all Creality machines must have the E-steps/mm calibrated in order to produce the correct volume of filament for extrusions. If you can or have calibrated the E-steps then DO NOT use a "single wall calibration cube" to further alter the flow. Just insure that when asked to deliver 100mm of filament the extruder does actually deliver 100mm - no more and no less. Flow Test Cubes.3mf EDIT: This is an exaggeration but it's what I'm seeing in your images. Notice that you can see the layer below through the gaps in the top layer.

@Torgeir hasn't dropped in lately but he's pretty good with the 2's. Maybe he'll respond and have a thought on this. The title says the printer "randomly restarts". After reading your description it sounds more like it "randomly stops". Would that be correct(?) or is it restarting the print from the beginning and double printing those first couple of layers?

Your Ender's firmware may support Resume after Power Loss. You would need to do some research on how to accomplish it. If it is enabled in the firmware, and you happen to be printing via the SD card, then the printer will constantly write the "resume data" to the BIN file on the SD card. If the power goes out, no problem, the printer checks the BIN file and knows pretty closely where it was when the power died. It can then restart a print from that "byte location" in the file. If you were printing via USB and did not have an SD card installed then there is no resume data. Cura has no way to know what happened at the printer so keeping track of how many bytes were sent isn't useful. If you were printing via the USB and did have an SD card installed then I don't know if the printer would be updating the BIN file or not. Printing from the SD card is simple, and the printer can pull gcode lines at it's own pace. Using something like Octoprint seems to work quite well. Printing from the USB is glitchy and can be prone to random print stoppages even without a power loss.

Also, make sure your wall ordering is "Inside to Outside". Some under-extrusion coupled with the outer wall going down first can drag the too-skinny filament across the middle of the hole instead of it staying where it was put.

I had always installed different printers so I could have different speeds in the StartUp Gcode (TPU in particular needs to be much slower and with no retracts). I'm old and remembering to pick the correct printer didn't always happen. Trying to print TPU at PLA speeds was a disaster. I want the purge lines to go down at 2/3 print speed and I noticed that {speed_print*60*.66} doesn't work. If I change it to {speed_print*60*2/3} it does work. So it would appear that floats are not allowed in the math. Another example: G1 F{retraction_retract_speed*60} E-{retraction_amount/3} works but G1 F{retraction_retract_speed*60} E-{retraction_amount*.33} does not. I can't get any logic to work. It might be a personal problem. "round" does work.

Hey, even a blind squirrel finds a nut every once in a while. When you start getting comfortable with Cura you can go to the definitions folder and open up your definition file in a text editor like MS Notepad and take a look. It's something you're going to want to know how do to later on. I've customized my definition file for things like the Skirt Height which I much prefer at "1" rather than the default of "3". You could remove the disallowed areas if you are brave. Be careful because if there is a typo then Cura won't load the file and the horrible "Your setup is corrupt - do you want to reset" comes up and you can wipe out all your printers, profiles, and other personal touches.

Build plate adhesion. The Ender 3 definition file has "disallowed areas" at the front and rear of the build plate to miss the clips that hold the build surface. Those are the dark borders. The light gray borders are the area that will be taken up by the skirt/brim/raft. When you have a big flat model like that the nozzle really only needs 1 lap of skirt to get flowing. So change the "Skirt Line Count" to 1, and change the "Skirt Distance" to 2 or 3. If it still doesn't slice you will need to rotate the model 90° because the Disallowed Areas are only in the front and rear meaning you have more room side to side. An alternative is to use the Ender 3 Pro definition as it doesn't have the disallowed areas. That's why my printer (which is in fact an Ender 3 Pro) doesn't have the disallowed areas.

The plugin was put together in 2018. On August 25, 2023 the author added a note to the ReadMe.md file. "This plugin is no longer being developed or updated and should not be used.". The note appears to have been added after the author made an attempt to get the plugin to work with Relative Extrusion. At that point it appears that the towel came flying into the ring. You can leave a note on the GitHub page. Maybe showing some interest will get Pheneeny to think about it some more.

Click on the model in Cura and then select "Per Model Settings" and set the model to "Normal Model". Right now it's the only thing on the build plate and you have it set to "Modify Settings for Overlaps". Cura is looking at the build plate and the only thing it sees is a Modifier Mesh with no model. As a Normal Model it looks like this and will slice:

That project file doesn't have any post processors active and the travel speed of 1000 is throwing a "can't slice" error. Within those snippets above; the retraction distance is 4.4656 and the print speed is 1000mm/sec. That's either a very capable printer or something is wonky. Post processors run in the order they are listed. You may be getting an interference if one must run before the other. There are also cases where one post is not compatible with another because of the changes it makes in the gcode.

The "Voron2 base" definition you posted is a LOT different than the one I show in Cura. Right off the bat - the version number is the second line and it should be the first line. Cura notices things like that. A single type and you get the "reset" warning as the file won't load. There are a lot of changes to the overrides section including the formatting and addition of spaces/tabs. That can be problematic if spaces and tabs are mixed on the same line. Your file: "overrides": { "machine_name": { "default_value": "VORON2" }, "machine_width": { "default_value": 250 }, Stock file: "overrides": { "acceleration_enabled": { "default_value": false }, "acceleration_layer_0": { "value": 1800 }, Here is the stock Voron2 Base file from my 5.5 installation. voron2_base.def.json.log

@obewan has got it I think. Open one of those new Gcode files in a text editor. At the very beginning will be a set of lines that describe the area of the build plate that is used. ;MINX:51.401 ;MINY:95.02 ;MINZ:0.2 ;MAXX:248.571 ;MAXY:203.986 ;MAXZ:27 There should be NO NEGATIVE VALUES in the list. If they are then Obewan nailed it. Related to that is the "Home Offset" position set in the printer. Changing the PID allowed access to manually change the Home Offsets. Resetting the printer to defaults with M502 should have fixed that.

DON'T RESET. The "Do you want to reset" box has an "X" in the top right corner. Use it to dismiss the warning box. Cura will start and you can delete the offending printer or do what you need to do without starting from scratch. Eventually you will find the corrupt file and Cura will start without the warning. If a corrupt/wrong temporary setting file exists in the AppData/Roaming folder then Cura can balk at starting. Which file it is becomes the question. It might be a definition file, nozzle file, or extruder file.

Some things can be passed along in the gcode. Others need to be supported by the printer firmware and must be set up in the printer. There may be pressure advance Gcode commands (mostly likely Mcodes) that would need to be added to the gcode. That can be very printer specific and is different from manufacturer to manufacturer and likely from firmware developer to firmware developer. Raise3D used M1001. My Ender doesn't support pressure advance and would ignore M1001 as being an illegal command. A TronXY might be configured for M650 but the owner changed the firmware to JYers and now it's something else. Your Duet might have a completely different way to configure it. At some point you run into the fact that UltiMaker does the heavy lifting on Cura. If their printers use pressure advance they will pay their people to write it into Cura. If not then you are stuck putting the commands into the StartUp gcode or using a post processor like Insert at Layer Change to sprinkle commands into the gcode.

Settings like Pressure Advance and Linear Acceleration need to be supported in the firmware. There is only so much you can do in the gcode before you start to hamper it.

No matter what someone asks to be included in the Cura gcode - someone else will ask to remove it. There will always be room for post-processing. A fella that posted here built a very large printer and the way it was configured there could be no retractions. Oozing while traveling dropped the pressure in the very large heating chamber enough that the next extrusion always started out dry. I wrote a script for him that does kind of what you are asking for...it continued a slow extrusion throughout travel moves and oozed on purpose. That allowed the printer to start the next extrusions with plastic actually coming out of the nozzle. He didn't care about cleaning up the strings. (That particular script is his property.) Perusing other scripts is how I learned what little I know. The scripts I've altered I did for myself. I just figured I'd pass them along in case anyone else was interested. "Can I infer that priming is forced to begin just at the start of the new path?" Yes. It is always: 1) Prime 2) Do an extrusion". G0 F7200 X116.392 Y191.152 >>>last travel move G1 F2700 E1761.20839 >>>Prime G1 F7200 X116.466 Y191.443 Z7.80 E1761.20389 >>> 1st extrusion "... spread priming over the next starting extrusion path". I dunno. It's what it already does since it is extruding at that point. You can try using the "Extra Prime after Retract" setting in Cura if you need to have more material available for the start. It can cause blobs as the mm³ is always the same regardless of the length of the travel move.

This is another of my re-writes that is waiting in line for approval. The Retract Continue included with Cura doesn't work if you are using Z-hops. This one does. (That was the only change I made.) RetractContinue.zip If you intend to use Z-hops you should use the new version. In Cura use the "Help | Show configuration folder" command. Within the config folder will be a "scripts" folder. Unzip the file and copy RetractContinue.py into that "scripts" folder. Next... Go to the Cura installation folder and navigate to "C:\Program Files\UltiMaker Cura 5.5.0\share\cura\plugins\PostProcessingPlugin\scripts" and rename the stock RetractContinue.py file to RetractContinue.OBS" so Cura will ignore it. When you restart Cura the new version will be available. This snippet is a combing move around a circle and is an example of what you will see from the script. For this example retraction distance was set to 5mm. The "mm of filament/mm of distance" was 0.05. That seems to be too much for this particular print G1 X182.69 Y190.89 E1736.58285 >>>>last extrusion G0 F7200 X182.595 Y190.86 >>>>>wipe G1 F2700 E1731.58285 >>>>> retract 5mm (per the retraction setting) G1 F7200 X182.503 Y191.143 Z7.80 E1731.56797 G1 X184.368 Y191.880 Z7.80 E1731.46770 .....47 more moves all with a bit more retraction G1 X116.694 Y191.902 Z7.80 E1720.22590 G1 X116.788 Y192.186 Z7.80 E1720.21095 >>> the Retract Continue script adds an additional retraction of 11.37mm G1 F2700 E1736.58285 For that example a setting of .05mm of filament / 1mm of distance is too much. That would draw molten filament up into the heat break of my printer. Not good. Setting it to .025 results in a total retraction of about 10.7mm which might be doable. I'd probably go with 0.015 which results in a total retraction of 8.5mm. Definitely much better for my printer. I print a lot of PETG and I've settled on 235° which seems to be a decent balance between the stringing problem and good layer adhesion.

Check the settings for "Minimum Support Area" and "Minimum Support Interface Area" and "Support Overhang Angle". You look to be supporting inside diameters and they narrow down at the top. Both a lower Minimum Area and a an angle around 45-50° should allow the supports to get to the other outside one. For the middle it's an ugly reach. The best idea is to use Normal Supports - Everywhere. It looks like that model only needs support within the holes. If that is true you could probably get by without any supports (provided your layer cooling fan is up to snuff). I don't bother with supports in holes that are less than 20mm diameter.

I'm on Windows (and Cura 5.5) and this might be specific but here is what I found. My built-in SD card reader has always been drive D. I plugged in a remote multi-drive reader and when I plugged the SD card into it, it showed up as drive D. I plugged another SD card into the built-in reader and it showed up as drive F. Now the built in reader is always drive F. Back to Cura, I sliced a model and when complete I plugged the SD card into the built-in reader and after 10 seconds or so it was available in Cura as drive F. So even with different drive letters it appears that Cura was informed and showed the current configuration of F and E. D seems to now be assigned to the slot in the removeable reader. That also showed up in Cura when I stuck a card in it. I don't know if Cura polls Windows for updates (like it does with USB printing) or if Windows is pushing information regarding how any drives are configured. I know this wasn't much help, but I was curious myself. If I had to guess I would guess it's a OpSys thing.

I've been printing smaller things lately and I had not noticed this. With all Print and Travel speeds at 75 in Cura I'm getting speeds excess of 150 in the gcode. That is simply too fast and the quality of the print suffers. It looks to me like "Speed / Flow Equalization Ratio" is the culprit. With it turned down to 0% everything is fine. I just checked another model with the equalization at 100% and the printing speed is up to 194.81mm/sec. My recollection is that 5.4 didn't have that effect. The print speed here should be F4500 (75mm/sec). G1 F4522.6 X129.811 Y148.87 E3395.59444 G1 F6000 X129.461 Y149.16 E3395.60577 G1 F8955.2 X126.129 Y152.907 E3395.68958 G1 F9090.9 X125.401 Y153.667 E3395.7069 G1 F9137.1 X124.534 Y154.448 E3395.72602 G1 F9183.7 X123.673 Y155.11 E3395.74372 With Flow Equalization at 0% these are approximately the same place on the model. This is what I've seen previously. G1 X113.139 Y114.071 E3465.42412 G1 F2100 E3459.42412 G0 F4500 X112.824 Y122.97 G0 X108.616 Y135.154 G0 X100.788 Y145.825 On another model the print speeds were pushed to over 190. On that same model with the identical setup 5.4.0 showed a max speed of 104. C'Mon man, if I wanted to print at 190 I'd would have bought a different printer. And those speeds are showing up though I have "Maximum Speed X" and "Maximum Speed Y" set to 100 in Cura. So what's up with this @nallath. We're all on the Autobahn?

Cura gets the letters of any available drive from the operating system. It doesn't talk straight to the hardware. Somehow, your operating system isn't conveying the new drive letter. Have you noticed if any other apps are having a problem seeing the drive? What happens with a USB stick?

Before there were so many ABL's available you could watch the skirt go down and make on-the-fly adjustments to the leveling wheels. It would need to be a bigger print to be effective but it does work.

Cura can use special words in the startup and ending gcode and they will be replaced with the value at slicing. The complete list is HERE and "cooling_fan_speed_layer_0" means Initial Layer Fan Speed. If you just have "cooling_fan_speed" the fan could go to 100% right from the start. (FYI Feed rate speeds in the list are in mm/sec but gcode is in mm/min so they aren't interpreted correctly if you try to use them in your startup/ending gcodes.) No, you cannot have two commands on the same line. The printer will ignore the line as it will be interpreted an illegal command. M118 would depend on your firmware. For most firmware it is similar to M117 (send message to LCD) but instead of the message going to the LCD the printer bounces the message back to a print server (like Pronterface). I have seen this form with M118: M118 X15.00 Y15.00 Z0.51 T0 That has the bounding box size in and the tool number so maybe it's telling the printer the area where that nozzle should stay. There are no replacement patterns for the XYZ of the model bounding box. It would need to be done in post process. I've also seen this form using M108: M108 T0 So use what works.