Next steps with my refresh project

[easytarget (Owen)]

A quick note; I have a list (on paper, a full page…) of things I wanted to do with LW, it’s 80% crossed out now. I just triaged it.

Before I PR anything I want to:

• Fix the spurious ‘no XXX ports detected’ warnings n the console.
• Add generic Marlin1, Marlin2 and RepRap profiles
• Line segmentation has some weirdness, it’s not properly propagated to all operation types as far as I can see; I need to test and fix if necessary.
• A Big fix: I just spent a couple of hours testing this to confirm what I can see in the code:
  There are two options Gcode Generator and Intensity Separate Line that confuse and conflict.
  For a start they only affect Laser operations, Mill operations do not use them at all.
  The Intensity Seperate Line option only affects Laser Cut operations, it is not respected by Laser Raster.
  The Gcode Generator option affects both Laser Cut and Laser Raster operations.
  I plan to remove the Gcode Generator option and make Intensity Seperate Line effective for All Laser and Mill/Lathe operations (it’s not that difficult, you do it in post-processing, the Laser Cut code shows me the way.
• A big fix related to the above, there is a post-processor that is run after the line separation has been applied, and only on raster jobs, which comments out all lines that begin with an S or G0 F.
  This will severely mess up raster operations if the user selects ‘marlin’ as the generator.
  I’m going to remove it, unless somebody can provide me with a very good reason why I should not…

Going Forward: I have a little hit-list (in increasing order of complexity)

• Vertical Rastering (and reverse diagonal), very handy for reducing line effects when lasering plastics etc.
• A-Axis knife cutter support for mill cutting
• Path generator; allow in-app generating of very primative SVG shapes which can then be directly injected into the documents list and positioned, resized, rotated and mirrored in the document editor window just like any other document path.
  The SVG module currently used in LW is capable of generating paths and has shape drawing functions. It should be possible to add a dialogue (like the vector generator one) that lets you generate circles, squares, paths, text etc.
  This, to me , is LaserWeb’s single biggest weakness compared to many other tools; It would be great if it can become an ‘all in’ tool for making signs, nameplates and cutouts from scratch without first needing to run Inkscape or whatever.
• Upgrade Node modules, remove unused ones, generally triage the list. Make sure we can build with node>10.
• Fix the React depreciation warnings seen on the browser console, upgrade to a modern react version. This is the one I dread.

[I wanted to write this down for my own reference, and to see if anybody has any thoughts, additions or subtractions]

[easytarget (Owen)]

Marlin - LaserWeb / CNCWeb is relevant here & I think it explains what I see in the code a bit better. I wont blindly strip out the Marlin generator without making sure equiv functionality can be selected in options.

[bullestock (Torsten Martinsen)]

Sounds good. Let me know once you have something ready for testing, my local hackerspace has a Lasersaur running LW4.

[cprezzi (Claudio Prezzi)]

Sounds good to me. Tell me if you need some explanations.

“Intensity Separate Line” was only implemented for laser operations because the S parameter in G1-3 is only supported by firmwares with special laser implementation. On mills you don’t want to change the spindle speed during a move.

The marlin generator was made in a time when marlin was not realy usable for lasers because it did not support S params in G1-3 commands. I don’t know if all actual marlin version support it now. If so, we could drop the marlin generator.

[easytarget (Owen)]

@cprezzi , @bullestock et al…
Sorry for not updating sooner; Life intervened, partly in the shape of a new large-format lasercutter and other practicalities.

My fork of the repo has been updated recently with my latest fixes, a couple of trivia/logging changes, and a re-written DXF importer.

I decided that the GCode generators work well enough at present and it was/is not clear to me how best to tackle resolving the complexity under the surface that I found when I dug deep, so I left them well alone (thanks for the explanation Claudio, it makes things a bit clearer now).

@bullestock ; there is a fully functional online version of my latest changes at:
https://easytarget-org.github.io/lw-mods-preview/index.html
Because it’s just the webapp you can browse to it with chrome, use it as normal to generate Gcode then save thhat to import/run on your machines, this is a good way to test it.

tl;dr
I started going through a collection of commercial DXF’s and other files I collected a few years ago on my new cutter. Most were for things my previous machine could not handle.

Only a couple of the DXF files would import in any usable form, for the rest I saw lots of XXX entity unknown/not supported errors from the parser followed by the re-save in R12 ASCII popup. I could salvage most of them by importing through Inkccape but decided to see if I could fix the parser instead.

So; I removed the old node dxf parser (a simple ‘dxf to json’ parser) and the internal ‘json entities to path’ counterpart, both of which were unmaintained for 8’ish years etc… and I replaced them with a actively maintained, newer, dxf parser node module. This module is part of a DXF->SVG toolchain, and produces a ‘parsed paths’ output that directly imports into LW and supports pretty much all the DXF entities currently used.

The only thing lost is layer information, but layers are not used in DXF-land to separate different cut types, colors are used for that. And I improved the color support.

All the DXF files that used to fail are now importing properly. I actually consider this a more useful thing to have spent my time on than the Gcode generators… which already work well enough.

My next target has shifted too; I want to fix up the corrupt displaying of SVG files, the path import is working fine but fill and line colors are badly screwed up, as is closed boundary detection in the display, actual path cutting and path filling from SVG’s seem squite solid. It is the rendering in the browser that is messy and has generated quite a few complaints here. I have often seen it myself, it looks ugly and stupid and distracts people in negative ways.

[bullestock (Torsten Martinsen)]

Good to hear that you have made progress.

I don’t really use DXF import a lot, but I was curious - looking at e.g. DXF color fixes · easytarget-org/lw.comm-server@03bad99 · GitHub, it appears that you have committed only the minified JS, not the actual source?

[easytarget (Owen)]

The code itself is in a branch in my fork of the Laserweb4 repo @ GitHub - easytarget-org/LaserWeb4: Collaborative effort on the next version of LaserWeb / CNCWeb

• the branch is called ‘mill-settings’, it’s the default branch on the forked repo.
• I’m building that branch of my fork and deploying it to my fork of lw.comm-server.

All the DXF related changes are in the following commits:

DXF import re-write

Process DXF colors correctly

[easytarget (Owen)]

Yesterday I sat down to look at the SVG stuff but got distracted.
End result: Vertical rastering (and reverse diagonal too) is now an option.
Really handy if the material you are cutting tends to show raster lines (eg lots of laser markable plastics) since you can mitigate that a lot by making two passes at right-angles to each other. It might also suit some machine geometries better too.

[cprezzi (Claudio Prezzi)]

Cool. Carry on with that good stuff