GregValiant

As far as the model goes, I couldn't find anything that couldn't be fixed by a good orthodontist.

This is my understanding and it may be incomplete, over-simplified (or just plain wrong)...nevertheless I'll put it up here at least to start a discussion. PrusaSlicer uses an oblong as the shape of the cross-section of a single extrusion, and Cura (and IdeaMaker and some others) use(s) a rectangle. When two extrusions go down next to each other Cura is still a rectangle but the PrusaSlicer inverts the radius on the end of succeeding extrusions so they nest with the first extrusion (Image 1). The difference is miniscule and gets lost because the printers aren't accurate enough to notice and we are dealing with molten plastic. As far as I can see, there is no "better", just "different". The math is slightly more complicated for PrusaSlicer, but that is in the background and nobody notices it. When both programs are set up as close as I can get them, they both do a fine job, the prints look good, and are dimensionally accurate. Back to steps...In the Image below the two yellow lines represent the outer surfaces of a model. The rectangles are .2mm high x .4mm wide. An 80° slope results in a step width of .04mm while a 5° slope results in a step width of 2.29mm and a slope of 1° would result in a step 11.46mm wide. A lower slope results in the steps being farther apart as you see on the top of the cabin on a Benchy. So with a slope angle of 90° the step width would be 0.00mm. As the slope angle approaches 0° the width of the step approaches infinity. Tangent(90° - slope angle°) * Layer Height = Step Width. A layer height of 0.1 would result in steps that are 1/2 as wide as with a layer height of 0.2 and so Adaptive Layers is a useful tool to smooth the steps. The lower the layer height the narrower the steps...BUT...There are always steps because your layer height will never be zero.

Is it repairable or junk? I ask because my current favorite mantra is "Everything is a POS."

Congrats on finding it. Regarding the screen message - If you go to Extensions | Post Processing | Modify Gcode you will bring up a dialog for the post-processors. Within the scripts are "Display Progress And Layer On LCD" and "Display Progress On LCD". The one I use is a bit different and is in the Zip folder attached below. Extract the file and then copy it to the (for Windows) "...C:\Program Files\Ultimaker Cura 4.12.1\plugins\PostProcessingPlugin\scripts" folder and the next time you start Cura it will be available in the list of scripts. You will notice in the gcode there is an M117 line that sends the message to the LCD and there is also an M118 line that bounces the same message to my host program. It has a fudge factor for the time and I've found that setting it to 1.1 makes the actual print time really close to what is being shown on the LCD. It isn't a part of Cura so when you upgrade the software you would need to manually copy and paste ShowProgress.py back in for the new version. ShowProgress.zip

You will need to get Printrun/Pronterface in order to see the response from the printer. You can send a command from Cura but you cannot see the response. On most printers the XYZ are really close to exact from the factory. The Extruder often needs to be calibrated but the other three don't.

Then the code I posted will work.

That is an IDEX printer? Cura doesn't actually support IDEX machines. Some can be made to work with Cura (Raise3D is an example). The Matter Hacker site notes that two slicers are compatible: "Slicer: 3DWOX Desktop Slicer Sindoh Cloud Slicer" Those may have been included on a memory card if one came with the printer. I suggest you go back to the manufacturer or the sales company and find out if there is a way to set Cura up for your printer. Maybe there is a support group somewhere?

Copy one of the "bad" gcode files off the SD card and post it here. A clog or jam will not stop the printer from continuing to process the gcode file. The printer will continue on it's merry way, it just can't push plastic and typically the extruder motor will skip backwards because it can't go forward. The noise is an unmistakable click-click-click from the extruder.

What printer do you have? The Gcode Flavor in Cura must match the firmware that the printer is running. What version of Cura is it. If you select "Help | About..." it should show the version number and maybe who put it together. Not all versions are from Ultimaker.

I made a couple of changes to the testcube04x012....Gcode file to accommodate my Ender 3 Pro (no linear advance, etc.). I printed a few layers and it was perfect until it got to the infill. That printed way too fast at 120% flow so I went back and looked at your speeds in the 3mf file. They are all over the place. The flow rate through the hot end (mm³/sec) is jumping up and down. That alone will make printing inconsistent. I took your profile, made a couple of adjustments to what I know works on my machine, made the speeds consistent, got rid of Z-hops and retract at layer change and some other things. I kept the layer height at .3 and the various line directions settings. Attached is a gcode file and a project file. There is no bed leveling or baby-stepping in the gcode as I'm a paper guy but it should print on your machine. You could slice the 3mf file and your startup gcode would be in place. The Gcode file prints excellent on my printer with the 1.1.5 board and Marlin 1.1.8. After changing the extruder and the mainboard you did re-calibrate the E-steps correct? There are two models here. Both were sliced with 4.12.1. The beer bottle is included because it's close to flawless as far as I can tell. The flat print is your model using the gcode attached below and on the same printer. It also looks very very good. GVBooster.3mf GVUntitled.gcode

If you want to get really fancy we can teach you to merge two or more gcode files together at a height so you can mix layer heights and line widths and even print different sections with a different size nozzle. It's a bit tedious but not bad. The hard part is watching (with your fingers crossed) as the printer goes through a transition area of the gcode 9 hours into a print and you're wondering if you got the transition code right.

Re-formatting the memory card usually takes care of the problem. Some printers (Creality comes to mind) don't read cards over 32gb.

In that snippet of code: You are starting with T1 and it heats up and then starts the print. Through that code there is no mention of T0. I'd like to see the entire gcode file. If T0 is disabled it should not be heating up unless something like "Printer Settings" | "Extruders Share Heater" or "Extruders Share Nozzles" is checked. (BTW I could not find M298 or G200 on the RepRap Wiki. Are you running RepRap firmware?)

From the GitHub site: "We are expecting a certain clearance around the nozzle, so make sure there is space around -- basically a 45 degree cone going up from the nozzle tip on at least 5 centimeters, but larger parts may require more clearance. The angle to optimize for can be controlled from the command line." Non-planar slicing comes up every once in a while. Here is a CHEP video from a couple of years ago. There has been some noise regarding the patents on the technology (AutoDesk, University of Hamburg, et al). I believe @nallath has a better take on that.

I am sorry for my response in English. It's what I know. It would be helpful if you would post a gcode file that shows the problem, or copy your StartUp G-Code from Cura and paste it in here.

Post the STL file. From here it looks like the bottom isn't flat on the Cura build plate.

The Line Width IS the index distance between two adjacent extrusions. That's how Cura calculates the size of the rectangle it has to fill. When you factor in the length of the extrusion you get the volume of the extrusion. The E values in the Gcode are calculated to provide that volume of filament for any extrusion. If you have gaps between the lines then it is under-extruded. The question is why it is under-extruding when older gcodes do not. What filament diameter do you have entered in Cura? Does it match what the printer uses? Are all the flow rates under "Material" at 100%? Checking the printer - is Volumetric Extrusion (E in mm³) turned on? If Volumetric is turned off on the printer (normal) then check the Gcode flavor in Cura. It should not be set to Volumetric if the printer is not set to Volumetric. If you would load a model and set Cura up to slice and then use the "File | Save Project" command and post the 3mf file here someone will take a look. Since the older Gcodes are fine, that lets the printer off the hook (mostly). I don't like to guess, but when it's a question regarding something that is essentially very simple math then the problem is usually a setting in Cura that is conflicting with the printer. Cura is calculating the E values by one method and the printer is interpreting it as another method. As you've found out, the result of that is scrap. One more thing - what printer?

What printer are we talking about here? It can make a difference. I think it's because the "G0 X0 Y200" move is under the G91 and before the G90. That makes it a "relative" move and if it is to a position that is illegal to the printer it may just be ignored. With your printer as the currently active printer: under the menu "Settings" select "Printer" then at the very bottom "Manage Printers". A dialog will come up showing the currently active printer. On the right is "Machine Settings" which will bring up another dialog. Stretch the dialog box vertically so you can see all of the "Ending G-Code" at the lower right. I think it will look like the following: M107G91G1 E-1G0 X0 Y200M104 S0G90G92 E0M140 S0M84M104 S0M140 S0M84M82 ;absolute extrusion modeM104 S0 Change it to look like the code below (you can copy and paste it in) as your new Ending Gcode. If you have a Direct Drive on your printer then you may want to change the two retractions (in bold) which are suitable for a bowden setup but might not be for a DD. This is pretty much the stock Ender 3 end gcode with a couple of minor changes. ; ; End Gcode G91 ;Relative positioning G1 E-2 F2700 ;Retract a bit G1 E-2 Z0.2 F2400 ;Retract and raise Z G1 X5 Y5 F3000 ;Wipe out G1 Z10 ;Raise Z more G90 ;Absolute positioning M82 ;Absolute extrusion mode G1 X0 Y{machine_depth} ;Present print M106 S0 ;Turn-off fan M104 S0 ;Turn-off hotend M140 S0 ;Turn-off bed M220 S100 ;reset feed rate M221 S100 ;reset flow rate M84 X Y E ;Disable all steppers but Z ; End Gcode ;

In Windows they are in "...Program Files\Ultimaker Cura 4.x.x\resources\definitions". I'm not very familiar with the UM line of printers but I would assume they put that in because Relative extrusion isn't quite as accurate as Absolute extrusion. I'm not sure why that is but it may have to do with the way the numbers are rounded during the calculations.

"This setting has been hidden by the active machine and will not be visible." So it's an Ultimaker printer thing rather than a Cura thing. It's called out in the base "ultimaker.def.json" definition files as an override. "relative_extrusion": { "value": false, "enabled": false

With your model loaded and Cura set up ready to slice, use the "File | Save Project" command and post the 3mf file here. I would assume it's a setting somewhere and it should show up in a project file.

Practice, practice, practice...

Taa-Daaa! Congratulations. If I had a need to print more TPU models I would consider a Direct Drive. My bowden printer hates TPU and I limit myself to flat gaskets and things. A pancake stepper would lower the weight but from what I've read the lower torque can be a problem and limits the speed you can print. If there is going to be a limit then you may as well stay with what you have and see how it goes. Something to consider is putting a line into your StartUp Gcode like (Ex.) M201 X300. The M201 is "Max Acceleration" so in that example X300 would limit the X to 300mm/sec² accell. You may find you don't need it but if there are marks showing up in the print from hard stops and starts of the X axis then it would be something to consider.

Hello @gr5 and @csermie. The prime tower does have a couple of settings that determine how much material it uses for purge. The diameter (Prime Tower Size) and the volume (Prime Tower Minimum Volume) would seem to cover the situation. Having to drop down in the Z is never a good idea with a print on the plate. A couple of questions arise... #1) How would you know what height to go back to? If G60 (save current position) and G61 (return to saved position) are enabled in the firmware it can be done but otherwise there is no way to order the printer on-the-fly to "go back to where you were". And you better make the Z move first. #2) What would be the XY start location of the purge line(s)? Would that location need to index so the Z is always 0. If you always go to the same position and purge on top of a previous purge line then wouldn't that also be a sort of prime tower? Instead of being round it would be one line width wide by however mm's long and it would still be a volume much as "Prime Tower Minimum Volume" provides. There is going to be material lost in any switch over. Going from any color to white is always an issue as the white takes a lot more mm's of filament to clean out the previous color. There was a poster here who came up with a pretty cool idea for a wipe station. He added a stepper to a brush contraption mounted on the X beam. In the main Gcode file he would call a "cleaning routine" using M32. He had enabled G60 and G61 in his firmware so he could save the current position, go to the cleaning station, the brush would move back and forth, and then the print head would return to the saved position. It was a nice setup. Instead of a brush there could be a bucket to extrude into and a wipe feature to take the last booger off. But in the end I think that the amount of material used to purge would be the same in any scenario. What would be nice is if within the Cura prepare scene the Prime Tower representation had a grip so it could be dragged to a different location. Currently the location must be typed in manually in a trial and error sort of way. And now the rain has stopped and it's time to go fishing!

Are there some Gcode or Mcode commands in Klipper that differ from Marlin? I've read that Enders equipped with Klipper will run Gcode sliced for Marlin.