GregValiant

You might try changing the line width also. It's usually set to the nozzle diameter but can be different. Try .6 line width and bump the flow rate % a bit. If the top cone had steeper sides the individual lines might bond instead of falling into the center.

I've been intrigued with saving a print-gone-wrong since I started using the Ender last December. Right away I came across M27 and M26 that use the Byte Offset of the print position in a file. I got Micorsoft Excel to talk to the printer and by crunching a gcode file with some Visual Basic macros, I figured it out. I started printing Mrs. Rabbit as a conventional slice with infill and wondered what would happen in Vase mode. So I aborted the print and had Excel send an M27 to get the byte offset and then the XYZE locations, sliced the Jessica file in vase mode and was able to justify the byte location within the new file, used M26 to jump to the byte offset in the new file and used a G92 to synchronize the extruder, and regular G moves to get the XYZ synced in and it worked very well. Off course she has some.......interesting.......horizontal parts that don't do well in vase mode, but what the heck. An experiment is an experiment. She would be impossible to print completely in vase mode since the model is standing on a flat raised dais. The file with infill handled the platform (and part of her feet) as you can see in the second image. The last image shows the area of the seam from the other side and not backlit. Even with the print in my hand I can't tell exactly where one file stops and the other starts. I am officially pleased with myself for figuring this out (even if I do feel a bit like Igor). Mrs. Rabbit appears courtesy of Thing-i-verse and she will be on a pedestal that proclaims "I'm not bad. I'm just drawn that way."

Unless you are using vase mode (spiralize outer contour), there is always a Z seam. Take a look at "Z Seam Alignment" and "Z Corner Preference".

Rule #1: When you're dumb - you suffer.

Since it's a gcode file it was sliced with something, and that something may have had a different "bed size" setting or "Center 0" that isn't matching up well to your machine. If you're comfortable with it you can make a one-time change to the Home Offset X value and bring the print back to the center. As a matter of fact, you should check your home offset numbers just to make sure. They should be something like X-10 Y-10 Z0. The beginning of the Gcode file may have something like this: ;MINX:65.158 ;MINY:92.5 ;MINZ:0.2 ;MAXX:159.865 ;MAXY:131.117 ;MAXZ:59 If any of those numbers are negative numbers then the model was sliced for a machine with a Center 0. By default Cura always plops down a model with the center of geometry in the center of the bed (provided nobody slid it around). If you take the average of the MinX and MaxX shown above, it comes out to 112.51. My bed (Ender 3 Pro) is set up in Cura at 225 x 225 so the center is 112.5. The math shows that the model is in the center of the bed. Rule #4: Never blindly trust a Gcode file that somebody else created.

You don't have to check the entire file. Just the last few lines. They should show the heaters shutting off and the steppers disabling. My gcode files have a lot of comments after the ";End of Gcode" line. A quick glance will let you know if the file is fit to print. You can open the file in your text editor and do a "Find" for "End of Gcode". If it's in the file then the file is complete. Just above that line you should see M106, M104, and M140 all set to zero. The end of the file should look something like this: M203 X900.00 Y900.00 Z50.00 E50.00; Last move of the actual print G1 X0 Y225 ;Present print M106 S0 ;Turn-off fan M104 S0 ;Turn-off hotend M140 S0 ;Turn-off bed M84 X Y E ;Disable all steppers but Z M82 ;absolute extrusion mode M104 S0 ;End of Gcode I'm still thinking it was corruption of the card. Hard to chase down. Cura seems very stable and not prone to doing stupid things. You may want to re-install for piece of mind though.

The file got corrupted somehow. That looks like machine talk (maybe hexidecimal, maybe garbage) that the text program is trying to decipher. Could be that some of the file ended up in a bad sector on the memory card. Try re-formatting that card. Some of the Creality card readers don't seem to like really large capacity SD cards either. I don't see the printer writing to a file though. The garbage in that file starts in "mid-line". The end if the file is missing. Did you make a copy to your hard drive right out of the slicer so you can compare the two?

I hope we are not talking apples and oranges here. Minimalfort sliced with 4.6.1 and got the seam. You sliced it and there was no seam. I sliced it with 4.6.1 and there was no seam. The Torgeir and Greg gcode files are extremely similar. Minimalfort's gcode file is very different. It must have been a settings thing. Time to move on.

All the short lines in the seam are about .15mm long. The longish ones are about 1.3mm long. I don't understand why the one I sliced didn't do it. The same version of Cura should produce the same results. The total movement inboard is .134mm for each jog and is consistent up the model. Another thing is that the Gcode file you provided is 2.2MB and the file I generated is 4.1MB. It is attached. EDIT: Here are some lines of code from MinimalFort's gcode file: G0 F9000 X42.581 Y47.395 G0 X42.527 Y47.627 ;TIME_ELAPSED:397.392266 ;LAYER:5 ;TYPE:WALL-OUTER G1 F1200 X44.104 Y46.187 Z2.002 E550.2832 And here is the same area from the one I created: G1 X108.211 Y53.26 Z1.199 E3897.18335 G1 X110.361 Y53.145 Z1.2 E3897.25663 ;TIME_ELAPSED:2464.219053 ;LAYER:5 M106 S191.3 ;TYPE:WALL-OUTER ;MESH:Kegle1.stl G1 F2237.6 X112.554 Y53.106 Z1.201 E3897.33128 As you can see, there are no G0 lines in the one I created and in fact there are none anywhere in the entire file. When I have AutoCad read in a gcode file the color of the line is determined by words like "Mesh" or "Wall" or "Infill". The Gcode file of MinimalFort came in as red which is Outside Wall. The one I did came in as yellow which is Mesh. (The M106 line is because I had the fan set to step up speed by height.) Another thing is the feedrate. In the first file it is consistent, layer by layer, at F1200. In the second file it constantly varies by layer going from a max of F2237.6 at layer 5 down to F600 at layer 498. All in all it doesn't seem possible that these were sliced with same software with near identical settings. On another topic Tongeir - How do you get that fancy view in Cura. Mine looks flat. Kegle1.gcode Kegle1.3mf

I like this kind of stuff though. Keeps the brain loose. I read your gcode file into AutoCad and here it is You can just see the magenta line running up the cone. They are short dashes (G0 moves) in the XY plane. There is no Z movement in any of them. Here is a front view of the same model with the G0 layer isolated. You can see the G0 moves going up the cone. Here is the one I sliced from your stl file. and the front view of the same one. In the one I sliced - you can see that all the G0 moves are at the bottom in the mesh. Nothing is running up the cone. There is no seam in the one that I sliced (Cura 4.6.1) If you take a look at the statistic text in the images, you can see that the one I sliced has twice as many lines in it as the one you sliced. It's almost as if I was slicing a different model. I haven't had time to mull this over yet. Something is going on though. But I was right when I said no Z seam. What you have there is an XY seam.

I'm sorry, but what do you mean by a "block thingy"?

I wrote a bit of Visual Basic code I use to read gcode files into AutoCad. I brought in one of the boat files and it shows a helix all the way up. It's pretty close to a perfect helix too. No jig-jags at all. Looking at the 3d print from that boat file under a microscope I don't see anything that could be taken for a seam. I was pushing a lot of plastic to make a thicker hull but that shouldn't make any difference. A seam line is a seam line. I'd like to stare at that Gcode file for a bit. Can you put it up here?

You need one of the moderators for help here. Gr5 or Maht come to mind. I draw my own stuff so if there is an issue like this I add a feature (big circle or something) 2 layer heights tall where I want it to sit in the slicer. It's a way to fool Cura into producing what I had in mind. I know, it's a workaround and not solving anything, but it gets the job done.

I wonder if there is something in the model file that is causing it. To my knowledge, slicers don't make things up. It looks like you've tried manually moving it...how about rotating it in space. Maybe a different orientation will help. If it fits within the build volume you shouldn't need to slice it into smaller pieces.

This was posted in January and there hasn't been a follow-up. I wonder how he/she made out. Cura has been updated twice since then. Sometimes I find it helpful to just think on stuff for my own knowledge...and I did. +1 on No Z-Seam. The Z value changes incrementally and constantly as the nozzle goes around the shape. Since it is a single wall construct, there is no sideways step either (i.e.: to a second line of wall). There really shouldn't be a Z-seam. Another way to look at it is there is only 1 layer. I've printed a 3 piece 650mm sailboat hull. There was no z-seam with Cura 4.6.1. Looking at the Gcode - within every 360° movement of the nozzle around the part there were 140 discreet steps in the Z and at that point it was 1 layer height (.20mm in my case) higher. A .0014mm step every 2.5° isn't really noticeable.

If you do a search on ThingiVerse for Mouse Ears you will come across some that you can download. They are like poker chips. With your part in the slicer, you add a mouse ear to the end of long thin parts of the print at bed level. Think of an octopus arm with a catchers mitt on the end. The poker chip doesn't tend to warp upward although they will need to be trimmed off later. There is a bit of a learning curve with PETG. Mostly, you have to learn how not to burn yourself on the bed or nozzle. You'll be running them very hot.

I'm saying I hope so. Good Luck with it. There is more information available if you do a search for "Pausing" +Repetier. There is also a little bit of information on the MonoPrice site.

And this is general advice... It's a "practice" thing too. I found that nozzle temperature varies more by color using PETG. Some colors can get pretty stringy and have to be run cooler and slower. Warping becomes more of an issue as long narrow features want to lift off the bed. Make sure that your new Bowden tube is cut exactly square, and that the nozzle butts up against the tube just before it makes contact with the inner steel tube of the hot end. You want a good seal there.

There are 4 Pause at Height scripts in the Cura extensions. One is listed for Repetier (which I think the MonoPrice printer uses). The one that seems to work with the Ender 3P/Marlin is simply called Pause at Height. It inserts this code ;TYPE:CUSTOM ;added code by post processing ;script: PauseAtHeight.py ;current z: 5.2 ;current height: 5.0 M83 ; switch to relative E values for any needed retraction G1 F300 Z6.2 ; move up a millimeter to get out of the way G1 F9000 X190 Y190 G1 F300 Z15 ; too close to bed--move to at least 15mm M104 S0 ; standby temperature I would change this line so the Hot End doesn't cool down M0 ; Do the actual pause TO RESUME you must click the button on the LCD M109 S215 ; resume temperature G1 F300 Z6.2 G1 F9000 X85.054 Y112.572 G1 F300 Z5.2 ; move back down to resume height G1 F3000 ; restore extrusion feedrate M82 ; switch back to absolute E values G92 E749.35974 From what I can see it does everything you would want it to...Lift, get out of the way, wait for the filament change, get the temp up to what it was, go back to where it belongs, and reset the extruder in case some filament was extruded during the color change. A nice tidy bit of code that should work with the Ender 5, but will not with JGord's MonoPrice (Repetier doesn't support M0 as a pause code).

Are you refering to one of the Pause-At-Height plug-ins for Cura?

Slowing down may have been the key. I can almost convince myself that I'm seeing some layer shifting there in the right image but it appears to be only in the cape which is not possible. You might want to check your belts though. It can't hurt.

When I imported the models into Cura it reported an error "The model is not manifold". I haven't seen that before. It mentioned that the Highlighted areas (polka dot area in your top image) contained extraneous surfaces. The model did slice and does not show the red "Outer Wall" lines between the cylinder and the vertical feature. It sliced as a single piece with infill between the two features. I had Support turned off.

This is a good one. Malegelebi may have given the best clue. His comment regarding the ABL indicates to me that it is indeed a Marlin issue. An invalid mesh? That makes more sense to me than Marlin just making up moves which I have to say is what it looks like.

Well, the cone is not connected by anything until it merges with the gantry thing. It's non-symmetrical as well. Unless the support wrapped around it I think it would fall over. And if the support did wrap around it, the head would crash. I think I'll stick with 2 pieces. One could be the cone and gantry (without the base) printed upside down. The second could be the base of the gantry. They'd need locating holes/pins but no support would be required.

Perfect. Thanks for responding with the fix.