"Laser Raster" lasering only one direction (e.g. always from left to right)?

[Sebbb]

Hello,

it seems, my laser/my motors have issues with the timing at high speeds, so when using the laser raster function, the laser start position is always moved a bit to the right/left, depending on from which direction I come:

Is there a way to configure that Laserweb always only rasters e.g. from the left to the right, and then returns to the left without switching the laser on?

[cprezzi]

I'm sorry, there is no such feature in LW4.
You should try to solve the backlash problem, because you will see this problem on vector cutting too.

[Sebbb]

Hey,

I don't think it's a backlash issue, I lasered some test patterns and it's more a timing issue - the laser is already in movement, due to inertia it's already 0,1mm further than expected by the firmware - you can't stop a movement without a slight overshooting.

It's not much, it's only 0,1 mm, at a feedrate of 1500mm/minute. At 300mm/minute everything aligns perfect.

Would it be possible to add such a feature, as I don't think I'm the only one with this problem?

[cprezzi]

• Is this a diode laser or a CO2?
• Is the laser late or the moves? (I heard of cheap diode drivers that had a delay between PWM input and laser output)
• Which controller board are you using?
• Which stepper drivers are you using?

You are the second one with this issue (as far as we know) since LW4 exists.

[Sebbb]

Hello,

it's a laser diode, the laser is late. From my feeling it's not an issue with PWM latency (although this is hard to prove, I could install a logic analyzer together with a photodetektor to validate, maybe I'll do that later).

I'm using an BTT SKR 1.4 Turbo with Marlin 2 (bugfix branch) and TMC2209 stepper drivers, but I had the same issues with Smoothieware on this board and Marlin 1 on a Creality 2.1 stock board. I replaced the wheels of my CR10-S with linear rails.

As I'm new to using my 3D printer with a laser, what are common feed rates?

Thanks, Sebastian

[easytarget]

Also, have you carefully tuned your Jerk and Acceleration settings for 3d printing (or taken default suggestions for your printer)? Settings good for 3d printing might not work well with a laser, especially if the carriage weight changes when you mount the laser.

[Sebbb]

@easytarget For Marlin, I took over the settings for my 3D printer model and did not adjust them for the laser. For Smoothieware, I took the default settings and did not adjust them.
But the carriage moves (at least from what I see) linear, only the timing for laser pulses is wrong.

I took a logic analyzer and photodiode and measured how long it takes from the first pulse until the diode triggers: ~2169 ns (~2 µs). The PWM frequency is 20Khz (50 µs per pulse width).

So there is only very little delay between PWM and laser output.

Any other ideas?

What feed rates do you use?

[Sebbb]

... I could connect also the stepper driver pins (en, step, dir) to the logic analyzer and count if it's a issue with the software starting the pwm pulse too late or a hardware issue 🙈

[cprezzi]

It sounds very odd that you see the same issue with Marlin and Smoothieware. I would suggest to try grbl-LPC but as far as I know the SKR 1.4 Turbo is not compatible.

Can you please post the gcode you used?

Which gcode generator did you use? For Smoothieware, and Marlin >= 2.0.6 you should use the default generator, for Marlin 1 the special marlin generator. (see https://laserweb.yurl.ch/documentation/initial-configuration/70-marlin for details)

[easytarget]

As a suggestion; have you tried changing the line angle to 45 degrees (it's an option in the fill and raster menus) It may make this less noticable. What happens if you try 90 degrees, so the Y axis (eg the whole printbed) is doing the scanning motion instead of the X axis? different?

Beyond that, I dont think there is anything much that can be done in LaserWeb to help with this,.
Please send a copy of the code as requested, but I'm pretty certain LW itself will have produced properly aligned line ends (we'd have noticed by now if LW produced bad code there by default)

TL;DR ?? (I got intrigued by this, so here are my thoughts)

I notice you have a CR10, this has a fairly lightweight frame and X axis because it has a very light bowden printhead assembly. If you have put a big-ish Laser on this (my 18W unit is 485g, half a kilo..) then you will need to reduce the jerk and acceleration values on the X axis since the head now has a lot more inertia and hence more overshoot. Wobbly X axes are pretty much 'a thing' on cantilever and bridge type 3d printers, increasing the carriage weight considerably will only increse this

Also.. You have upgraded to linear rails, if these have plain bearings then you will have more sticktion (binding at movement start) than with rollers. Another area where acceleration and jerk; plus correct lubrication (oils, not greases) and very careful alignment help. https://www.linearmotiontips.com/how-to-reduce-the-effects-of-stiction-stick-slip-in-linear-guides/

Finally; make sure your firmware has a real proportional laser mode.. so that the laser power is scaled down while the head is accelerating/decelerating. Otherwise you might go from jagged edges to over-burned edges. I dont know what the current state of this is in marlin. I use GRBL (ESP32) these days and never really bothered with anything else for my CNC.

You will notice that I am not blaming poor timing/signalling from your board controller. I would be utterly amazed if any stock controller board+firmware was getting this wrong by such an extent.

[Sebbb]

@cprezzi Sure, here are the files and images.

gcodes.zip

I used the default generator and spooled from Laserweb4 via USB directly.

[Sebbb]

@easytarget

Thanks for this long post.

I assume setting it to 45° will help, nevertheless, I try to figure out the reason..

Indeed, I don't think it's an issue of LaserWeb. I asked for an option to work around that, but I also fully understand why workarounds are not wanted - and of course are not a good solution.

My laser is a NEJE 450nm 7W with a weight of 116g, additionally an aluminium plate, I didn't weight it, but I'm sure it's all equal to/lighter than my printing head.

I completely cleaned my linear rails, partly replaced the bearing balls, all moves really easy. 3D prints come out perfect without any ghosting since I replaced the wheels.

For the firmware: Marlin 2 has several options for adjusting the laser intensity:

 * Scale the laser's power in proportion to the movement rate.
 *
 * - Sets the entry power proportional to the entry speed over the nominal speed.
 * - Ramps the power up every N steps to approximate the speed trapezoid.
 * - Due to the limited power resolution this is only approximate.
 */
#define LASER_POWER_INLINE_TRAPEZOID

/**
 * Continuously calculate the current power (nominal_power * current_rate / nominal_rate).
 * Required for accurate power with non-trapezoidal acceleration (e.g., S_CURVE_ACCELERATION).
 * This is a costly calculation so this option is discouraged on 8-bit AVR boards.
 *
 * LASER_POWER_INLINE_TRAPEZOID_CONT_PER defines how many step cycles there are between power updates. If your
 * board isn't able to generate steps fast enough (and you are using LASER_POWER_INLINE_TRAPEZOID_CONT), increase this.
 * Note that when this is zero it means it occurs every cycle; 1 means a delay wait one cycle then run, etc.
 */
#define LASER_POWER_INLINE_TRAPEZOID_CONT

/**
 * Stepper iterations between power updates. Increase this value if the board
 * can't keep up with the processing demands of LASER_POWER_INLINE_TRAPEZOID_CONT.
 * Disable (or set to 0) to recalculate power on every stepper iteration.
 */
#define LASER_POWER_INLINE_TRAPEZOID_CONT_PER 10

(I also tried disabling LASER_POWER_INLINE_TRAPEZOID_CONT_PER, this didn't change the behavior)

So, don't get me wrong, I never thought it might be a Laserweb4 issue. I just have no clue anymore where this could come from..

BTW, I noticed an issue with controlling my board with marlin-bugfix-2.x via USB, the "laser test" / "laser off" buttons don't work. Unfortunately, it does not show what command it would send.

[Sebbb]

Out of curiosity, I tried setting the acceleration to 25 and junction deviation to 0.025:

[Sebbb]

I think, I have to change my statement "the laser is late". Actually, the laser seems to fire too early.

[easytarget]

Humm.. Yep, I'm a bit flummoxed. You shouldn't have stick issues with ball-race linear rails, that weight sounds very good, and marlin does what is needed..

I'd be very interested to know if this happens with 90 degree cuts, if it only shows for one axis that would be a useful datapoint.

Also; staring at the images, it's prety obvious that there are bands where this is worse, and these correspond to the places where the laser is switching on/off while in motion, and at the endpoints for each movement t looks better.
It really does look like a timing issue doesn't it? I'm just at a loss to explain how two different controllers/firmwares could both show the same problem.

Since you have the analyser. maybe you could compare the pwm signal from controller pin with the actual signal from the driver module going to the LED itself, the timing should be identical. Also; (and I'm clutching at straws here) make sure you are driving a digital input on the laser module, one of my modules has a ttl/analog switch, the analog mode is very non-linear when driven with pwm signals.

PS: For the laser test the commands (marlin) are : 'G1 F1 M106 S(power)' (defined here). If nothing is happening try increasing the power level in the Gcode settings panel, the default (4%) is not enough to make my module illuminate, I needded to put 6% or more before I see a dot.

[Sebbb]

Hey,

for the laser command: M106 was for Marlin 1 (where they butchered the fan command set), in Marlin 2 it's (e.g.) "M3 S3".

Is there a way to override the detected model? I see e.g. repetier or marlinkimbra would get the correct commands.

I'll answer on the other stuff tomorrow and also will test some more things, indeed, I also assume it's a timing issue. BTW, big thanks for that, even where my issue isn't LaserWeb related :)

[easytarget]

where they butchered the fan command set

lol

I think @cprezzi knows more about how marlin1.x and 2.x are handled, lw.comm-server is his speciality. I'd been sort of expecting to see separate entries for them.

[Sebbb]

Okay, so this is embarrassing..
It was indeed a hardware issue, I lost steps on fast moves. Swapping X/Y and printing diagonal showed this, I wish I had tried that earlier.. With a higher current now everything works fine 👍 Thanks for your support and input!

One more thing, LaserWeb4 related: The control pane always shows "not connected", but printing works fine. Not sure if that should switch to "connected", but having "not connected" was confusing the first time.

 Machine connected
 echo:Unknown command: "version"
 echo:Unknown command: "{fb:n}"
 Firmware marlin RE_NA detected
 Cap:SERIAL_XON_XOFF:0
 Cap:BINARY_FILE_TRANSFER:1
 Cap:EEPROM:0
 Cap:VOLUMETRIC:1
 Cap:AUTOREPORT_TEMP:1
 Cap:PROGRESS:0
 Cap:PRINT_JOB:1
 Cap:AUTOLEVEL:0
 Cap:RUNOUT:0
 Cap:Z_PROBE:0
 Cap:LEVELING_DATA:1
 Cap:BUILD_PERCENT:1
 Cap:SOFTWARE_POWER:0
 Cap:TOGGLE_LIGHTS:0
 Cap:CASE_LIGHT_BRIGHTNESS:0
 Cap:EMERGENCY_PARSER:1
 Cap:PROMPT_SUPPORT:0
 Cap:SDCARD:1
 Cap:AUTOREPORT_SD_STATUS:0
 Cap:LONG_FILENAME:1
 Cap:THERMAL_PROTECTION:1
 Cap:MOTION_MODES:1
 Cap:ARCS:1
 Cap:BABYSTEPPING:1
 Cap:CHAMBER_TEMPERATURE:0
 area:{full:{min:{x:0.00,y:0.00,z:0.00},max:{x:315.00,y:300.00,z:400.00}},work:{min:{x:0.00,y:0.00,z:0.00},max:{x:315.00,y:300.00,z:400.00}}}
 jog(Y,-1,1800)
 jog(Y,-1,1800)
 jog(Y,-1,1800)
 jog(Y,-1,1800)```

And of course, being able to use the "check size" function with the laser switched on would be helpful :)

[easytarget]

I'm glad you found that; this sort of thing can be a devil to sort out.
The Status icon takes it's state from the status responses from your controller. So it shows 'Idle, Hold, Run, Alarm, etc as appropriate. I'm guessing that Laserweb is failing to interpret the responses from your firmware. This, and the laser test / check size commands are probably related to using Marlin2. Unfortunately I do not know any way to override this.

The Long term fix is to add Marlin2 to lw.comm.server and LaserWeb, From what I can see it is not a huge job; most of the work is in the comm server. The PR that added marlin (1) support originally gives some idea of the work involved:
LaserWeb/lw.comm-server#54