Jump to content

RoboDLC

Member
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

0 Neutral

Personal Information

  • Country
    US

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Found the problem. Not with CURA, but Marlin. I left USE_ZMIN_PLUG defined. For some reason that added an offset to the first layer. You have been warned. 🙂 DLC
  2. First off, I do not know if this is a Marlin issue or a CURA issue. It may be some interaction. I just updated my delta printer from a VERY old version of Marlin to 1.1.9. I am using CURA 3.6 with both the older version of Marlin and the newer one. After updating to Marlin 1.1.9 I used Pronterface to level the bed and check Z height (I manually level and have EEPROM disabled). Everything looked fine. I then used CURA 3.6 to fire off a print through Octoprint. My CURA settings have the first layer set to 0.18mm. I have changed nothing in CURA nor Octoprint between the time when I used CURA to do this print with the older firmware and the newer firmware. The hot end dropped to about 5mm off of the bed and started printing. Not optimal. I have checked my CURA settings, the Z offset is 0.0. I modified no Marlin configuration.h calibration options for bed leveling or calibrations - and note that Pronterface correctly followed G0 commands to go to 0.2mm. I have attached my gcode file. Any insight that anyone has is appreciated. Thanks, DLC CFFFP_Small_FlexiStego_Supports.zip
  3. It could very well be that old. I am planning to update this printer, but have not bothered until now because "If it ain't broke, don't fix it". I will try that. DLC
  4. Does this plugin work with non-UM printers? I am using CURA 3.6 currently. Yesterday I installed the available z-offset add-on from "Marketplace". I entered 0.1mm Z offset. My reprap delta printer (Folgertech 2020) homed, moved to the bed and then rose 200mm (or so) and started printing in the middle of the air. The front panel told me it thought it was a 0.1mm. It should have said 0.28mm, .1mm higher than my first layer setting. Currently this printer is running an older Marlin version. It is possible that the g-code was not recognized or perhaps was misinterpreted by the firmware. I plan on updating to the most recent Marlin and trying it again. Thanks, DLC
  5. I use both. CURA has terrible supports, S3D allows infinite customization of supports, angles, connections, specific locations, sizes and densities as well as finish layers. CURA just has, well supports. The support Keep out functionality is clumsy and often does not work, the customized add of supports doesn't work very well either. HOWEVER, the Experimental "tree support" in CURA can work wonders where S3D creates a support mess that cannot be removed, "tree support" can often make a print where the supports just snap off. Dual color support is stupid simple in S3D, and except for the fact that there is no built-in way to drop temps on the inactive head (you can create a script for a head swap, but they do not offer examples that I have found), I like it a lot more than CURA dual head setups which are harder to configure. They work, but S3D is a 5 second setup, CURA demands chin-knuckling time. S3D additions seem invisible to me. The latest (4.1.1) messed up the dual color settings and takes much longer to make the ooze shield and uses 2X the filament. It still works well, but the print times are greatly increased. Octoprint integration in CURA (with plug-in) complete and useful. S3D requires a custom post-processing script to use Octoprint and gives no feedback or ability to see camera output like CURA does. It works, but is not integrated at all. I find that I use CURA more often than S3D these days. But I occasionally use S3D to solve stubborn issues that CURA just won't print well. DLC
  6. I did this. I used this CURA 4.0 to print on another delta reprap, and it didn't go funky. So there was just something about this model and setup, I think. I will have to re-install the CURA 4.0 and do this model again so that I can capture the 3mf file for analysis. thanks, DLC
  7. Member 0 18 posts Report post Posted Friday at 10:28 AM · Print Exceeds Build Volume in Cura 4.0 I have a very interesting problem on a reprap delta printer. CURA 4.0 on a Windows 10 home computer. I tried to print this Thingiverse thing (The gnoll figure): https://www.thingiverse.com/thing:3362465/files with supports. I had no experimental options enabled and had no unusual gcode in the startup preamble (used default CURA). I submitted it through Octoprint to my printer. The preamble executed and the end effector dropped to a 15mm height, then it "wandered" off the build plate and continued to attempt to move far off of the build plate, causing the typical belt-grinding until I hit the kill switch on the printer. My Marlin firmware has a fixed firmware volume that is well within the limits of my delta printer. However, CURA managed to tell it to move off of the print bed until it ground the belts and could go no further. So, either a corrupt command was sent that messed up the firmware or there is some g-code that bypasses the firmware build volume limits. This model worked fine from CURA 3.6 and from Simplify3D, but failed in the same way every time with CURA 4.0. Thanks, DLC
  8. I have not read through the g-code to be certain, but the g-code clearly told the print head to go past the build volume. The same model with S3D worked correctly and the same model and settings worked fine with CURA 3.6. CURA did not warn me that the the head went out of the build volume though. What is really strange though is that my vanilla Marlin firmware would normally refuse to print outside of the firmware established print volume. So, some code was sent that bypasses that safeguard in the firmware. That may provide a hint. I too went back to 3.6. The potential for damage to the printer is too high to experiment with this much. My error may or may not be related to the OP error. I think that I will move this to a new thread and not taint this one. Thanks, DLC
  9. I had a very similar problem on a reprap delta printer. CURA 4.0 on a Windows 10 home computer. I tried to print this Thingiverse thing (The gnoll figure): https://www.thingiverse.com/thing:3362465/files with supports. I had no experimental options enabled and had no unusual gcode in the startup preamble (used default CURA). I submitted it through Octoprint to my printer. The preamble executed and the end effector dropped to a 15mm height, then it "wandered" off the build plate and continued to attempt to move far off of the build plate, causing the typical belt-grinding until I hit the kill switch on the printer. Thanks, DLC
  10. It looks to me like your nozzle is too close to the bed and that your bed isn't quite level - close but not perfect. In this case I would raise the nozzle a little and push more filament out slower on that first layer. Also, typically one doesn't do a width more than 2x the nozzle size. That is canon, so take it with a grain of salt. Like TMicke, says, raise the nozzle, increase first layer flow AND I suggest going a bit hotter on the first level. I use eSun PLA+ quite a bit and I print that at 225, 235 for the first layer with the fan off. Also, I would drop the speed down to 20% of your normal speed, and then some. If your settings work to drop print speeds if the layer time is very short, then this should work. Your skirt looks fine, so your first layer speed may be OK. I tend to explicitly set my first layer to print at 6-10mm/s when using CURA. DLC
  11. (I will avoid any feature flame-war comparison with S3D - I use CURA and S3D) Each of these slicers has something that the other one doesn't have. S3D does have useful retraction settings: mm retract, retract speed, coasting (letting filament run out at end of a run without extruding stuff), extra extrude after a retract, wiping,... There may be more, I have used these to great effect to help with blobs and strings. Sometimes what you need to do to correct the issue is not very intuitive... "Over" retracting can cause weird things to happen, under-retracting gets you blobs and strings, LOTS of retracts in a small space will give you headaches on a print... You end up fiddling until you find what is giving you problems. DLC
  12. I just had this happen and it took three days to figure it out. I use both CURA and Simplify3D, and my models had the exact same problem as you describe, in both slicers. What I discovered is that in places where there are a lot of retracts due to crossing open space to the next landing, if you have retraction distance set too high, your get what I call a "starve-gush" cycle that makes it look like your printer is alternating a weak extrude and then an over-extrude. Try reducing your extraction distance. I went from 5.5mm to 3mm and the issue went away. I too was using a 40mm/s retract rate. I am using a Delta printer, but the same dynamic might still be in play. DLC
  13. I have seen "Waiting for user input" on my printer when going through USB to my printer with 3.4.1. I never saw that before. In my case it seems to be caused when I preheat the bed and the nozzle via the "monitor" screen in CURA before I start the print job. Do you use the preheat buttons as well? Oh and. Setting up Octoprint is stupid simple and cheap. I have a ancient Raspberry Pi model B (not 3B, B) with a $10 USB WiFi dongle and a class 4 8GB SD card on my Anet A8. I do not know how I survived without Octoprint! I even run a USB camera on it with no problems at all. You can get a RPi 3B+, USB cable and power supply off Amazon for about $43, another few bucks for an 8GB SD card. Any RPi board will work but I think that the Pi Zero is a bit more of a hassle because of its limited I/O. Google Octoprint to find the image to put on the SD card and follow their instructions to set it all up. It takes about 10 minutes (after you dump the image to the SD card.)
  14. The solution appears to be obvious now. As I noted above, when I turned down the part fan, I got better media flow and it stopped under-extruding. But I am getting a rough spot in the middle of the print. I just did a Simplify3D print of the same part, filament, settings and speeds as CURA (as much as I can match these). That print was also messed up in the exact same place. SO... It looks like the fan is my issue in CURA. It also looks like I have a mechanical stutter in my linear rails, or something else in the drive train of my delta. I don't think that the issue lies with my "Itty Bitty Belted" extruder since the problem occurs at a specific time in the print that is clearly based upon height. Maybe something is binding up, or a "flat spot" in my GT2 belts or pulleys. I will do a complete tear-down and check all those parts. I have had issues with these rails before - It may be time to get another set if I can't clean them out to fix them (or whichever one it is). Thanks for your help everyone, DLC
  15. Update: No idea about acceleration and jerk. It is nothing that I have ever fiddled with in CURA before and I'll need to read up on just what it does. Yes, the filament is 1.75mm in both S3D and CURA settings. HOWEVER I found something that is starting me on the way to a fix. This printer has a VERY effective part fan ducting system. I dropped the starting fan speed in CURA to 40%, with a maximum of 60%. This eliminated the filament starvation, but I still had some rough spots in the beginning. I then SLOWED the first layer down to about 6mm/s and this cleared up the initial roughness at the plate. The attached print is of the beloved "Benchy" calibration print. We start out well, end out well and go whack in the middle. So, that is a puzzle. I am running an S3D Benchy on this printer to see if the problem may be mechanical (one of the linear rails has a rattle to it that I don't like). Thanks all for the suggestions, DLC
×
×
  • Create New...

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!