Carving speeds

This topic contains 7 replies, has 5 voices, and was last updated by  Ryan 2 months, 3 weeks ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #99082

    Dave S
    Participant

    Hi.   I’m working on carving a sign, and it seems the speed is pretty slow and jittery.   Not sure what is effecting it.   I have the feed rate at 50 mm/s (up from 15 mm/s that was initially recommended).  Thing is I have already run this project before and I don’t recall it being so slow the first time.   But then again I was pretty excited it was even working.   Regular engraving paths seem to be fine (speed wise)  Is it normal to be slow when carving?   Video attached may be poor, I have to convert from iPhone to Windows to shrink it down).  Ignore the duct tape nightmare that is my dust baffle.  FWIW, I’m running on Rambo 1.4 with a Raspberry Pi Zero W feeding it.  The artwork comes from a traced bitmap in Inkscape maybe not the smoothest boundries.

    On a related note.  I am trying to cut painted MDF in this case.   As you can see I am getting paint folding back on the edges.  I am not sure if it’s relate, but I noticed if I rerun the same job, where it re-cuts it gets smoother some (sort of a finishing pass).  How to I get carve to make a finishing pass on purpose?   I tried setting the allowance, but it just runs the same regardless.  Meaning it does not appear to be going back to clean up.  The paint folding may be because it is not fully cured too.  It was just painted today.

    Thanks in advance for any advice you might have about either issue.

    Dave

    #99086

    Jamie
    Participant

    Look at your g-code and see if you have large numbers of very small moves.  I have seen this happen on Estlcam’s carve feature.  Here is an excerpt from one of my jobs:

    G01 X64.2859 Y16.4484 F800
    G01 X64.2368 Y16.4255 F800
    G01 X64.1859 Y16.4070 F800
    G01 X64.1335 Y16.3929 F800
    G01 X64.0801 Y16.3835 F800
    G01 X64.0261 Y16.3788 F800
    G01 X63.9490 Y16.3782 F800
    G01 X63.8490 F800
    G01 X63.7490 F800
    G01 X63.6490 F800
    G01 X63.5490 F800
    G01 X63.4490 F800
    G01 X63.3490 F800
    G01 X63.2490 F800
    G01 X63.1490 F800
    G01 X63.0490 F800
    G01 X62.9490 F800
    G01 X62.8490 F800
    G01 X62.7490 F800
    G01 X62.6490 F800
    G01 X62.5490 F800
    G01 X62.4490 F800
    G01 X62.3490 F800
    G01 X62.2490 F800
    G01 X62.1490 F800
    G01 X62.0490 F800
    G01 X61.9490 F800
    G01 X61.8490 F800
    G01 X61.7490 F800
    G01 X61.6490 F800
    G01 X61.5490 F800
    G01 X61.4490 F800
    G01 X61.3490 F800
    G01 X61.2490 F800
    G01 X61.1490 F800
    G01 X61.0490 F800
    G01 X60.9490 F800
    G01 X60.8490 F800
    G01 X60.7490 F800
    G01 X60.6490 F800

    Since it is moving purely in X, I know this is sub-optimal (putting it nicely) and not a question of resolution.  It’s quite annoying and I have considered getting SD support purely as a workaround for this.

    This might not be your problem but it is something relatively simple to check.

    #99087

    Dave S
    Participant

    That does seem to be a possibility.  Here is a piece of the file I was running.   Looks like pretty small moves.   What I am running is a small portion of a previous job to test cutting thru paint.  I looked at the original job file I as well and it does not seem as dense.  Wonder if I changed something I shouldn’t have in Estlcam.

    ;No. 1: Carve 38
    G00 X192.0047 Y47.4028 F2100
    G01 Z-2.6250 F3000 S24000
    G01 X192.0473 Y47.2436 F3000
    G01 X192.0888 Y47.0812 F3000
    G01 X192.1303 Y46.9104 F3000
    G01 X192.1690 Y46.7408 F3000
    G01 X192.2060 Y46.5680 F3000
    G01 X192.2412 Y46.3908 F3000
    G01 X192.2743 Y46.2090 F3000
    G01 X192.3050 Y46.0220 F3000
    G01 X192.3329 Y45.8297 F3000
    G01 X192.3574 Y45.6314 F3000
    G01 X192.3781 Y45.4268 F3000
    G01 X192.3944 Y45.2130 F3000
    G01 X192.4052 Y44.9853 F3000
    G01 X192.4091 Y44.7563 F3000
    G01 X192.4055 Y44.5194 F3000

     

    #99243

    Ulli
    Participant

    Video? Don’t see any here.

    The vector increments look small, but then they are in the order of magnitude of tenths of a millimeter, which serves a good surface.

    In any case, let any paint, putty, glue etc dry, really dry and cure before you work on it.

    #99285

    Jamie
    Participant

    Hmm, my math is not working out like I thought it would.

    At 250k bits per second
    you would get about 25 k bytes per second
    which is about 1000 commands per second if each command is roughly 25 bytes
    which would be 100 mm/sec if each command is a 0.1 mm movement
    which would be 6000 mm/min feed rate top speed, which is sufficient for the requested feed rate.

    And yet I see jerky, slower than expected movement that appears to correlate with large numbers of tiny movements.  Perhaps it is not the communication speed but the computation speed of the Mega 2560 that is the limitation?  I was already considering adding SD support as a workaround, but now I want to add SD support as an experiment to see what happens…

    #105116

    Bill
    Participant

    F3000 on a Z movement will not work, it should be capped at F480.

    #105124

    Ryan
    Keymaster

    Perhaps it is not the communication speed but the computation speed of the Mega 2560 that is the limitation?

    Yup, were were capped at 8.4mm/s with allthread at 32nd stepping. so I think is was 5100steps/mm or so. So that is something like 40k-50k?

    #105125

    Ryan
    Keymaster

    …and it does not handle an overflow well, it just goes nuts.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.