Firmware support for the Creality CV laser module engraver on the S1 (CVLM)

[chrisys]

Thanks for all the work on the firmware, I've been running it on my S1 for a couple of weeks. I just ordered the Creality Laser for the S1 to play with as I've never tried one before, and wondered if this firmware supports it or plans to support it?

I thought I saw someone else raising this same question a couple of weeks ago but have been unable to find that thread/issue again. 🧐

[mriscoc]

EDIT: Creality released the sources for the laser firmware, but it is based on the older version of Marlin, a major revision of the laser files was needed to make it compatible with the latest Marlin firmware.

Experimental support was released here:
https://github.com/mriscoc/Special_Configurations/releases/tag/CVLM

Old answer:
Hi, the firmware could support the Laser module if we can get the appropriate configuration files. We are waiting for Creality to publish the source code of the official firmware for the S1.

[fatofthelan]

I know you're probably much too busy to explore this at the moment, but I thought I'd at least ask what it would cost to move this along? Perhaps I can see if there is an appetite in the community to help fund this feature. If that is something you'd consider, please let me know and I'll run with it. Your firmware is outstanding and the thought of going back to the OEM version is appalling. Either way, thank you all that you do for the community.

[markrickert]

I've just spent some time setting up my laser module and a pen plotter. From what i can tell the only thing that's different about the stock firmware's laser mode is that you can set the Z freely (to focus the laser on the surface) and homing only homes X & Y.

The Z axis never changes after you set the focus. Laser mode also has the "Tuning" option turned off while it's engraving and I'm sure it ignores things like bed temp, hotend temp, fan speed, and extrusion.

Controlling the laser itself uses standard Marlin M3 and M4 commands to turn the laser on and off.

[TheWebMachine]

If that is all that is truly different and M3/M4 are implemented in this firmware, then we should be able to simply swap on the laser and load the usual laser gcode to "print." So long as the G28 command in the laser print gcode is changed to G28 X Y then Z shouldn't move after manual adjustment for focus. I'll pick through a small laser gcode file to make sure Creality isn't inserting anything else special and leaves things like temps and Z alone.

Is there anything I'm missing before I give this a try? haha

[markrickert]

@TheWebMachine The Z axis can still move if the gcode tells it to. This is useful for pen plotters and vinyl cutting toolheads to lift the off the bed and make a move to a new location.

My workflow has been the following:

1. Put stock firmware back onto the machine
2. Change toolhead
3. Move toolhead to the center of the bed
4. Turn on printer and switch to Laser mode
5. Adjust the Z-height in the interface to where i want it
6. Load up gcode and "engrave"
7. Put this firmware back on the machine
8. Put printing toolhead back on.

Settings to initialize the print should include G28 X Y (and not a standard G28) so that it excludes the Z axis from homing at the beginning of the print sequence.

For the laser, the gcode should turn the laser on and off using M3/M5.
For the pen plotter, I have my slicing settings to "Z-hop on retraction" and then set the Z-hop distance to like 5mm so the toolhead is lifted off the bed for moves.

I found this really great interchangeable toolhead system for the S1, purchased it (3€) and loved it so much that i designed a Laser Module holder and a vinyl cutting toolhead adapter for the system.

[TheWebMachine]

Indeed, the Z should still be able to move for those purposes. That's why I was saying we would need to ensure any G28 in laser gcode specified X Y only. We wouldn't want Z trying to home without the probe attached (for those with probes).

The question is, can we use this firmware as-is with the laser or is Creality, indeed, not controlling laser power via normal PWM - which would preclude finite control with M3/M4? I have the 5W laser, so I absolutely need power control or I'm cutting through everything except maybe a 2x4. haha

I hate the idea of flashing back and forth all the time. The flash, while robust, does have a finite number of writes before failure.

[markrickert]

It should be pretty easy to manually edit standard gcode if you slice with the z-hop trick. Replace all the hops with an M5 to turn off the laser, then an M3 (with your specified power level) after the move is completed to the new location.

[mriscoc]

If it is possible to manage the laser by only editing the g-code maybe someone could write a Python script to do the conversion and add the required additional g-codes.

[TheWebMachine]

Haha. I was writing the below just now.

[TheWebMachine]

So, I did some looking into my existing laser gcode sliced by CrealitySlicer for their factory firmware. It would appear they are controlling thusly:

G92 X0 Y0 Z0 ; zero our steps-per-unit
G90 ; Absolute mode, obviously...they assume you've homed and such while setting up the print range 
G0 F#### ; set some feedrates
G1 F#### ; on G0 and G1
M3 I ; turn on the laser in Inline mode
G0X123.456578S500 ; note the S499 which is inline power output modification for the laser
...more moves...
M5 I ; turn off the laser
G0 X0 Y0 ; move laser out of the way when done

So, there is only one caveat I see getting in our way and it isn't a small one:
G0 S/G1 S requires firmware be built including the LASER_FEATURE option, which is likely going to wrap us back around to the biggest issue for us...flash free space. This is especially true of F4 boards with their giant bootloaders. I doubt we'd be able to get LASER_FEATURE alongside UBL on F4 as it currently stands, for example.

The only way I see around this, if LASER_FEATURE can't be added without sacrifice, is to use a post-slicing script to alter every line from:
G0X123.45678S500
to:

M3 0128 
G0X123.45678

The M3 value will need computed from Creality's 0-999 (I think it's 999 based on my gcode files) range to an equivalent 8-bit unsigned int since the firmware expects 0-255 for M3 0 for controlling the PWM output

We'd also cut the starting M3 I since we wouldn't be using Inline mode. Laser instructions would begin with the first M3 0 and subsequent first move.

If LASER_FEATURE can be added without having to sacrifice any of the existing features included, then we should able to use the gcode entirely as-is without needing to really change or add anything to the screen or elsewhere in the firmware. You'd just manually home/focus your Z on the object before you began the print and any Z moves in files for things other than laser (plotter, etc), should also work just fine, as far as I can tell. The only catch is we wouldn't have the UI adjustment to manually set the "print range" like you can in Stock, essentially the 0x,0y or Origin point for the print, but you could also just disable steppers and manually move the laser/pen/etc to your desired 0x,0y after you adjust your Z and home X/Y. The printer will still believe it to be at 0x,0y despite your manual offset when it starts printing and the gcode should be sane at that point.

@mriscoc can you comment on the flash expense of adding LASER_FEATURE in whatever minimal manner you can? As far as I can tell, we only need the extra support in G0/G1 for Inline power control and nothing else. I know F4 UBL versions are the tightest on available space and you already had to exclude a couple things. I'm willing to test for you with my Plus and laser if you want to cook up a S1-F4 build. (I'm busy with a few other dev projects at the moment and haven't gotten around to setting up my own build env for this yet....maybe next week.)

When I get a chance, I'll start working up a python post-slicing script to modify for current firmware without Inline power control as shown above, just in case adding LASER_FEATURE proves to be detrimental or not reasonable...since I'm pretty sure something else is going to have to be sacrificed on F4 boards to fit it in, at least with the UBL version.

[TheWebMachine]

Is PC0 controllable via M106/M107 in the current F4 firmware? As noted below, I could not find a P in M106 that had any effect on that laser port.

[mriscoc]

Is PC0 controllable via M106/M107

No because FAN1_PIN was defined as AUTO, perhaps disabling E0_AUTO_FAN_PIN, but then it needs to be manually enabled to prevent heat creep in normal operation.

[TheWebMachine]

If we enable EXTRA_FAN_SPEED, can we also keep E0_AUTO_FAN_PIN enabled? EXTRA_FAN_SPEED should, in theory, give us M106 control, right?

[mriscoc]

If we enable EXTRA_FAN_SPEED, can we also keep E0_AUTO_FAN_PIN enabled? EXTRA_FAN_SPEED should, in theory, give us M106 control, right?

No, the main problem is FAN_COUNT, it limits the number of controllable fans in M106.

#define _CNT_P FAN_COUNT
...
void GcodeSuite::M106() {
  const uint8_t pfan = parser.byteval('P', _ALT_P);
  if (pfan >= _CNT_P) return;

[TheWebMachine]

And if we increase FAN_COUNT? Sorry, I haven't had time to do a deep dive into this FW or the original Marlin source yet.

I am willing to flash a custom build to test whatever we need to test if you wanna give something a try. I use Octoprint, so I can capture serial logs and send whatever commands we wanna test. I already have a python script to convert Creality's gcode into M3, but altering it for M106 would be simple because I'm already converting from Creality's values to a normal 8-bit range that a PWM would expect. I have the 5W laser for testing.

Hopefully in the next couple weeks I'll have time to setup a build env for this and can start compiling on my own to help things along.

[TheWebMachine]

Ok. I've run into a problem while writing the python script. I got a simple workable beta script going and went to go connect the laser and do some testing. 😞 It would appear M3/M4/M5 are entirely unavailable in this FW ("Unknown Command") without LASER_FEATURE added. This puts us back to having nothing workable. However, I have another idea that might get us there...

We could, instead, enable EXTRA_FAN_SPEED and use M106/M107 to do the PWM control of the laser. It is nearly a drop in replacement command for M3/M4/M5 if we set aside the asynchronous aspect (which I will test the impact of).

@mriscoc This brings me to a few questions:

• Is EXTRA_FAN_SPEED added already and mapped to the unused PWM ports?
  I don't get an error when I run M106/M107, but I also can't seem to find a P<index> that controls the exposed unused/laser PWM port on my Plus. I found a great diagram of the board and port group I'm talking about, for reference; I have circled the Laser/PWM port in blue.
  

*If not already added and configured, can we add/configure this without sacrifice on the F4-UBL and other "zero free space" versions?

[TheWebMachine]

@mriscoc Could you shed some light on this for me, please?

[mriscoc]

I just saw your contribution on Github, thank you!
Do you know if Github allows direct communication? It could be interesting for the managers to have direct communication with sponsors.

[TheWebMachine]

Quite welcome; I find a project like this to be highly valuable to all of us and don't mind suppporting the efforts. Pretty sure github precludes any sort of direct message support, though.

[mriscoc]

I was able to code a preliminary and very basic support for S1 Laser Module but only for the Ender3S1 F1, I could post a bin file to test.

[mriscoc]

air enough. I noticed that F4-UBL uses 196.6kb

Yes, but my final idea was to be able to have Laser support along with other features, but maybe it is too much and I will leave the LS1M alone, so no LS1M with USB and other features will be supported.

[TheWebMachine]

No, I agree with your original thought at this time...Run Range can be left out for now so long as the caveat is known that laser print must be sliced at proper 0,0 origin and exact relative origin on material can be specified at the printer with the current menus. I think once we nail down laser with what we have right now (fixing PWM as mentioned below, etc), we can decide what we want to add and if there is still room left to add Run Range after that.

Requiring slicing at 0,0 isn't really a big ask and what most users likely default to anyway. With the Set Home options in menu now, this should be fairly straight forward.

[TheWebMachine]

LS1M with USB and other features will be supported.

What do you mean? Which USB functions are missing from this firmware at the moment? You mean USB firmware flashing and SD access?

Ideally, this still needs to function well in FDM mode, too...so I wouldn't want to hobble FDM too much for Laser or we might be back to where we started needing to flash different firmware to switch modes for the best options. I'd absolutely sacrafice Run Range if the alternative is a sub-par FDM build. I mean, ABL is fine, but I don't want to lose too much from the main F4-ABL version on the whole.

[mriscoc]

Oh, I didn't read your comments, I just implemented a light version of 'Run range' but removed XY axis movement and set home menu items.

[TheWebMachine]

I'll give it a try and see if this Run Range provides enough control to preclude needing the move/set menu items you removed.

[mriscoc]

This version should work better, the firmware expects M3 S in the range of 0 to 999, I can't find why the Laser output was higher than anticipated.

(File removed)

[TheWebMachine]

The gcode I tried and got excessive output was using G0/G1 S commands to control the laser output (Creality slicer's default output) and I suspect the firmware was expecting a 0-255 range for that one, so anything over 255 was being treated as 255.

I will use my python script to convert to M3 and see how another test goes with this new build...pending the discussion above about Run Range.

By the way, my script can be found in the repo below and is named: plpp.py
You run it with a filename specified and it rewrites that file by replacing the inline G0 power with M3 power preceding the original (power removed) G0/G1 commands. It overwrites the specified file at this time but I'll add param for output filename at some point.
To be considered just as experimental as the firmware, itself. haha
https://github.com/TheWebMachine/Ender3V2S1ProBits

Note: I will need to update it so the M3 uses 0-999 because I currently have it converting to 8-bit (0-255) because that is what Marlin defaults to for M3. Are you sure M3 in your firmware is expecting 0-999?

[TheWebMachine]

Ah, I just pulled up my noted on my script, which sheds a little light on how Creality builds the laser gcode files. My script is doing the following:

• Removes M3 I to preclude Inline Power mode
• Changes all Inline Power commands (G0X123.456Y123.456S999) to individual M3 and G0/G1 commands (M3 O255 & G0X123.456Y123.456) while also converting from Creality's 0-999 to Marlin's preferred unsigned 8-bit int (integer division by 3.91)

So...I should be updating my python script to instead convert from G0 S[0-999] to M3 S[0-999]?
Is M3 I and the G0 S perhaps the problem with the last firmware test?

EDIT: just updated my script to use M3 S[0-999]. I'll give it a go, as I just loaded up your latest test firmware.

Side note to everyone: Do NOT try to use Octoprint to send laser files. It seems that the rate at which laser employs moves is much faster paced and I noticed a LOT of stutter. Therefore, prolonged burning and other undesired/unsafe effects when trying to use Octoprint to send laser gcode files.

[TheWebMachine]

Ok...that was...um...a little better? lol It didn't burn through the wood entirely this time but most of the detail was lost because the laser wasn't powering down completely when it should have...however, I blame this on my script. I am about to try again with the stock gcode and see if I get a better result.

That said, kudos on the addition of the items in the Laser menu to set home. That fixes one of the big hurdles (the negative Z issue). Run Range would be nice so we aren't beholden to absolute coordinates from Creality Slicer (which is a pain to begin with), but if we can't fit it in I suppose it can be worked around most of the time - always placing your laser print at 0,0 origin in Creality Slicer, at the risk a bug will not let you place it there in some seemingly random cases, which is why Run Range is useful.

Let me do some more testing to see if I can get a good laser engraving from this current firmware with stock gcode and we'll go from there. I'm going to slice something fresh with a 0,0 absolute origin and see how it goes.

[mriscoc]

Could you please post a Creality demo G-code file for the Laser module, I want a file without changes, just as Creality expects it to work with its laser firmware.

[TheWebMachine]

I did a lot more testing last night. Here's the TL;DR and most important points I found. NOTE: This only applies to the latest experimental fw-20230228, as 20230226 build did not like Creality's stock gcode at all.

• Using M3 S preceding G0/G1 (as my script converts to) does not work well...the laser doesn't properly power down (M3 S0 appears to be ignored). This could be a bug in my python script, but I haven't dug into it yet.

• Using Creality's stock gcode, unmodified, works fine with its M3 I & G0/G1 S inline power. HOWEVER, there is something off with the PWM...the output is WAY higher than it should be. I am seeing 100% laser output when gcode is only asking for 50% (S495). So I think the modulation of the PWM signal is tuned too high.

Here is a stock sliced gcode, without modification, positioned at precisely 0,0 origin, and set to 50% laser output. At this power output, it should be burning only about 1mm deep in basswood at the 1500mm/min default speed. When I print it, it positions and such just fine, but the laser output is way too high for what is being requested in gcode...it's burning through 2.4mm of basswood! I had to lower the power in slicer to 10% to get what I should be getting with 50% requested power output.

In this zip is the gcode file and, for reference, the image that was imported into the slicer so you know what it should look like...
TEST-LASER-8th50-mountain2.zip

[mriscoc]

I found the problem with the laser power and G0 S commands, also I implemented a Run Range:

(file removed)

[TheWebMachine]

Nah, I don't like this limited Run Range implementation. It requires absolute positioning from the slicer being translated to the bed without exception, as it appears to be missing Creality's Run Range menu option to move the origin point. So, it illustrates where it will print, but this means if you slice too close to edges of bed, you have no way to secure the material...or you have to determine mounting magnet positioning at slicing time, which is far from ideal. On the other hand, the previous version with manual move menu items and set home does require you to slice with a 0,0 origin for accurate knowledge of where you are originating on the bed but lets you place the engraving anywhere on the bed by manually adjusting the origin to match the material position. I also noticed some deviation on the Y axis laser homing that I don't see on the FDM homing, where it was seeing Y0 as off the edge of the print bed instead of respecting and calculating my Y-Min value setting.

That said, your fixes for PWM are good. I got proper PWM output both with oscilloscope and when I hooked up the laser for a real test.

Can you put the PWM fixes in the 20230228 (x/y move and set home menus) fw and let me test with that for a bit? I think we may have to include too much of the Run Range functionality to make it useful and I still agree with you that we could use that space for other features. Basically, if given the option of Run Range as it is now -or- the X/Y/Z/Set Home method, I choose the X/Y/Z/Set Home for greater control over at-print-time positioning.

[mriscoc]

This version has all:
(file removed)

[TheWebMachine]

You know what they say about having it all, right? 😳🤣 Perfect timing, btw. Power was out due to a storm here and it just came back on a few minutes ago. I guess I'll get this tested shortly and let you know how it goes.

Thanks for all the work on this!

[TheWebMachine]

Well, something is wrong with Run Range. It draws a box much larger and seemingly arbitrary compared to the image. I sliced an image at 0,0 origin in Creality's Slicer, positioned material, manually set X/Y/Z home to match material placement, used Run Range and saw a huge box, Engrave proceeds to produce the correctly sized output from slicer.

I have taken a video. Pardon the exhaust fan noise! It shows Run Range with a really big box, then Engrave of the actual much smaller image. So, Run Range is the only thing not working and the rest seems fine. If you can't find an easy fix, I'd say just drop Run Range to make room for other things. Of course, I'll keep testing if you endeavor to fix Run Range.
https://photos.app.goo.gl/NCWUPSdvGUh6smHQ9

That said, what else can we add back with the space remaining, whether we keep run Run Range or not?

[TheWebMachine]

Ok, some further testing reveals that Run Range is correct some of the time. I can't find a reason for it in gcode - both good and bad Run Range results have accurate headers in the gcode for image size as far as I can tell, which I presumed was how Run Range obtained its values so readily. Some files show an accurate Run Range and others show the arbitrary large Run Range like in my video. I can't make sense of it.

For example, in the video linked above, the header of the gcode looks like this

;Header Start
;estimated_time(s): 4704.477����
;MAXX: 88.33
;MAXY: 149.00
;MINX: 0.00
;MINY: 1.00
;Header End

And that is not at all what Run Range presented, as you can see.

In another test, the header looked like this:

;Header Start
;estimated_time(s): 2647.760����
;MAXX: 151.67
;MAXY: 150.00
;MINX: 0.00
;MINY: 0.67
;Header End

And the Run Range showed perfectly accurate dimensions when selected!

[mriscoc]

I'm preparing a change where the limits of run range will be displayed in the screen, that will allow us to check if the firmware is reading the values correctly.

[mriscoc]

Experimental support of CV LaserModule:
https://github.com/mriscoc/Special_Configurations/releases/tag/CVLM

I got rid of the original laser "get header" code and used code from my gcode preview library.

[TheWebMachine]

Which version are they on? I haven't yet moved to the version you posted to Special Configurations recently. I can confirm that on the Experimental-Ender3S1-F4-CVLM-20230315 firmware the Laser does NOT turn on at boot until you toggle the option in menu. It also only turns on the minimal power focus dot once you enable and I've yet to see an exception to this.

In fact, I was initially annoyed that I had to toggle it back on after every reboot until I realized the safety reasons for this. 🤓

If they are on the latest one you posted to Special Configs, I can update to that and test in case you perhaps made a mistake in that one. However, I haven't had cause to update yet because 20230315 has been working flawlessly and the newer release you posted has the LIMIT_LASER_MANUALMOVE option enabled, which I really think should be disabled by default (or maybe a menu option??). 😉

[mriscoc]

Please try the latest version. Perhaps with the new menus you might find the LIMIT_LASER_MANUALMOVE irrelevant.

[TheWebMachine]

Duly noted. I will give that a try today and post my results in a bit. 😎

[TheWebMachine]

Done. 20230407 tested. You are right; the LIMIT_LASER_MANUALMOVE does appear irrelevant with the new menu arrangement. I also could not replicate the bug reported. Every boot - whether reboot via menu, physical power switch, or unplugging the machine outright - the printer always boots with the laser entirely off. I have to go into Advanced > Laser menu to toggle it on after every single boot and it only powers on to the low-power focus dot.

Beyond a bad mainboard, cable, or laser module...hardware...I can't think of anything else that would cause the reported bug...I don't think it is in firmware unless there is a detail we're missing in the user's report. Which model of E3 are they using?

[mriscoc]

Thank you for your review. I don't know the exact printer that he has (S1, S1Pro, F1 or F4).

[Mazzetta87]

hello there is some experimental release for use laser with your firmware mriscoc? i have 10w laser falcon

i have ender 3 v2 neo with 4.2.2 mb and im a mriscoc firmware addicted :D please do some miracle and let me use my falcon laser engraver without swap firmware stock everytime i have to engrave...

thanks in advance

[mriscoc]

I don't know the requirements of that laser module, what firmware do you need to install to use it?
I think this module has its own control box?

[Mazzetta87]

that laser module is compatible with every ender look i have this module but i dont know if the function on your firmware is implemented for engrave like stock firmware https://store.creality.com/eu/products/creality-laser-module

if u confirm that work im just happy :D i didn't tried yet the module cause i seen something about problem with this firmware and i wont go back stock for use it soo i din't installed yet

also i must to do a rigid support for engrave(not like a stock support that creality give in bundle...) that support is a joke,no sense ...soo before i made one i wanna be sure this laser work with your release :D

[mriscoc]

The Laser control box takes control of the motors, so the printer board is not used at all.

[Mazzetta87]

really? soo is like a motherboard that move axix disabling the original printer mb? fantastic....

[Mazzetta87]

Tnx a lot for the answers professor :D

[mriscoc]

@TheWebMachine please test this new version, it is based on the current experimental and have a new enhanced laser code that allows automatic detection of laser/fdm files, also it should support engraving using Octoprint with lightly changes. For engraving from Octoprint the home position must be set before of send the laser file to the printer, otherwise the G92 X0Y0Z0 in the laser g-code file will use the current position as home with a possible crash if there is not enough space, but I think that is obvious.

Experimental-Ender3S1-F4-CVLM-20230505.zip

[TheWebMachine]

I can confirm that the auto detection of laser vs FDM files works rather well! I haven't been able to fool it yet, regardless of which app I generate the gcode from. I'm assuming it is looking for M3 as the trigger for popping up the laser menu. Hits the spot every time thus far.

Sorry for not getting to test Octoprint laser yet. I'll be on the road through the end of the month, so I won't have access to the printer for the duration.