[FR] Standard Marlin for Cutting CNC machine(plasma , laser)

[mkeyno]

hi all developers , as I remember Marlin in primarily invented for 3d printer , however couple of cool guys hear attempted to modified Marlin for CNC machine like laser machine , but it seems all of them not follow the same and standard way as the original Marlin goes, I hope in this repository finally new branch for cutting machine will be created and gather all enthusiast on same approach for standard Marlin version for cutting machine such as Plasma oxyfule and laser

[666dsa666]

I would love this too, TurnkeyTyranny fork looks like the best approach IMO, but it was not updated for a few months.

[mkeyno]

you are so welcome and actually guys like @HakanBastedt already merge the TurnkeyTyranny code in new Marlin firmware in Due , also he mentioned it test goes well , but there is couple of feature need to be add like auto high control during the cutting or engraving , I suggest at first look at his code here
https://github.com/HakanBastedt/Marlin4Due/tree/Laser

[nextime]

I'm just doing the same thing on MarlinKimbra with this pull request: MKFirmware/MarlinKimbra#113

[Roxy-3D]

I hope in this repository finally new branch for cutting machine will be created and gather all enthusiast on same approach for standard Marlin version for cutting machine such as Plasma oxyfule and laser.

It would be interesting to hear your thoughts about what new commands and features need to be added. There is no reason the 3D-Printer code can't co-exist with CNC milling and Laser cutting. In fact, it is very possible in the near future machines will have all 3.

My initial thinking is we can give you a whole block of GCodes (for example: 700-800) for your stuff if you can think it through and come up with some well thought out plans.

[nextime]

@Roxy-3DPrintBoard on my pull request to MarlinKimbra i've added the same GCodes as is Turnkey Tyranny modified marlin, retaining full compatibility with existing frontends for it (laserweb and the inkscape plugin first of all ).

The complete gcode list is here: https://github.com/nextime/MarlinKimbra/blob/dev/Documentation/GCodes.md

Most notables are:

• G0 ang G1 aren't the same anymore. G0 move the head without firing laser, G1 with firing laser. Firing laser is also with G2 and G3 arc moves.
• G7 to execute a raster line ( base64 encoded line )
• M3 start laser at specific intensity/power
• M4 Turn on laser
• M5 Turn off laser
• M649 to set laser options
• M650 and 651 for mUVe specific laser kit "peel"

[nextime]

As i'm adding also support for water cooler on the laser patch for marlinkimbra, i'm thinking about the Mcode to set the PID for it.

Actually we have 2 Mcodes for setting PIDs: M301 for extruders, and M304 for bed.

For the laser cooler i have many options:

• Use M301, and just use it as if were the first extruder (E0)
• Use M301, but use the last available extruder (E3 on MarlinKimbra) as it's the least-probable extruder used in configurations of machines that can both 3dprint and laser cut/engrave
• Use M301, add an additional extruder setting (also in EEPROM store), (E4 on MarlinKimbra), so, it doesn't override any possible extruder in case of machines that can both 3dprint and laser cut/engrave
• Use M304, on laser machines we don't have heatbed, so, just use it.
• Use M304, modify it as it can accept multiple PID settings, like extruders does in M301 with "E" selector. Don't know which selector to add too, using "E" seems stupid, has to be choosed something that make sense both for "bed" and "water cooler" or "laser".
• Use another Mcode not yet listed. I can't find any Mcode "standardized" for this use, and i don't like to add Mcodes without large consent.

I ask here cause i hope that if in future Marlin will be patched for lasers, we can retain full compatibility in G/Mcodes, so, make sense to ask also here for those things.

Has anyone suggestions about that?

[jbrazio]

This is very interesting.
Quick question, I do not know (anything) about laser cutters, is the standard G1 mean "move while running the laser" ? For standard CNC machines the spindle on/off and velocity (rpm) is controlled in another G-Code thus G1 is a standard movement.

[nextime]

is a "sort of de-facto" standard nowadays thanks to both the fact that repetier-firmware, other (older) marlin based modified firmwares like turnkey tyranny, and also other firmwares implement it in that way, also, looking at http://reprap.org/wiki/G-code you can read:
In Repetier-Firmware in laser mode you need S0..255 to set laser intensity. Normally you use S255 to turn it on full power for moves. Laser will only fire during G1/2/3 moves and in laser mode (M452).

Also, all host software specifically done for lasers like https://github.com/openhardwarecoza/LaserWeb uses this "standard"

[thinkyhead]

Side-note: I'm still a little torn on the differing usage of G0. I believe it's supposed to mean "raw uninterpolated move" but I have seen some GCode that uses G0 for any move that doesn't include the E axis. Has anyone else noticed this, or am I just imagining things?

[MetalMusings]

Have seen this too. For example repetier-host use G1 for movements when pressing the arrows. In 3D printing G0 and G1 are used interchangeably.
In practice one needs to use a G-code generator for laser cutting and the (very) few I have tested behaves well with G1 when cutting and G0 when traveling.

[nextime]

@thinkyhead the issue can be triggered when the firmware is compiled for a machine that have both 3d print and laser, as you will have to enable LASER define, and then when 3d print using a slicer that uses g0 and g1 without differentiation.

But the issue is on the 3d print side, as for lasers the g0/g1 difference is a common thing. Maybe implementing also the M452 like in the repetier-firmware can solve this issue, when in laser mode g0 and g1 are different, where in 3d print mode g1 and g0 are equal, shold be easy to implement

[Blue-Marlin]

@nextime
The current MarlinFirmware/Marlin has no LASER define. What are you referring to?

[nextime]

@Blue-Marlin i'm referring to the pull request add laser support to MarlinKimbra i was describing few messages ago where the discussion about g0/g1 was started ( pull request that eventually can be ported to marlin too)

(this one: MKFirmware/MarlinKimbra#113 )

[mkeyno]

@Blue-Marlin please check this repository https://github.com/HakanBastedt/Marlin4Due/tree/Laser , right not this firmware is implemented on CNC laser and shows reliable speed , we interested to implemented the dynamic THC with ready -to-use module with some modification and replace with temp control feature or I2c

[MetalMusings]

Ok, I have ported it for my own purposes, and I know of several people that also have taken the laser code from https://github.com/TurnkeyTyranny/buildlog-lasercutter-marlin/tree/master/Marlin and used it in current Marlin. All credits goes to TT.
The code is well working, has three laser modes, synchronous, pulsed and raster and the two last are synchronized with movements so no overexposure when motors stutter or during acceleration. The G7 command for raster engraving offloads the planner and stepper by putting like 50 rasterpoints into one stepper block. Reduces also serial line overhead. My own experience is that G7 can engrave at 3x the speed of G1 steps for every dot. The code is also very well encapsulated with #ifdef LASER. Modifications are in planner.cpp and stepper,cpp, in a few places not spread all over the code. I have taken the code into Marlin4Due and exactly the same code can be used. Only the hardware PWM generation part is unique between Mega and Due. TT's PWM code work well for Mega, take my code for PWM if interested in Due, last part in HAL.cpp.
The only drawback is the lack of g-code generators that use the G7 raster engraving command, only TT's own tool for Inkscape export does that afaik. It is not difficult at all, so things might change if Marlin gets the capability.

[MetalMusings]

One question is how to hook up the laser driver and to control the intensity. There are laser drivers that use TTL as they call it, a 5V PWM up to like 20 kHz frequency is needed. There are laser drivers that use the voltage of the PWM signal to set max intensity, so adjustable voltage PWM is needed. Then there are laser drivers that use a "firing pin". The laser driver input can have common ground, thus disqualifying mosfet-controlled outputs, and there are laser-drivers with optically insulated inputs thus allowing the use of mosfet-controlled outputs. The laser pwm pin must be a pwm capable pin thus 2-13 and 44-46 according to docs. Also the timer needed for the chosen pin must be free and not used by stepper, servo or temperature for example.

[Downunder35m]

I also worked on the Turnkey firmware and modified for the use on chinese K40 clones.
Some of the changes I made include support for full 8bit raster engravings both in the firmware and the Inkscape plugin.
To accomplish this the input range for the laser intensity was increased and the base64 calculations slightly modified.
I have the project on Instructables if anyone wants to read the full story.
For some time I was looking for beta testers or people willing work on a newer Marlin base, no clue how I missed this thread for so long.
If anyone is interested then I will have a look at the Kimbra release and add my modifications for the K40 laser models.
Documentation on the wiring is included in my Instructable based on the standard Turnkey mods.
Both single pin or double pin control for the laser is possible.
Would be great to find some more people with Mega/Ramps and a K40 clone to get going.
With my current tweaks I do 8 bit engravings @ up to 4000mm/s depending on the set resolution in the Inkscape plugin (I experiment with 207DPI compared to 508DPI at the moment).

Edit: Just noticed the Nextime is quite busy in his branch...
Since all Turnkey stuff is included there I would like to add my changes to improve the laser control range and enable full 8bit engraving support.
So far I have not done anything here on Github, so it would be nice if someone could let me know what the best option is for adding my cahnges is without making a mess of everything.

[Downunder35m]

I have included the changes required for 8bit engraving in the release I downloaded 2 days ago.
After some initial tests I have to say I am quite impressed with the firmware.
Not just in terms of features but also how smooth it performs during 8bit engravings.
With a 508DPI export resolution in Inkscape I can engrave at 4000mm/min with no stuttering or pinhole burns on sides.
Still trying to implement the minimum laser power for the raster engravings into the M649 command in a way that it is accepted for the raster calculations.
Will upload a video later on showing the machine in action with the new firmware.

[MetalMusings]

Sounds great! How many steps/mm do your motors have? I think the speed limit is due to steps/sec the Mega can do. 8bit == G7?
I would hate to see the G7 command deviate from TT's original. G8 in that case?
I made a modification, a variation on the greyscale and power levels, the code is here https://github.com/HakanBastedt/Marlin/commit/a14dcf90ad91f210cd6de0e8a2d4308a0de8eb2b
that maintains the 0-255 range until point of firing the laser. Then the limit is the PWM resolution, can be increased but eventually the cpu clock frequency will limit.
(The code is not tested)

[Downunder35m]

My x and y motor run at 157.48 steps per mm.
Did some more tuning and can reliable engrave at 4800mm/min now.
Only problem is the simple fact that the IR light attacks the wood much harder than the visible light from a diode laser.
But with the right speed and power it looks quite good, really good when doing 2.5D engravings.
Currently working on getting the display and SD working and to implement the changes in the LCD stuff.
If I find the time tomorrow then I will find a way to add the minimum power level for raster engravings into the M649 command as I am sick of flashing the firmware for every change to test it.
Still no clue how to get result up on Github but will figure it out one day LOL
Would like to see your code tested as your approach looks like mine in reverse and I when I tired a similar approach I either got no laser power at all or really bad looking engravings.
But I did not include these calculations like you did.

[emartinez167]

Have you guys checked the work being done by Laserweb (Peter van der Walt)

https://github.com/openhardwarecoza/LaserWeb

They are now working on an improver LaserWeb2 version.

It would be good if both projects are aware of each other.

Regards,

Ernesto

On 18 Apr 2016, at 16:41, Downunder35m notifications@github.com wrote:

My x and y motor run at 157.48 steps per mm.
Did some more tuning and can reliable engrave at 4800mm/min now.
Only problem is the simple fact that the IR light attacks the wood much harder than the visible light from a diode laser.
But with the right speed and power it looks quite good, really good when doing 2.5D engravings.
Currently working on getting the display and SD working and to implement the changes in the LCD stuff.
If I find the time tomorrow then I will find a way to add the minimum power level for raster engravings into the M649 command as I am sick of flashing the firmware for every change to test it.
Still no clue how to get result up on Github but will figure it out one day LOL
Would like to see your code tested as your approach looks like mine in reverse and I when I tired a similar approach I either got no laser power at all or really bad looking engravings.
But I did not include these calculations like you did.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[nextime]

@HakanBastedt more than using G8 i would like to have an M code to select how G7 would act, if using full 8 bit raster or the "usual TT" one, and by default if not selected using the "old TT" one, so, we can still fully compatible with the old TT G7 and having an 8bit implementation on the same G code.

@Downunder35m i'm working on a patch to implement all TT modifications ( and few more ) on the MarlinKimbra (MKFirmware/MarlinKimbra#113), i will probably add also your modifications to it.

@emartinez167 i know and use LaserWeb, and i have access to LaserWeb2 repo too, i will work to integrate my MarlinKimbra modifications on it to make it fully compatible, so, if the same modifications will be done also on Marlin, i will assure it works on it too

[emartinez167]

Excellent!!!!
On Mon, 18 Apr 2016 at 17:50, Franco (nextime) Lanza <
notifications@github.com> wrote:

@HakanBastedt https://github.com/HakanBastedt more than using G8 i
would like to have an M code to select how G7 would act, if using full 8
bit raster or the "usual TT" one, and by default if not selected using the
"old TT" one, so, we can still fully compatible with the old TT G7 and
having an 8bit implementation on the same G code.

@Downunder35m https://github.com/Downunder35m i'm working on a patch to
implement all TT modifications ( and few more ) on the MarlinKimbra (
MKFirmware/MarlinKimbra#113
MKFirmware/MarlinKimbra#113), i will probably
add also your modifications to it.

@emartinez167 https://github.com/emartinez167 i know and use LaserWeb,
and i have access to LaserWeb2 repo too, i will work to integrate my
MarlinKimbra modifications on it to make it fully compatible, so, if the
same modifications will be done also on Marlin, i will assure it works on
it too

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#3208 (comment)

[MetalMusings]

@nextime I am puzzled because I don't understand what you mean by the differences between 8bit and 'TT'. TT's approach does encode every pixel in 255 range greyscale. Then due to the implementation in Marlin it sometimes doesn't come out very well, but there is a (at least one) fix for that as I showed in my code. What I have read is that @Downunder35m have changed what the data in the G7 command means, with a larger than 255 range, and that is my worry. I could be wrong. But all I am saying is that I would like to keep the 255 encoding as TT did it, and fix the bad greyscale resolution at low intensity inside Marlin.

@Downunder35m I will see if I can test the code tonight. It will have to be on the laserdiod so I'll see what I can do.

@emartinez167 I know of LaserWeb as well. I would really like so see that photo engravings can be encoded into G7 raster commands.

[nextime]

@HakanBastedt no, TT doesn't use full 8bit resolution, it scale down to power values in a percentage value, so, 1 to 100 instead of 1 to 255. @Downunder35m patches are to move to full 8bit.

[MetalMusings]

@nextime that is not correct. The pixel data in the G7 line is full 256 range. It is when the pixel data enters these lines

OldRange = (255 - 0);
NewRange = (laser.rasterlaserpower - 7); //7% power on my unit outputs hardly any noticable burn at F3000 on paper, so adjust the raster contrast based off 7 being the lower. 7 still produces burns at slower feed rates, but getting less power than this isn't typically needed at slow feed rates.
NewValue = (float)(((((float)laser.raster_data[i] - 0) * NewRange) / OldRange) + 7);

the value gets reduced from 0-255 range to 0-100 range. I have not seen @Downunder35m's patch, but I show one way to get rid of this limitation in the commit link a few messages above.

[marcwolf1960]

Hi.. I am glad I have found this conversation.
I have a Tevo Black Widow and I am working on modifying it for 3D Filiment/Laser/CNC. The function change will be by using custom tool mount plates. What I am hoping to do is to find 2 spare inputs so I can use a simple binary decode to work out what physical head is installed.
i.e. 00 - No Head, 01 - 3D Print, 10 - Laser, 11 - CNC.
The Mega can then do a check before starting the print and so update the LCD with the correct tool, and also enable/disable various functions or codes.
Likewise as most 3D print style software can have some starting G-Codes one can add in a specialised one to check that the correct tool is installed and warn if not.
Just some idea's.

[empakoso]

I too am glad I found this. I currently have a diode laser mounted alongside my extruder. I've used a selector switch between extruder fan and laser. I use the Inkscape laser plugin to turn the laser/fan output on/off.
The only difference is that my laser is always attached and I can begin using it with a simple flick of a switch. It is riding alongside the extruder permanently.

It would be great to have a T0 (extruder) and T1 (laser) #define that allows me to switch over.
I would like the T1 to use the offsets already defineable in the Marlin config. The difference is that I would like to avoid having to set all the other related defines usually needed for a dual extruder setup.
Switching from T0 to T1 would immediately move the printer to the new offset position to verify position and begin use (I think it already does this, not sure, since I can't get around all the dual extruder settings as of now)

Hoping this could be an over-simplified way for the creative juices to begin flowing for dual purpose movement. (Pens, dremels, scribes, strapped/taped to extruders ;)

I have my own idea of a metered syringe to make silicone gaskets, where I'd like to snap a plastic nozzle with a flexible feeder hose to it.

[thinkyhead]

Hi all. I've implemented G53 and G54-G59.3, also adding the common "chaining" behavior of CNC G-code, where you can use a command like…

G53 G1 X20 F500

…to do a move in machine-native space.

See #8200 for details.

[MetalMusings]

Hi again, I was active on this topic some years ago. Nice to see progress and that a continuous laser mode is now available. My CO2 laser has been dismounted but my laser diode printer is still live and working very well with the Marlin I worked on earlier in this issue. Eventually I couldn't keep up with the changes made here so still at a much older version. Perhaps we can improve on the laser functionality a bit, I can spend some time on it. I think there are two issues really that can be addressed

• Continuous laser mode/constant laser intensity have the problem that when the speed changes so does the power transferred to the surface. Longer exposure => more burn/darkness, same effect as higher intensity. That's why engraving with continuous laser intensity always gets darker at the edges where the head needs to slow down to change direction. The buildlog laser implementation had a special mode for that LASER_PULSE which fixed that issue. I think an even easier way is to vary the laser intensity with the speed. That is, intensity to the laser is = (specified laser intensity)*(real speed)/(set speed Fxx). This needs to be in the stepper ISR and evaluated and adjusted at every step. This way every piece of the lasered path will get the same amount of laser energy. This way even engraving using contunous laser intensity mode will get a decent result with consistent gray scale over the whole engraved area. However, the speed may not be all that great when engraving this way.

• The raster mode (G7 mode) is really where it really shines. Good speed, good results. Now, the buildlog uses a pseudo-axis for that. It isn't a real axis but in the stepper ISR it is treated as an axis and steps are counted just like a real axis. I think, why not treat it as a real axis, like E1 or so. With some luck all configurations/kinematics like delta maybe can be supported. This is pulsed mode where every pixel is fired with a pulse of a certain intensity. The axle E1 determines the firing point and need to carry along the intensity setting for the pixels. A laser_pulse() function is need to do the actual firing. Two arguments, intensity and duration.

I see there are a lot of changes in the stepper isr and I need guidance to find my way there. Interest?

[davidelang]

see the hangprinter discussion where there is also need to define additional axis and questions about how it should be done (and what needs there are for additional axis definitions)

[croisez]

I want to use a Marlin firmware on my home made Prusa-like H printer which use a quick-fit system to go from 3D-print head to 2.5W laser engraving head.
I want to use M106 fan0 to drive either fan0 or laser power.

Currently, with Bugfix-1.1.x branch of Marlin, I am able to set laser pwm with M106 S command, and am able to do some vector engraving.
But whenever I engrave in grayscale raster, the rendering (on cardboard or plywood) is howfull.

I wonder if Marlin function gcode_M106() and gcode_M107() does need to be modified to synchronize stepper movements with M106 and M107 commands.
Do I understand well, and is my reflection correct ?

Actually, I got stripping bands which should not be there, like on this power calibration test on cardboard :
https://photos.app.goo.gl/cnmHOvZfnj7A03t12

[thinkyhead]

Have you tried this?

/**
 * Spindle & Laser control
 *
 * Add the M3, M4, and M5 commands to turn the spindle/laser on and off, and
 * to set spindle speed, spindle direction, and laser power.
 *
 * SuperPid is a router/spindle speed controller used in the CNC milling community.
 * Marlin can be used to turn the spindle on and off. It can also be used to set
 * the spindle speed from 5,000 to 30,000 RPM.
 *
 * You'll need to select a pin for the ON/OFF function and optionally choose a 0-5V
 * hardware PWM pin for the speed control and a pin for the rotation direction.
 *
 * See http://marlinfw.org/docs/configuration/laser_spindle.html for more config details.
 */
//#define SPINDLE_LASER_ENABLE

It enables the proper use of M3/M4 and M5.

[croisez]

two questions:

• my laser PWM is connected physically to the FAN0 output of my Ramps1.4 ; are those M3,M4,M5 commands compatible with FAN0 on D9 ?
• if I enable the define SPINDLE_LASER_ENABLE, is this compatible with a normal 3D printing use? Because I don't want to reflash Marlin firmware every time I want to switch from laser to 3dprinting and back.

[thinkyhead]

if I enable the define SPINDLE_LASER_ENABLE, is this compatible with a normal 3D printing use? Because I don't want to reflash Marlin firmware every time I want to switch from laser to 3dprinting and back.

Once you configure the spindle/laser options, you can then use M3/M4/M5 to control the spindle or laser. It doesn't conflict with 3D printing.

The pins SPINDLE_LASER_PWM_PIN, SPINDLE_LASER_ENABLE_PIN, and SPINDLE_DIR_PIN are pre-defined in most pins files. For example, in the RAMPS pins file:

//
// M3/M4/M5 - Spindle/Laser Control
//
#if ENABLED(SPINDLE_LASER_ENABLE) && !defined(SPINDLE_LASER_ENABLE_PIN)
  #if !NUM_SERVOS // try to use servo connector first
    #define SPINDLE_LASER_ENABLE_PIN  4  // Pin should have a pullup/pulldown!
    #define SPINDLE_LASER_PWM_PIN     6  // MUST BE HARDWARE PWM
    #define SPINDLE_DIR_PIN           5
  #elif !(ENABLED(ULTRA_LCD) && ENABLED(NEWPANEL) \
      && (ENABLED(PANEL_ONE) || ENABLED(VIKI2) || ENABLED(miniVIKI) || ENABLED(MINIPANEL) || ENABLED(REPRAPWORLD_KEYPAD)))  // try to use AUX 2
    #define SPINDLE_LASER_ENABLE_PIN 40  // Pin should have a pullup/pulldown!
    #define SPINDLE_LASER_PWM_PIN    44  // MUST BE HARDWARE PWM
    #define SPINDLE_DIR_PIN          65
  #endif
#endif

[croisez]

Physically, I have to share PWM D9 pin, both for part cooling and for laser PWM power control, because I use a quick fit system with a DB26 connector for fast plug/unplug of laser/printing, and almost 26 pins of this connector are already used. Do you think that if I define both SPINDLE_LASER_PWM_PIN and FAN_PIN to the value RAMPS_D9_PIN it will work without a hassle? *L*OUIS 2018-03-15 22:11 GMT+01:00 Scott Lahteine <notifications@github.com>:

…

if I enable the define SPINDLE_LASER_ENABLE, is this compatible with a normal 3D printing use? Because I don't want to reflash Marlin firmware every time I want to switch from laser to 3dprinting and back. Once you configure the spindle/laser options, you can then use M3/M4/M5 to control the spindle or laser. It doesn't conflict with 3D printing. These pins SPINDLE_LASER_PWM_PIN, SPINDLE_LASER_ENABLE_PIN, and SPINDLE_DIR_PIN are pre-defined in most pins files. For example, in the RAMPS pins file: //// M3/M4/M5 - Spindle/Laser Control// #if ENABLED(SPINDLE_LASER_ENABLE) && !PIN_EXISTS(SPINDLE_LASER_ENABLE) #if !defined(NUM_SERVOS) || NUM_SERVOS == 0 // try to use servo connector first #define SPINDLE_LASER_ENABLE_PIN 4 // Pin should have a pullup/pulldown! #define SPINDLE_LASER_PWM_PIN 6 // MUST BE HARDWARE PWM #define SPINDLE_DIR_PIN 5 #elif !(ENABLED(ULTRA_LCD) && ENABLED(NEWPANEL) \ && (ENABLED(PANEL_ONE) || ENABLED(VIKI2) || ENABLED(miniVIKI) || ENABLED(MINIPANEL) || ENABLED(REPRAPWORLD_KEYPAD))) // try to use AUX 2 #define SPINDLE_LASER_ENABLE_PIN 40 // Pin should have a pullup/pulldown! #define SPINDLE_LASER_PWM_PIN 44 // MUST BE HARDWARE PWM #define SPINDLE_DIR_PIN 65 #endif #endif — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3208 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABsSyd6ueDLgMJri7ePs8lgx2XqpDJrzks5tetkPgaJpZM4H2DPU> .

[thinkyhead]

You don't want to have the SPINDLE_LASER_PWM_PIN run 12V to most lasers, as it will kill them. It should be ok to share the fan with the constant SPINDLE_LASER_ENABLE_PIN pin, however.

[croisez]

currently, I am using the electrical signal coming from the gate of the mosfet for FAN0 as command for my PWM laser module instead of the one coming from the D9-labelled signal coming out of the RAMPS. I first tried to use the RAMPS switched 12V signal, by transforming it back to a valid TTL PWM signal, but finally I gave up to using the signal of the mosfet gate, which is a nice 0-5V PMW signal (on pin D9 of the Arduino MEGA). *L*OUIS 2018-03-19 11:13 GMT+01:00 Scott Lahteine <notifications@github.com>:

…

You don't want to have the SPINDLE_LASER_PWM_PIN run 12V to most lasers, as it will kill them. It should be ok to share the fan with the constant SPINDLE_LASER_ENABLE_PIN pin, however. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3208 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABsSyQ6Wh13tp8MSC7rZuvF5YmnwYSJYks5tf4TfgaJpZM4H2DPU> .

[Spidermakercnc]

Hello everyone I'm new in the forum and I'm very interested in this topic, I would like to ask a question if possible, how do I modify the firmware resolution from 8 to 16 bit pwm? On what parameters should I act? thank you very much for your availability

[thinkyhead]

@Spidermakercnc — Here's a sample function that can be added to Marlin to set Timer 5 to just about any frequency. Adapt and modify according to your needs.

/**
 * Set Timer 5 PWM frequency in Hz, from 3.8Hz up to ~16MHz
 * with a minimum resolution of 100 steps.
 *
 * DC values -1.0 to 1.0. Negative duty cycle inverts the pulse.
 */

uint16_t set_pwm_frequency_hz(const float &hz, const float dca=0.0, const float dcb=0.0, const float dcc=0.0);

uint16_t set_pwm_frequency_hz(const float &hz, const float dca, const float dcb, const float dcc) {
  float count = 0;
  if (hz > 0 && (dca || dcb || dcc)) {
    count = float(F_CPU) / hz;            // 1x prescaler, TOP for 16MHz base freq.
    uint16_t prescaler;                   // Range of 30.5Hz (65535) 64.5KHz (>31)

         if (count >= 255. * 256.) { prescaler = 1024; SET_CS(5, PRESCALER_1024); }
    else if (count >= 255. * 64.)  { prescaler = 256;  SET_CS(5,  PRESCALER_256); }
    else if (count >= 255. * 8.)   { prescaler = 64;   SET_CS(5,   PRESCALER_64); }
    else if (count >= 255.)        { prescaler = 8;    SET_CS(5,    PRESCALER_8); }
    else                           { prescaler = 1;    SET_CS(5,    PRESCALER_1); }

    count /= float(prescaler);
    const float pwm_top = round(count);   // Get the rounded count

    ICR5 = (uint16_t)pwm_top - 1;         // Subtract 1 for TOP
    OCR5A = pwm_top * ABS(dca);          // Update and scale DCs
    OCR5B = pwm_top * ABS(dcb);
    OCR5C = pwm_top * ABS(dcc);
    _SET_COM(5, A, dca ? (dca < 0 ? COM_SET_CLEAR : COM_CLEAR_SET) : COM_NORMAL); // Set compare modes
    _SET_COM(5, B, dcb ? (dcb < 0 ? COM_SET_CLEAR : COM_CLEAR_SET) : COM_NORMAL);
    _SET_COM(5, C, dcc ? (dcc < 0 ? COM_SET_CLEAR : COM_CLEAR_SET) : COM_NORMAL);

    SET_WGM(5, FAST_PWM_ICRn);            // Fast PWM with ICR5 as TOP

    //SERIAL_ECHOLNPGM("Timer 5 Settings:");
    //SERIAL_ECHOLNPAIR("  Prescaler=", prescaler);
    //SERIAL_ECHOLNPAIR("        TOP=", ICR5);
    //SERIAL_ECHOLNPAIR("      OCR5A=", OCR5A);
    //SERIAL_ECHOLNPAIR("      OCR5B=", OCR5B);
    //SERIAL_ECHOLNPAIR("      OCR5C=", OCR5C);
  }
  else {
    // Restore the default for Timer 5
    SET_WGM(5, PWM_PC_8);                 // PWM 8-bit (Phase Correct)
    SET_COMS(5, NORMAL, NORMAL, NORMAL);  // Do nothing
    SET_CS(5, PRESCALER_64);              // 16MHz / 64 = 250KHz
    OCR5A = OCR5B = OCR5C = 0;
  }
  return round(count);
}

[Spidermakercnc]

Uauuuu thank you have been the only one who gave me an answer, thank you so much, I can steal wualche always if you have time and desire as I have practically no basics of programming (I just bought 4 volumes on programming Arduino and C) but) I'm an electronic expert, this code that you wrote me I have to insert in the config.h or in the initial? Then another thing you could explain to me even in detail to understand what it does? Thank you so much, I would pay you swear

[shitcreek]

@mkeyno Much of the laser/spindle codes have been improved such as laser/spindle PWM frequency, inline firing and trapezoidal power scaling.
Give it a try, then please close this FR if it's no longer needed. Thanks.

[mkeyno]

thanks, @shitcreek , I should check it with my SAM Due board

[sjasonsmith]

@mkeyno, since you haven't responded, I am going to close this request based on the improvements mentioned by @shitcreek. I am sure there are many improvements yet to be made, but it makes sense to track those with more granularity as issues are found.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.