Today for the 1st time since I bought the software in October I used the flood fill scanning option. I was running a scan sized 340mmx214mm, before flood fill it estimated that it would take 34 minutes to complete the job, after flood fill it was 13 minutes. How did I miss this great option… THANK YOU LB
Be careful if you’re using a DSP controller (Ruida or Trocen) as they don’t like the paths generated if the design is anything but simple. If you’re using a GCode system, especially a diode, this is made for them.
Well…it didn’t really help me out. It took 30 minutes to do it. I have a Rubia controller. Oh well…makes me wonder how it would have taken had I not used the option.
I missed that you said “estimate” in the first post. The current preview estimates don’t include time to speed up & slow down, so they’re way off, and worse when using flood fill because so much more of the time is spent there. The new simulation engine will make the times more accurate.
3 Likes
In addition, if you reduce the parameters for acceleration on the controller (I had to do it to avoid occasional belt slips), flood fill may get slower, as it will introduce more direction changes, and the changed acceleration will add extra movement to each direction change.
That said, if I’m going slow, so that acceleration isn’t a problem, flood fill is much faster in many cases.
I have a Rudia controller with an 80W CO2 machine. I’ve experimented with Flood Fill a couple of times. I scan only text. Sometimes Flood Fill is faster where there are neighboring pieces of text so it scans each letter separately rather than scanning text in line with the travel direction wasting time traveling between each letter. Another option sometimes is to change the direction of the scan.
Tim