Analyser fails on a single cut gcode?

CAD & CAM Tool Chain LaserWeb/CNCWeb
1

Hi,
I found a small bug with the automatic analyze function after GCode generation. It says the following:
Analysis failed
No tool operation
Check code before using

I’m attaching the DXF I used. It’s just an horizontal line, 20mm long. In my workspace I shrank it down to 10mm and repositioned it to workpiece origin.
H20.dxf (6.8 KB)

2

Curious. What do you see if you look at the gcode?
I believe that message means the path preview failed to find any G1 commands

3

There was a single G1 command, as expected. I’ll send you the GCode later today.

4

There are four types of programming error:

  1. Divide by zero
  2. Out of bounds
  3. Off by one

Seems entirely likely that a single line breaks this… I’ll reproduce and see if a fix is obvious.

Ps. Bumped into new thread

5

I cant seem to reproduce this; with your DXF file and a simple slowish laser cut I get:

Estimated run time: 0m, 12s
Tool duty cycle: 100%
Size: 20.00 x 0.00 mm
Code: 497 B, Moves: 1

and the gcode looks like:

; Generated by LaserWeb 4.1.0 on Wed, 06 Apr 2022 11:47:15 GMT
; Base profile: *gen_fluidnc


$Spindle/Type=LASER
G21       ; Set units to mm
G90       ; Absolute positioning
M4 S0     ; Laser on, zero power
;
; Operation:    0
; Type:         Laser Cut
; Paths:        1
; Passes:       1
; Cut rate:     100 mm/min
;


; Pass 0

; Pass 0 Path 0
G0 X0.00 Y0.00
G1 X20.00 Y0.00 S1000.00 F100
M5        ; Switch Laser off
M2        ; End

Maybe you were using a ‘Fill path’ or ‘Raster Merge’ operation?

6

Hi,
I think it’s either programming error 1 or 4. Definitely using Laser Cut operation.

When I run at 100mm/min, then I get the same estimate as you. When I run at 3000mm/min, then I get the error. Somewhere above 1476 mm/min it fails. GCodes between 1477mm/min and 1476mm/min look the same except for the F speed.

7

Ok, that’s a LOL. The analyser data is gathered as part of the path preview generation, I’m pretty familiar with it so I’ll have a further look later on.

Thinking about it, I’ll bet the time estimate is the culprit… 12s is OK, but go 15* faster and that rounds down to 0s and blows up the estimate. It’s a uncommon scenario but I’ll see what can be done.

1 Like
8

Ok, found it, indeed due to time estimate being rounded to zero. I’ve got a fix here: it’ll get merged in due course…

3 Likes
9

Great! One small step toward no errors, one giant leap for LW4-kind

3 Likes