LW4 Easytarget-org - feedback

Hello @easytarget ,
I’m starting to go through a “normal” use of your fork. Here are my observations. Many of those could be flagged as a feature request depending on the amount of work required.

  1. When importing my old R12 DXF sample, the layers are now tagged as their colors instead of their names. Is it something coming from the R2000 or something with the SVG?

  2. When changing the background colors in Settings / Machine the colors aren’t updating even when clicking the button beside the color selector. If I toggle the SHOW MACHINE selector above then it updates. It seems to be linked with the fact I’m using the PERFORMANCE DISPLAY CACHE option. If the cache is off, then it behaves as I’d expect it.

  3. I’d recommend moving the color selection in the application section, not sure if this is really related to the machine, makes more sense (to me) to be along with the grid spacing selection. Maybe also consider moving the SHOW MACHINE selector, but maybe its best to leave it where it is for legacy reasons?

  4. Would it be possible to double the width of the simulator slider cursor? I’m happy with the behavior and the ability to adjust the overall width. I made it 44 EM wide. I have a dual monitor setup and LW4 takes the main one at 1920x1080 with the usual xfce toolbars and launcher.

  5. I suggest the simulator slider is reset to the left after GCode generation. It looks strange to have it part-way when GCode has just been generated.

  6. GCode “eye” button in the GCode generator section now works on my setup, it didn’t on the current dev-es6 branch. This is good improvement as I had to save the file, open it, then delete it because they’d pile up in the Download folder, etc.

  7. The GCode magnifier / zoom control seems to work good. At first I wasn’t sure of its purpose as I always work in Doc zoom but I understand someone may have paths displayed that isn’t part of the GCode.

  8. The Gcode filename generation works good.

  9. The GCode Analyse button is an interesting feature, but the time estimation is missing the G4 delay codes. I’m adding delays on LASER GCODE START to allow my fumes extractor to spool up. The way I’m doing it is on gcode start the gas assist is toggled on and off and the system waits 5 seconds with G4 S5 as the fans spools up. After the 5 seconds is done I start the gas assist again. I also have a quarter second delay at the end to make sure the kerf is clean. However the estimate seems to ignore the G4 commands.

  10. The estimator also highlight something I haven’t dug yet which is the G0 speeds. Right now when I look at the GCode it looks like it uses the last G0 speed… which was when I was carefully jogging to set workpiece zero or checking boundaries. How is this supposed to be handled? I can put a G0 F8000 on the gcode start code if that is the intent.

  11. I noticed the tooltip for Settings / Gcode / LASER TOOL ON GCODE has now a mention about $INTENSITY. Thank you for this :slight_smile: I searched quite a bit in the forums then made a typo using %INTENSITY. This tooltip should help.

I have more stuff but they are more in the wish list bucket for now. I’m waiting for some parts for my machine and then I’ll get things cutting again.



Howdie! thankyou greatly for the feedback :slight_smile: super appreciated.

Ok; so some quick thoughts:

1 - Yes, I have replaced the old unsupported DXF importer with one that understands the post 2012 formats, especially ‘splines’. This brings much greater compatibility with most of the DXF’s I have encountered.
The downside is that it does not import by layer, it uses colours instead, this seems to be the current standard. It also doesn’t import text , which puts it equivalent to the svg importer. A text path generator for both would be lovely, libraries are available, but you need font importers and selectors etc, it gets really complex really quickly.

2 - Yes, this is as expected, display cache limits the number of refreshes done.
-note that I’ve just ‘fixed’ production build generation in my branch, and these should run faster. The latest preview is now a production build, much smaller, and certainly a bit snappier on my laptop. (npm run bundle-prod)

3,4 - Good ideas, which I have just implemented. I’m not too precious over this sort of change.

5 - see below

6,7,8,11 - :smiley:

10 - G0 speed for simulation is in settings->application, but note that no allowance is made for acceleration/deceleration in the time calculations. Not a big issue for profile cutting, but rastering on diode lasers (eg, not using burn-white) can suffer badly from underestimated times.

Simulator / Analyser:
I went into the code yesterday and, having learned new tricks, did some improvements here. The most obvious of these is that the ‘Analyse’ button is gone; analysis now happens automagically when code is loaded, and has no delay. The sim bar slider will also go back to ‘full’ when the gcode changes.

Someone (you?) was asking about G4 dwells in the time estimates. It’s worth noting the sequence for getting the estimates.

  1. Gcode generation happens using web workers (in parallel for multiple operations)
  2. The resulting gcode (a string) is stored, and can be saved or passed to the server on demand, but it is also passed to a fast gcode parser that splits each G0 or G1 command and it’s parameters into a fixed-format byte array. G2/3/4 commands are not processed.
  3. The resulting bytearray is passed to both src/draw-commands/GcodePreview and src/draw-commands/LaserPreview. These transform the bytearray into webgl preview paths which are displayed in the document window (the ‘show gcode’ and ‘show laser’ checkboxes simply enable/disable the path objects).
    -The Laser path is intensity coded, darker is higher power.
    -The Gcode path uses green for travel moves, Red for the default tool, and other colours depending on the T (tool selection) flag.
  4. The analysis (time and size estimates, move counting and sizes) are actually done by piggy-backing the gcode preview as it traverses the bytearray.

The end result is that both the parser and the gcode preview would need modifications to handle G4 pauses. This is a good issue for later; it would be nice if it could be done, and even better if G4 pause points could be shown on the path somehow.

The other point is that valid Gcode with G2/G3 arc commands will not be considered for time estimates, and will corrupt the preview display since the path will ignore them. This could be fixed by the parser deconstructing the arcs into their component segments and adding that to the byte array as as sequence of G1 moves.

Bonus: Gcode Header
I also added a new, overdue, feature. A text block you can define which will be added as a commented (;) header to the gcode. It supports strftime() substitutions and the LW version and selected machine base profile can be substituted in too. Find it at the end of the gcode settings.


@easytarget Be aware that the raster2gcode lib also adds a header to the gcode.

1 Like

All the generators already add some sort of header to their code blocks, the raster one is better than others.

But I wanted a common top level comment header that appears before the main body, has a date-time stamp, and is independent from other file and operation settings. Adding the LW version should also be handy when supporting people. The default is short and looks (to me) like:

; Generated by LaserWeb 4.0.999 on Sun, 13 Feb 2022 22:27:14 GMT
; Base profile: *gen_fluidnc

The date/time stamp is done using the %c strftime() option, and should adjust to the users ‘Locale’ format


I’m quite excited that you managed to make the bundle-prod target work again, I’ll try that out on my own fork as soon as I get the chance.


6 posts were split to a new topic: LaserWeb Cache Issues

I’ve tried a recent commit to your fork, just before the Dockerfile fix.
Overall it seems to work. The only odd thing I’ve found is a periodic error in the development console:

Looks like something is trying to poll and the connection is refused. Are you using some kind of custom lw.comm-server?
Note that I keep fighting with port numbers. Normally I use port 8000 for lw.comm-server and 8001 for the frontend. But with the no-cache python script or npm run start-dev I’m not sure where to change the port on the frontend, so I swapped things around with the frontend on 8000 and server on 8001. The error in the dev console could be related to that.

Edit: with npm run start-dev the frontend port is 8080

1 Like

Please do not get too concerned about the console errors; the actual user experience is more important.

That said, they are important for finding errors etc, so I do look at them, and this error is an old friend…
…Your saved config is trying to connect to lw.comm-server, and failing. Clicking ‘disconnect’ in the connection box should stop it.

For most LaserWeb frontend development you dont need a working comm-server connection; it’s only really necesscary when you are testing comms or control features.

Of course, we’re in full agreement on those topics. I’m looking to make sure the whole process makes sense, from the file import to the laser turning on. I’m working on the lw.comm-server to get the code ready for a pull request and share my code on for the manual pulse generator HB04B, I was wondering if I broke something or not.

4 posts were split to a new topic: Analyser fails on a single cut gcode?