Non-LW question but looking for some insight from you knowledgeable folks:
I have a 2.5W 445nm banggood laser running grbl and I’m having a slight issue with cutting thin material like mylar and cardstock for a particular application. Note: I’m trying to get fine detail cut-outs (e.g. 1mm x 1mm squares).
For the most part I’m getting good clean vector cuts but for any given design, I always end up with several rectangles/squares that don’t quite detach - i.e. there’s always a tiny undesired connection that stays there.
What’s strange is that it is repeatable. As in every time I cut the same design, features in a given position will do it over and over again even though there are identical features (size and shape) elsewhere in the same design that dont do it. So, I think it’s got to do with what is cut before or after that particular shape.
I believe what’s happening is that the last segment of the shape is not meeting the node/first segment.
For the shapes in question, I’ve confirmed that the generated gcode starts and stops at exactly the same point. I’ve tried experimenting with various parameters (below) to no avail:
G1 feedrates
laser power
no. of passes
machine acceleration
G0 travels feedrates
M3 vs M4
Nothing seems to really help - It might stop doing it on one particular shape but start to do it on another. What else could I try to vary to get what I want?
Could it be that the path itself it’s separated? A filled item it’s not the same as a path depending on how it’s created.
Also u say it’s repeteable on a given position, does this mean machine location where the item is being cut?
The path is confirmed closed by analysing the design in inkscape and the problem shapes’ do start and end at exactly the same machine point as confirmed by studying gcode.
Not machine position but given position in the design.
It feels like it has to do with the dynamics of the path planner. Eg. may be related to what is happening after the last segment. Eg. Short travel vs long travel etc. I don’t know. It’s not quite random yet not quite predictable.
I had thought of laser delay but looking at the results it feels like the issue is not at the start of the shape but at the end so I would need a PreG0 dwell or something like that or maybe an force a little overshoot in last G1 segment before a G0.
Nevertheless, I’ll still try your suggestion and see if it helps as I could be wrong. Also, I’ll probably check the propegation delay in the driver circuit to confirm if laser is lagging movement.
Do you use M3 or M4?
M4 was developped lately to reduce overshoot at start and end of lines (that M3 is creating). In your case, it may be better to use M3, if not already doing.
Tried both M4 and then M3 (so power is constant through end of move). No difference with respect to this issue. I’ll do some more testing later tonight.
I updated to the new LW you committed Claudio and while trying to test Peters suggestion of adding dwell between G0/G1, I came across a problem with the new update. It seems something broke.
Having any command in “Pre-G1 Opt Command” or “Post-G1 Opt Command” causes issues such that when running the generated gcode within LW, it just pauses/hangs shortly after starting and starts misbehaving and acting strange.
Exporting the Gcode and running it in another sender does not have any issue so it’s not a CAM issue but something specific to LW.
Reverting back to previous version and doing exactly the same thing has no issues.
Running server on Win 7 PC or Rpi (both have this issue). Laser is running grbl v1.1e.
I first tried G4 P0.1 (both in Pre and Post) just for testing. When that started playing up, I just tried M3 (Pre) and M5 (Post) respectively. Both did the same thing.
As for the main issue at hand, I reverted to the previous LW commit and continued testing. I think a G4 P0.0001 command in “Post-G1 Opt Command” (nothing in “Pre-G1”) seems to have done the trick. Not quite as clean a cut as no dwell but with the small amount of dwell, all cuts appear to detach well every time. It’ll work just fine for this application.
