Ok here is one that uses Pin12 for enabling on/off and Pin11 for PWM. The PWM commands are Z0-Z255. Look at Step 11 for the instructions of use and source code github link.
@LarryM I also have a couple of K40 lasers that I would like to try this out on but I am in the same boat as Timo, the enable logic is reversed for the K40 High (+5 VDC) on and Low for off (GND).
Would it be possible to compile a version with the enable logic reversed for us?
Here is the board I just designed and put into my laser cutter. As @HalfNormal mentioned, we would be fine with a hex file for this config… Please check out the readme.md https://github.com/McNugget6750/K40-grbl-board
This firmware upgrade was not intended to be a general purpose laser version. It is targeted to a specific audience with specific equipment. Sonny is working on the “official” laser support that is targeted for version 1.0c and he says he is close to having it ready.
However, it may work in other systems, depending on the system requirements of the laser you are using.
My version does not have separate enable/disable and PWM output. The only control output is PWM. To use it in an on/off mode (as in turning a relay on/off for spindle mode, or to turn the laser on/off in laser vector mode) you could use S(max: spindle $30, laser 255) to turn the device on and S0 to turn the device off (assuming you have M03 active).
When M03 is active S0 puts a logic low (~0 volts) on pin 11 (PWM). (spindle and laser)
When M03 is active S255 puts a logic high (~5 volts) on pin 11 (PWM). (laser)
When M03 is active S(max $30) puts a logic high (~5 volts) on pin 11 (PWM). (spindle)
When M03 is active S1 through S254 puts a PWM signal on pin 11 for laser raster mode.
M05 puts a logic low (~0 volts) on pin 11.
How is this reversed?
It is reversed by being active low.
On my laser and using the current GRBL master 0.9j I had to configure the following changes to config.h to make it work on my board. It then uses D11 for hardware PWM and active low D13 for spindle on and spindle off. M3 pulls D13 low (not matter the S value) M5 pulls D13 high (no matter the S value). PWM is generated only when M3 was sent last. M5 stopps PWM as well.
GRBL Config Modifications
Modifications for config.h are required!
Modify homing cycle:
#define HOMING_CYCLE_0 (1 << X_AXIS)
#define HOMING_CYCLE_1 (1 << Y_AXIS)
Invert spindle enable pin by enabling:
#define INVERT_SPINDLE_ENABLE_PIN // Default disabled. Uncomment to enable.
Enable variable spindle speed if not done by default. This gives you hardware PWM on Pin D11.
#define VARIABLE_SPINDLE // Default enabled. Comment to disable.
Remap spindle enable pin to pin D13 by enabling (WARNING! WILL BE PULLED LOW BY BOOT LOADER DURING POWER UP! DEACTIVATE YOUR LASER DURING STARTUP OF BOARD IN ORDER TO PREVENT FULL POWER BURNS AT STARTUP.):
#define USE_SPINDLE_DIR_AS_ENABLE_PIN // Default disabled. Uncomment to enable.
This answers the question. To enable the K40 it needs a High (5 VDC) separate from the PWM input. I guess to test the firmware, toggling M3/5 could work with a manual enable instead of software.
Does your CAM software use M03 at the beginning and M05 at the end, or does it change M03/M05 through out the run?
If just the beginning and end you could do a manual enable at the beginning and manual disable at the end. Then use S commands for the variable intensity. S0 should turn it off.
In my case it’s the other way around. I set S300 (range: 0 - 1000) at the beginning according to the power I need for the complete cut and just use M3 and M5 for every segment.
During engraving, this can also be the other way around like you suggest.
So my start code would look like:
and my end code would be
For every pixel for engraving the laser power would change using the S command throughout the whole run.
Ideally this is not required and instead a specific engraving command provides an array of laser power values for as much of a pixel line as possible with the limited buffer on the ArduinoNano.
I took a deep-dive into the LaserLink grbl sources that you posted and integrated all the modifications into the current grbl 0.9j master that I’m using and what can I say… IT WORKS! I’m super happy. A faster sender or a larger TX queue might help accelerating the engraving but it generally works!
I’ll try to upload my modified grbl so that other people can take advantage of the new version of grbl and the laser engraving capabilities. The comments like “// NNW” are still there so all the changes are easy to spot. I just added another define that essentially says that you want real time spindle commands.
Can’t you use the coolant on/off with pin A3?
Sure there are workarounds but they entail editing the GRBL file to work. I am not lazy but it would be nice to have a plug and play solution. With lasers getting cheaper and more prevalent, I am sure there will be more development to incorporate the options into the firmware. I am seeing a lot more cross over from the CO2 laser community into the CNC community which also brings a lot of talented people like Timo sharing their hard work and great ideas for everyone to use.
Jay has done a great job with his laser GRBL but did not release the source code so it could be refined. The next major laser GRBL release is on its way and should make more people comfortable using it.
Great things are on the horizon! That is why I love this community!
Not really. The coolant enable and mist enable are already active. M07 (pin A4) turns on mist, M08 (pin A3) turns on coolant and M09 turns them both off.
M07 => pin A4 high (~5 volts)
M08 => pin A3 high (~5 volts)
M09 => pin A3 and A4 low (~0 volts)
The M8 (coolant on) can be added to the Precode & M9 (coolant off) to the Postcode in PicEngrave Pro 5 so they will be included in the file when the gcode is generated. I just tested it with Larry’s Multimode grbl 1.0c and M8 sends pin A3 high when the file starts running, the M03 enables PWM on Pin 11 and the S0-S255 commands controls the duty cycle of the PWM throughout the file. At the end of the file the M05 turns off the PWM and the M9 sends Pin A3 low.
No work around needed, just Plug in & Play!
Well I’ll be darned! I had not done my due diligence and actually checked the code and program for real before making a fool of myself!
Thanks for keeping me in check!
Just saw this post, This is Nick from laser Ink the original author of the 9g derivative which JTech based there mods on.
I have two CO2 lasers running from this Codebase. I will upload the modified code to the repository Friday.
Anyhow, What I did to handle the additional enable is I re-purposed the spindle direction pin(13). With this mod there is no need to send additional GCodes M3 will automatically raise pin(13) high and M5 will sett it to zero.
I will follow this mod and am willing to help in any way.
I have also done some major work on the ability to do high detailed image rastering by implementing a streaming mode in grbl. Currently I have not shared the format of this original GCode block so the only way to generate this will be through my software. This allows me to send an entire raster line(You may be thinking there is a limit on the line length but there is not:-) ) as a single GCode block and provides a 10x performance enhancement to the existing method of sending a GCode block for each pixel. There is a down side on the UNO based controllers I had to disable Arcs as I needed the code space. However, with the Mega I would be able to enable both.
Here is a video from my face book page
I am not ready to release this firmware yet but it will be coming soon. It may be nice to integrate with the XCarve base code.
This is excellent news! However, I really don’t like the sacrifice of not having arcs!
However, I really like the new gCode! I think I saw that somewhere but I can’t remember where. I suggested a new gCode like this in the K40 community yesterday and I’m very glad you already did major work on this!
I spend yesterday night and a good portion of today to port your changes to the grbl code base into the current 0.9j code base which I am using. I have the laser running raster, arcs and homing quite well now and I think I found three bugs in your code (at least I think they are bugs). I’d love to share my 0.9j modifications so that you guys can test it as well. I might open another github repository for this - or a branch to the original 0.9j release.
Let me know what you think!
It looks like the focusing of your laser is not as good as it should be.
This looks great
I’ve only ever built and installed from source code, does anybody have a recommended way to load a hex onto the XCARVE electronics from a Mac please?
There is a method mentioned here:
Make sure you have your laser safety glasses on.
We use a 3 inch focal height from the bottom of the heat sink to the top of a piece of black anodized aluminum when focusing. You may have to bump up the laser’s power slightly and rotate the lens in both directions until you see the smallest focal point possible.
After confirming the beam’s focused properly, you need to secure the lens with some hot melt glue from the lens thread to the module/heat sink. This ensures it does not move when engraving.
You need to maintain the 3 inch focal height distance when engraving on your material, or it will go out of focus.