Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by RoboDLC

  1. I have CURA 4.3.0 and Octoprint Connect plugin 3.5.9. The plugin has random issues. Often the Monitor page does not show the button to pre-heat the extruder. When a print has been started, CURA will randomly lose connection with the printer. When this happens I have to re-start CURA to "unclog" it so I can start another print. The printer/Octoprint are working fine, CURA just does not connect to the printer. Is there a troubleshooting procedure or any ideas what might be going wrong? Thanks, DLC
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. (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
  13. 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
  14. 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.)
  15. 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
  16. 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
  17. Nope. I wouldn't know what to set it to. S3D does not expose any acceleration or jerk modifications that it may put into the gcode. I assume that it is using the firmware defaults. I do not set those values at all in my CURA profiles.
  18. I have both CURA and Simplify3D and go back and forth between them depending upon my projects. I recently completed a new delta machine of my own design and have run into a problem. My Simplify3D profile works just fine, but I tried to create a profile in CURA that mimics these settings and it is a miserable failure. This is the first time I have had absolute failure in this process, but it is also the first time that I have tried to mimic profiles between the two programs too. I have attached a picture of the two results, the left is S3D, the right is my customized CURA 3.4.1 profile. This problem is obvious. But not the cause... Clearly I am under-extruding in CURA, filament grinding makes me think that I am under temperature as well, but I am not. It could be CURA is trying to push filament too fast, but why? Both programs are set to the same speeds (so far as I can tell) and same temperatures. I am missing some nuance. Is my "micromanagement" of the CURA settings the cause of this? I don't use the CURA stock settings ever since I typically use delta printers, and eSun PLA, for instance, likes 225C, not 200C (stock CURA PLA settings). What settings have I obviously run afoul of? Many thanks all.
  19. Well, if it helps, I just installed 3.3.1 on my Mac (OS 10.13.4), installed the new Octoprint plugin and all is working fine. I left the 3.2.1 install and 3.2.2 on my machine as fall backs. But, Occasionally I still get the "hashed" fonts in at least one of the custom setup windows. It didn't happen the second time, so I don't know which window caused it. So, where it counts, 3.3.1 is working fine so far on my Mac, and with Octoprint. Thanks, DLC
  20. This did the job. I will now go test some "stuff" and see how it all works. DLC
  21. I can't reach anything at this link. I don't have a login there. Thanks, DLC
  22. Me too. Almost everything on the "Prepare" page has to be "pattern matched" to be understood. OSX 10.13.3 DLC
  23. I will uninstall for now. Maybe a later version will work. Or, maybe not so much on a Mac. Thanks all
  24. Nope. I have only run cura on my PC up until now. My only laptop, for traveling demos is my Mac. Cura 2.7 is the first version I have tried to install on it. Edit #1: I just tried cura 2.6.2 - Same thing happens. One more detail in both cases: Initially the "C" appears on the dash board as the OS verifies the install, then it warns me that this is the first time it has run an internet download of cura. when I give the the "OK" it crashes silently, no error screen, no log file. Every attempt to start it past that point is a silent crash. Edit #2: Cura 2.6.2 will open and run if I open the app container, go to MacOS and double click on "cura". A terminal window opens and tons of info and a few errors are thrown out. Then cura actually starts and asks me to define a printer. Cura 2.7 will NOT work if I go this path, I get a similar error as I posted above in its terminal window. Hopefully something I am saying helps. Does no one else out there have this problem? Thanks, DLC
  25. There is nothing here: $User/Library/Application Support/cura//cura.log (OSX). So I tried running it on the command line and got the trace: Error in sys.excepthook: Traceback (most recent call last): File "", line 969, in _find_and_load File "", line 958, in _find_and_load_unlocked File "", line 673, in _load_unlocked File "", line 665, in exec_module File "", line 222, in _call_with_frames_removed File "/Users/ultimaker/build/2.7/build/inst/lib/python3.5/site-packages/cura/CrashHandler.py", line 10, in File "ExtensionLoader_PyQt5_QtCore.py", line 22, in File "ExtensionLoader_PyQt5_QtCore.py", line 14, in __bootstrap__ File "/Users/ultimaker/build/env/2.7/inst/lib/python3.5/imp.py", line 342, in load_dynamic ImportError: dlopen(./lib/python3.5/PyQt5.QtCore.so, 2): Symbol not found: ___sincos_stret Referenced from: /Applications/Cura.app/Contents/MacOS/./libQt5Core.5.dylib Expected in: /usr/lib/libSystem.B.dylib in /Applications/Cura.app/Contents/MacOS/./libQt5Core.5.dylib Original exception was: Traceback (most recent call last): Traceback (most recent call last): File "/Users/ultimaker/build/env/2.7/inst/lib/python3.5/site-packages/cx_Freeze/initscripts/__startup__.py", line 12, in File "/Users/ultimaker/build/env/2.7/inst/lib/python3.5/site-packages/cx_Freeze/initscripts/Console.py", line 21, in File "/Users/ultimaker/build/2.7/build/inst/bin/cura_app.py", line 54, in File "/Users/ultimaker/build/2.7/build/inst/lib/python3.5/site-packages/cura/CuraApplication.py", line 4, in File "ExtensionLoader_PyQt5_QtNetwork.py", line 22, in File "ExtensionLoader_PyQt5_QtNetwork.py", line 14, in __bootstrap__ File "/Users/ultimaker/build/env/2.7/inst/lib/python3.5/imp.py", line 342, in load_dynamic ImportError: dlopen(./lib/python3.5/PyQt5.QtNetwork.so, 2): Symbol not found: ___sincos_stret Referenced from: /Applications/Cura.app/Contents/MacOS/./libQt5Core.5.dylib Expected in: /usr/lib/libSystem.B.dylib in /Applications/Cura.app/Contents/MacOS/./libQt5Core.5.dylib Any clues here? Thanks, 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!