Jump to content

RoboDLC

Dormant
  • Posts

    30
  • Joined

  • Last visited

Posts posted by RoboDLC

  1. Tried twice to install 4.4.0 on my Windows 10 home 64 bit laptop.  On startup is freezes at "Loading plugins".  The only way to kill it at this point is through task manager and looking at background processes.  The install never makes it to showing up on the task bar as a running application.  I have installed 4.4 on two other Windows computers (10 Enterprise and 10 Pro) with no issues.

    Opened a "cmd" window and started it there on command line.  It came up after noting that Windows Firewall had blocked some of it.  I gave permission for it to run and it started.

     

    Now it starts from the icon.

     

    FYI,

    DLC

    • Like 1
  2. 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

  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. 8 hours ago, ahoeben said:

     

    It should, yes. I can't test it with all printers though. Specifically, I don't have a delta so I never tested the plugin with one.

     

    I don't know if there is an issue with using G92 with a delta running Marlin.

     

    How old is your Marlin? It could be this issue: https://github.com/MarlinFirmware/Marlin/issues/2106

    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. 22 hours ago, gr5 said:

    In cura go to the machine settings and make sure (0,0) is at the center (delta printers usually have that in the center) versus the corner (non delta printers usually have that in the corner).  There is a checkbox.

    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

    •  
    • Member
    • 0
    • 18 posts
    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. 5 hours ago, nallath said:

    But did it generate g-code outside of the buildplate? The issue reported is about UM3 and the bounding box it generates, so i'm pretty sure it's a completely different issue.

    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. On 4/3/2018 at 12:17 AM, tonycstech said:

    (snip)

     

    If you get those when you have travels from outside (such as open walls inside the printget blobs but outside walls are ok) you need to retract when you travel. (as well as making sure you dont prime too much)

     

    My printer can handle countless retractions all day long without getting jammed. I designed my own extruder for that purpose.

    Since most extruders cant handle too many retractions, retraction is overlooked by the slicer developers.

    They develop combing and all sorts of crap but dont incorporate retraction options very well.

     

    I am surprised to hear that $150 software has a problem that every free slicer has. LOL

    I am so happy i never purchased it.

     

    (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

    IMG_3617.JPG

  16. 1 hour ago, nallath said:

    Did you also set it to use the same acceleration & jerk? The speed is actually setting the max speed, which is quite different from actual speed (which is the result of max speed, acceleration and jerk)

    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.

  17. 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.

    IMG_3616.JPG

  18. 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

×
×
  • Create New...