+Peter van der Walt I love your LaserWeb3 software but I have a couple of questions… I recently converted my K40 laser cutter to GRBL (latest master 0.9j) and I’m trying to get everything to work properly.
My biggest issue at the moment is the uneven speed at which GRBL executes small circles (huuuge amount of commands) because it seems LaserWeb3 does not support arcs and circles in this format:
G2 X -36.061 Y -19.061 I -1.061 J -1.061
Since one of those commands is replaced with an incredible amount of small vector movements my laser slows down significantly without reducing laser power (since it still receives the same feedrate command).
Are you planning on implementing arcs and circles? Or is there an option that I couldn’t find to activate them?
My second biggest issue is the work with DXF files. Whenever I export a DXF using solidworks (with the polyline option activated and merging set to 0.01) and import it into LaserWeb3 and check the gcode view as well as the movements that my laser makes, I realize that none of the paths, arcs and circles are connected to each other. Movements are erratic and an outline shape seems cut up into little chunks including the problem mentioned above that curves are not represented as arcs but as little tiny vectors. So tiny in fact that I’d question if this is necessary.
Are you planning on implementing a path optimization (traveling salesman) and arc estimation using a biarc Fitting algorithm?
Open your dxf up in something like Draftsight. I can almost promise you that your drawing is made of tiny polyline segments and not connected lines. You’ll have to use the Pedit command to join them.
@Joe_Spanier I just downloaded the software. I’d hoped that LW3 would support some kind of optimization…
@Timo_Birnschein i just perfomed a test with that file and cannot see any issues related to small lines on a circle or arc. It was flawless movement for me. I do know what you mean as it happens to me sometime
i do agree theres a need for path optimization and its great that you placed a issue on github.
I’ll try it tonight too. Ariel and I are both on smoothie though.
all the parts are broken into segments. Each segment will be its own move with its own accel/decel. Unfortunately this is very common. Even if you spend 5k on Vectric Aspire you will still have to join all these segments for proper operation.
@Joe_Spanier Yeah, I used the suggested software to get the same result. The thing is - and I do believe it’s a reasonable request since I find it all over the web for all hobby mills as well lasers - that dxf import handling should be the first thing to attack in a gcode generator.
I solved the problem using dxf2gcode with my own configuration for the tool as well as the post processor and then send the file with GRBL-Controller. Works like a charm, now. It also requires no manual fixing of the dxf file because it does it all automatically for me - including tool path optimization.
The file generated by dxf2gcode is no four pages long while the gcode generated by LaserWeb3 is several 10,000 lines long because it does not detect arcs.
@Timo_Birnschein remember this is a open source community developed solution. Not having something does not mean its not wanted but more like no time for the dev to actually add it. By all means if you know how to fix this or know someone who has it will make everyone very happy
@Ariel_Yahni_UniKpty I’m sorry, I didn’t want to sound unreasonably mean. I know it is open source and I support it. Which is why I added my requests to the github repository. I also added some additional information to what I was looking for in matters of algorithms. I believe dxf2gcode is also open so maybe it would be possible to port some of it’s dxf handling capabilities into LW3. I’d love that!
@Ariel_Yahni_UniKpty I also uploaded my complete project to github and tried to compile a proper readme for it in case you’re interested. https://github.com/McNugget6750/K40-grbl-board
https://github.com/McNugget6750/K40-grbl-board
That’s the spirit 
all good my friend. Countless hours and long nights to get what we have
Glad you found a work around that works for you. Peter has been playing with different dxf lib’s for a while. I know dxf2gcode was one. Not sure where that went. +Peter van der Walt
It’s not GRBL; it rips through line segments like mad when you tune its parameters for it and your sender keeps up. e.g. this is all lines:
The main reason web-based CAMs use lines is that it greatly simplifies processing. E.g. there’s no known offset algorithm for curves that has a bounded set of border cases. Some non-web CAMs risk using curves, but sometimes hit border cases and fail spectacularly: the cutter or laser goes where it should not go.
It’s funny seeing the king of cross-posting mention someone else cross-posting
