Marlin: [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: https://github.com/MagoKimbra/MarlinKimbra/pull/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?

[HakanBastedt]

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: https://github.com/MagoKimbra/MarlinKimbra/pull/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

[HakanBastedt]

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.

[HakanBastedt]

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.

[HakanBastedt]

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 [email protected] 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 (https://github.com/MagoKimbra/MarlinKimbra/pull/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 <
[email protected]> 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 (
MagoKimbra/MarlinKimbra#113
https://github.com/MagoKimbra/MarlinKimbra/pull/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
https://github.com/MarlinFirmware/Marlin/issues/3208#issuecomment-211303360

[HakanBastedt]

@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.

[HakanBastedt]

@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.

[nextime]

Well, i was under the impression that the Downunder35m's patch was about avoid reducing in the 0-100 range as he was talking about "full 8bit", but i don't have yet looked at it too.

[HakanBastedt]

Well the 0-100 range is indeed a limitation in itself, especially at low intensity. That should go away.
My example code just delays the multiplication of intensity and pixel data value to the last point possible, thereby keeping resolution as good as it gets.

[Downunder35m]

That sounds great but I still have not figured out how to actually upload my stuff to Github, must be too simple so I overlook something LOL
I guess the discussion about TT's raster or full 8bit is a bit useless.
TT implemented a limit of 100 to stick to the original 100% power settings with the original controller.
Or at least he thought 100% is a good value for calculations.
I changed all the vital parts for these calculations so full 8bit rastering is now possible.
Since there is no real difference in terms of speed or handling to TT's choice I fail to see why anyone would need an engraving resolution of just 2 or 3 bit.
Sure it is a bit different with the power levels but for a CO2 laser you need it, a diode might be able to do with less.
With Laserweb I expeimented a bit and think if you can convert the base64 stuff then there should be no problem to implement the G7 code as well.
Ok, if I can't figure out this Github stuff I will upload it all as a RAR file to a filehoster.
The 8bit engraving works fine although it is quite a task to find the correct speed and power settings so the wood does not disappear, should be fine with diode lasers though.
Will also include my modified version of the Inkscape plugin as the two belong together for now anyway.

@HakanBastedt:
Trust me when I say that I fell for the same "trap" in the code.
It sure is true 8bit but no matter how you turn it it goes down to whatever is available in terms of analogwrite capabilities.
Since there we are again limited to just 0-255 the calculations for the power range need to be included before we get to the firing or the entire system has to be changed to allow for decimal digits like 9.76.
The last I tired and it was a disaster as float values kill processing speed.
On top of that come the simple that float calculations on Arduino are never 100% correct.
So I eliminated both the problem of the power resolution by increasing the 0-100 range to 0-1000 and by modifying the raster range calculations and base64 library.
I did my best to comment on all the changes I made but I might have missed a few spots where I changed calculation values from float or char to integer values.
And as said the base64 library was changed accordingly but this only goes for the output so far until we get 16bit or at least 12bit resolutions working.
I only have to check the display and SD features and make the changes for the power levels to the display stuff.
So tomorrow around this time the archive should be available somewhere to download and test.
Keep in mind though that I already optimised everything for the use on the K40 clones as listed in my Instructable.

Just started another testengraving to check the power levels, will edit in a bit to provide a link to check it as it seems I can't include images here.
Edit1: Settings used for the engraving...
Speed: 4200mm/min (above that I still get some problems with the stepping and calculations)
Material: 3mm plywood
Power settings: Lower limit set to 580, max engraving power 1092 - this equals 5.8 to 10.92 in the original scale if decimals were supported.
And as said with CO2 it is really tricky to get ALL settings right for a good result.

Here is the image:
http://oi63.tinypic.com/s400nt.jpg
Not as good as it was on paper but this plywood I have is really crap, will do some more tests on proper wood shortly.

[HakanBastedt]

It is not in the data from the Inkscape plugin, unless you think 255 levels of greyscale is not a good enough representation of your image.
The actual laser levels will never be better than the resolution of the PWM duty cycle, TT's code sets it to 10-bit, 1024 levels. With this it is at least in theory possible to get 256 different and unique PWM greyscale levels with 25% intensity. One way to improve this is to increase the pwm resolution, timer 3 and 4 are 16 bit timers, so some improvements can be done there. You don't solve this problem with higher resolution in the G7 pixel data.

I will test my code tonight, and I might remove a few floats if it works.

[Downunder35m]

I see we think at the same level when it comes to figuring out what TT did and how.
All I can say is that I do get 256levels of power for the 8bit mode, or better: 256 mapped power levels.
Increasing the PWM resolution further will most likly cause timing issues.
Would like to see someone with a diode setup try my mods one day as I assume they too fail to burn the wood at lower power levels.
So this area where nothing happes to the wood can be eleiminated in the range calculation and for the rest you still get the full 8bit.
I am still working on the code for the display so I won't really have time to apply your changes and test them in the next few days.
My aim for 8bit is 2.5D engravings more than picture engravings but if I get the power levels right for pics than nothing bad can happen in 2.5D ;)

Keep in mind my approach was not to mess with any timings or PWM signals.
I simply wanted the input range for the power increased to give more resolution.
And as the standard base64 library was unable to handle this I change it too. (only a tiny bit)

The power mapping goes something like this:
Inkscape adds the user selection into the M649 command.
Marlin reads the S value in the M649 command and uses it as a replacement for the intensity value.
The pixel data is only used to store the original grayscale values, in Inkscape and in the decoding part within Marlin - they are used here for the positioning.
The power mapping takes care that the actual pixel value changes to be within the constraints given by the NewValue in the mapping calculations.

[Downunder35m]

Seems I finally managed to get the code up, so you guys can check and test them for yourself if needed.

[HakanBastedt]

Ok, I have tested my code, One fix needed, just counted wrong in my head. It works now.
Tested with laserdiode on Masonite. 100% intensity was ok, smooth grayscale transitions - I found a test picture. At 4% intensity and running veery slow, well it isn't so easy to see from the engraved result because if the masonite has started to char it seems to continue charring even at lower intensity levels. On the oscilloscope it looked good, in that small 4% window there at least seemed to be more than the original 10 transitions, definitely more than 10. It should be 40, perhaps it was, couldn't really tell the signal wasn't really that good, but it looked like smooth transitions.
The commits are here: original https://github.com/HakanBastedt/Marlin/commit/a14dcf90ad91f210cd6de0e8a2d4308a0de8eb2b + fix: https://github.com/HakanBastedt/Marlin/commit/a87a8b8e6c63c46d54ea0e16110097eacec78756

[HakanBastedt]

So I tested quite a bit, and when I run on the CO2 laser which has this lowest power threshold, you know the 7% remapping, it turns out that this mapping needs to be moved from planner.cpp to laser_fire, because it is the actual power level to the laser driver that needs to be remapped.
I have done it on the CO2 laser (running a Due) and will do it in the Mega tomorrow. I don't have this power level issue on the Mega/laserdiode, but for completeness I'll do it. Apart from that everything works beautifully.

[Downunder35m]

I did some tests and at least in the theoretical world of calculations it is possible to increase the raster resolution from 8bit to 12 or even 16bit.
Inkscape seems to accept 24bit images without complaining, not sure though if they are rendered down.
Only problem is the encoding, although it would be possible to change the base64 library to accept 16bit values the resulting amount of code is massive.
And the TT plugin uses PIL, which would need to be updated to Pillow for 32bit image support.
Oh, of course the TT plugin code must be changed to read the higher bit values correctly so they can be base64 encoded.

Does anyone think it would make sense to go from 8bit to 16bit or even higher grayscale resolutions?
My CO2 laser won't be of any use for this and I don't know if diode lasers would be capable of producing a noticable difference worth the blow up of the Gcode file.
Would have to do some serious calculations to check if the current way of handling the analogwrite for the laser would still be enough to allow for 16bit.

[HakanBastedt]

Have a look at the Image.convert('L') function in the Inkscape function as well, that one does the actual grayscale conversion, at least I think so.

I had a deeper look into TT's timer3 and timer4 initializations and the good news is that the full 16 MHz is used. With a setting of LASER_PWM to 1000 this gives a 16000 bits PWM resolution. It is not 1023 as I wrote, that is just something in my code. With the code I just presented this should give full 255 range grayscale as low as 4% intensity.

I don't have any specific requirements on raster depth so 8 bits are fine with me.

[Downunder35m]

Little bit on a sidenote here:
When I started to mod the TT release I noticed one thing wuite soon and that was a lower raster speed compared to the crappy original controller.
What the Mega2560 can do in terms of movement speed is basically limited by the CPU frequency.
Around 63mm/s is the limit here but Marlin can cheat by using a so called quad stepping mode where the commands are sends every forth step.
I noticed then when trying to go over this "fixed" speed limit the rater mode starts to struggle quite badly.
Starting with pinholes at the borders up to stuttering and losing steps.
To some extent this is rectified in MarlinKimbra but still not fully solved.
Increasing the serial buffer did not help much either in this case as the stepper calculations still require the CPU power.
In other posts on the web I found that around the 60mm/s mark is the usual limit for 8bit CPU's when it comes to raster engraving, worse if only the G1 command is used for it.

I know my code works just fine without messing on any PWM signal.
That is no offense in any way and I will try explain why:
TT based his calculations on the older power supplies and laser tubes used in the K40 clones.
Not too much has changed hardware wise to my knowledge.
For the original controllers it is stated that a use over 68% of power will shorten the lifespan of the tube.
TT mentioned the same value in some older blog I found back in the day although it was also stated that most tubes will be fine till around 75% of power.
The PWM frequency is also set to match the original controller which makes sense as laser tubes of different power or type will need different power leves and ofeten a different frequency.
TT limited the resolution more or less intentionally, I removed the limit by means of adjusting the calculations.
It would be very intersting to see your way of addressing the problem on a similar machine in comparison.
Although I removed a lot of the flot operations the speed improvement was only marginal.
If your code would require less computing power it could mean faster speeds are possible which is always a benefit.

How exactly translates your code change to the power mapping to the laser?
I am asking as I made a similar approch to yours just instead of the PWM change I only changed the mapping calculations.
Here I noticed an overflow problem that often caused totally black areas to be either not engraved at all or at a drastically reduced power level.
The Gcode was fine by the way.
Also if you change the PWM duty cycly like this, how does the affect the actual signal compared to the orignal?
I am asking because if the signal falls out of range for the power supply I wouldn't even have a clue what happens.
Did you do any real life test with your code yet?
Would love to see an engraving for comparison.

With the Inkscape coversion to 16bit I will wait a bit and do some tests on my calculator first.
At this stage I am almost certain USB is out of the question for the amount of date that needs to be transfered and I could not find any info on how fast the SD controller on theses Smart discount controllers is.
And as said computing power is the next issue as the speed in 16bit would limited to around 20mm/s max according to my estimation based on the CPU and stepping calculations.

[HakanBastedt]

On my laserdiode machine I use the Mega, and I have the same issues like you describe. Too high speed gives stuttering. Making the machine take fewer steps/second helps, by reducing steps/mm on motors and increasing pixel size - but maybe not wanted. Certainly there is a limit to the speed, 60 mm/sec you say, I get a little less but over 50 mm/sec. My motors have 200 steps/mm so I can image the difference is there. There are options, I for one run Marlin on Due on my CO2 laser. This machine easily engraves 10 times faster, over 650 mm/sec in a test. Same laser modifications from TT. So when I try on CO2 laser it is always on the Due.

But don't you use the Timer3 and Timer4 code from TT? There you have the option to set the PWM laser frequency with the LASER_PWM define in Configuration.h. With this the PWM frequency can be adopted to whatever the laser driver needs. Use 20 kHz if you want, or use the default 490 Hz if you want. Up to you. TT's code makes the best of the situation - there is 160000000 pulses/second available. If you use 490 Hz there is 16000000/490 pulses / PWM cycle = 326530 pulses. That is the resolution you will get. Not 1023, but 326530. And in laser_fire, in the analogWrite() statement to fire the laser, the 0-100 range is mapped to the 0-326529 range. Nothing extra needed, it is all in the code from TT. I did mess with this in the beginning, but I will change back to TT's code because his code is better. If you use the standard timer setting from Arduino and analogWrite - then you should immediately change over to TT's code.

I haven't really bother about the upper limit, if I want to run at 100% or 68%, well I just do it. But the remapping for lowest power level is nor for that - the 7%. If you engrave with a certain speed and power level - and then double the speed and half the power level = same power for every pixel, you may notice that the engraving does not have the same darkness. One reason for that seems to be that some laser drivers need a certain minimum pwm signal to start at all. In TT's case his laser driver needed 7% PWM to do anything noticeable, therefore he remapped 0-100 intensity to 7-100 intensity. I need to do the same, my CO2 laser driver has something like 3.5% as minimum threshold. With the code modification I made, this remapping needs to be moved - not changed - from planner.cpp to laser_fire, a link to the commit is here: https://github.com/HakanBastedt/Marlin/commit/f2c3ace5be4b65bf2468141c9ee8e4a9092fed3c This adds one floating point multiplication and one floating point addition to the laser_fire code. Either that or add 68 bytes to every planner block, by increasing the resolution of the raster data from 8 bit to 16 bit. I did it this way. I have not seen any over/underflow problems, and there should no be.

You haven't looked at my code I understand: it is is here https://github.com/HakanBastedt/Marlin/tree/dual_y_motors . And the code for Due is there as well. Have a look to see how I did it for my machines.

I tested the whole evening yesterday, both on the laserdiode and the CO2 laser with these modifications. I tried to increase PWM resolution and discovered that is was already as good as is possible. On both Due and Mega. I got it to work fine, I mean it works fine for my purposes. I engraved an image that transistions from white to black with no visible steps, and there were no visible steps on the engraving. Ok, Masonite isn't the best material for engraving. I run with TT's Inkscape plugin unmodified in the area of base64 and image conversion etc.

16-bit it just double the amount. My CO2 with Due easily swallows 10 times at the same baud as the Mega, amount of data should not be a problem.

[Downunder35m]

I see we will some more interesting discussions to come :)
Will have to find some time to check your code for comparison one day.
I just wanted to leave the TT code as genuine as possible to avoid problems.
So I removed some float calculations change some values to int and only change the input range limit from 100 to 10000 to basically get decimal point precision without using float calculations.
Might be just a lingering effect from back in the day when I started coding, our techers always said that float operations slow everything dow so they should be avoided.
Since the Mega only uses a 8bit processer with no math processor added I thought it was the best approach.
But now with your explanation the way you took also makes sense to me.
From a cumputing power point of view I don't see that your method would cause more problems than mine either.
There is one nagging question though that I could not really figure from the code.
If you leave the input levels unchanged, how to are you able to get a value of let's 9.35% as the input?
For the engraving all is automated as I understand but at least I like to be able to use a finer input when required.
And so far (from my few tests) entering 9.34, 9.7 or just 9 for the power level always results in just plain 9 to be used.
Might be no issues for most people but even for vector works I like to be able to say that I just want to darken paper instead of burning through.
Sure speed will compensate for that but IMHO it is easier to have a complex job with multiple operations working at a good a solid speed and to adjust the power accordingly.
Takes one fuzzy value out of the preparing calulations.

As for controllers and speed...
I know the due or other 32bit processors won't have any problems getting much higher movement speeds, question is: do we need that on a hobby level?
At least for what I do I prefer to keep the laser power on the lower end as new tubes are quite expensive over here.
So speed is a relative terms as more of it also means higher power levels for the laser.
Diode lasers at the currently used power levels are not really able to go lightning fast either, so for most it will come down to what is available and how much it will cost.
So IMHO the foucs on faster hardware should start once the birthing problems are solved so it all works great on a 8bit architecture.
After all it is not much more than defining a different board in the configuration.
In terms of 8bit vs 16 there won't be any other option than to use 32bit CPU's if you want to keep the same speed as we can use right now in 8bit.
A think that I would love to test but that is over my limited coding skills would be to create a mutilated Marlin version with all 3D printing stuff not just dormant but completely removed.
Basically just the movement stuff and what we need to support the laser, pumps, cooling, safety switches and so on.
I think for the sole usage in a laser machine this would be a massive benefit.

The one thing that is really nagging me still is the "bug" in Marlin for the double and quad stepping modes.
It is implemented for some years now but I have not found a single version that actually works reliable above the 63mm/s limit (or around 10000 steps/s).
Well, that is not entirely true is it?
On my 3D printer I can reach printing speeds of up to 200mm/s if I really push it and use just PLA.
So something tells me the stepping modes must be optimised for multiple axis moving at the same time at about equal amounts of moves - like it happens in a lot of printing jobs.
Here I also noticed that during solid infills the speed can't really be reached without problems - similar to what happens in our raster engravings.
But I am unable to find the algorithms for this otherwise I would try find a way to change the calculations.
If you think about it:
During raster engravings it would not matter really if 1/16, 1/8 or any other stepping is used as we just move a full line length as defined by the base64 calculations and mm per pixel.
Changing or getting the quad stepping working properly during raster jobs would allow to reach around 180mm/s or if running as good as the normal mode even up to around 200mm/s.

[HakanBastedt]

I am with you on the floating point avoidance, and there is room for improvements in the code I made as well. Sometimes it will obscure the meaning with the code. If someone picks it up and modifies it, sure, do it.
The power setting is in the M649 Sx line. When looking at the code a setting of M649 S7.35 should come over to Marlin as intensity 7.35 and then further on used untruncated. You can check the M649 line just before the raster data, if you set power to 7.35 in the Inkscape plugin it should come out as M649 S7.35 in the G-code. I suspect the truncation is done in the Inkscape plugin, around the power level input field.

Yes a dedicated firmware for laser would be nice. I would like to disable the temperatures, extruder and hotends all together - I made a lame effort with than but wasn't successful at that point. At least at this point in time I prefer the free ride with Marlin when it comes to motions and handling of many other things. There is always grbl I guess.

When running at 0.1 mm/pixel the planner adds 600 steps/sec to change the laser power level. After all, there is a fair bit of code that should be run for every change of power level. One test could be to comment out the actual rastering code in the stepper isr and see what speed can be reached.

[Downunder35m]

Have to check the code again for the things affecting the intensity levels.
The last test I have done with the original TT release and there was no change in the laser power from let's say 9.0 to 9.9, all were lasered with just level 9.
For people interest I uploaded a video showing the raster engraving in action.
Couldn't get a clear focus with the stupid orange lid, this needs to be replaced with something clear soon...
But will certainly check if decimal values work out correct in Kimbra as this would certainly make things a bit easier for thos used to the standard 100% for the power levels.

www.youtube.be/7tPr2A6nMWw

[HakanBastedt]

Where is the value 9/9.9? In inkscape plugin or in the G-code? I checked in the inkscape plugin and it indeed does truncate 9.9 in the input field to 9.
If you check the G-code - it is one of the ten first lines - for the M649 it says S9 and not S9.9. Truncated by the Inkscape plugin. There is an "int" in the python menue file that should be "float" I think.

[Downunder35m]

I checked it by simply creating some lines with different power levels.
The Gcode was manually edited to give the values, so if Inkscape truncates than because somewhere in the firmware (at least the old one) it was lost.
But will look into it again for sure.

[HakanBastedt]

I looked at your video - nice! The lighthouse comes out very well. Never thought about using copier paper.

So I had to see if I could do the same. Took a few tests to dial in the power level - this one is run with S5.0 - and then it came out pretty ok https://dl.dropboxusercontent.com/s/xv4e9oo14r2eg8t/Laser-grayscale.png . Next time I'll use a bit more air to blow away the black spots. And the paper curled a bit so the laser lost focus, all beginners' mistakes with copier paper.

[HakanBastedt]

@Downunder35m Can you do a quick test? Engrave some known lines, but before that reduce accelerations down to really low like 100 mm/s2? Do you see anything odd? Anyone else seen something at the edges?

[Downunder35m]

With high speeds and straigt lines it is not too bad, just results in bad overburn during the acceleration.
But multiple, very short lines make the whole thing freeze up !? WTF?
Just sits there without any movement for about half a second and burns holes.
Did not run with the acceleration that low on the TT firmware very often but can't remember that I ever had such results.
But that can't be what you mean, there sure is an issue here somewhere that I missed.

I can do it again, what types of lines, lenghts and speeds do you suggest so we are on the same level for a comparison of results?

[HakanBastedt]

Engrave for example a centimeter of the lighthouse. The acceleration should be really low so the head spends most of its time accelerating up and down in speed.

[Downunder35m]

Checked your image and it looks really nice indeed considering the power levels are not right.
I prefer paper as it eliminates the inconsitencies of wood or other materials while giving more contrast at the same time.
Plus it really helps on a CO2 system to check if the power levels can be controlled with enough precision.
For paper I use sticky tape on all four corners to prevent the curling.
The power (max) I dial in like this:
Size reduced image at about half the speed the machine can do proper while engravng, in my case 2400mm/min.
If the laser burns holes without air assist I reduce the power and move the image a bit to the side or down so I don't need to place a new sheet of paper during the testing.
Once there are no more holes I increase the speed to around 4000mm/min and increase the power level until I see a good level of contrast.
If I can't reach that at full speed I reduce the speed and power until there is a good balance between speed and contrast.
Air aissist on paper is only required if your exhaust suction is insufficient or you are a bit far away from the exhaust hole.
If you need it to prevent the paper from burning it usually means the total black areas are charred and will cruble out of the paper when you flex it a bit.
Really need to find the time on the weekend to test your code a bit, do you have just the diffs or a complete release somewhere as well that you keep updated?

Ahh, you mean raster lines and not vector cuts, my mistake.
Give me about 30 min and I shall report back with the result.

[Downunder35m]

That is indeed a bit odd...
Going down caused slightly darker neds on the lines as it is expected with lower speed and same power.
100 works still fine though, then I went down to 50 and the laser stopped engraving.
Going up and it fires again.
Seems something is messing with the firing timing at such low acceration rates as the speed changes too much within a single line segment.
But don't see it as more than a bug as I don't see me ever running that low to be affected.

Was it that loss of lasering you meant?

[HakanBastedt]

Thanks fr testing. I didn't expect the machine to stop. I can clearly see that the engraving is lighter during acceleration and also some line patterns which shouldn't be there. The ends of my lines are whiter/brighter - oh well so it can still be in just my code. Usually I engrave with high accelerations and this is not noticeable then, or just a mm or so at then end of the line. Well, I guess I have to wait to dig into this until later, there are other things on the agenda such as auto-leveling the work table and auto-focus (one-time). I have an idea of what can be wrong, it has to do with the timing calculation during acceleration, for some reason the steps become too short for the laser steps. For now, I increase acceleration.

The contrast in your engraving was very good. Thank you for sharing how to set up the power. The black spots are hmm burnt paper I guess, I hoped the air should blow them away. The fumes were tolerable.

You find the diffs in the links I have given earlier in this thread. They are just diffs, starting from an new Marlin patched with TT's code. I think you will recognize things immediately.

[Downunder35m]

What you experience I had with the original TT firmware a few times even at normal acceleration settings.
Especially if the pictures borders are total black you could clearly see the laser power was reduced at the start and end of a line.
In sever cases it also caused "hickups" and pinhole burns at about 2-3% of distance from the border (taking the image width as the base).
I tracked the power problem down to the way the mapping of the power levels was done.
The orinal float method with an ending range below 512 power levels caused inconsistent spacing for the lowest and highest brightness levels of an image.
Together with the float calculations for the mm per pixel and the base64 source too much vital info was misintertpreted.
Pinhole problem was totally fixed with Kimbra so I assume it was based on the timing issue of the early Marlin releases.

You moved the power mapping into the stepping and as far I know the added calculations could be enough to upset things.
That was one of the reasons why I tried the other way around the problem.
Once you start changing timer settings you need to be sure those changes won't affect other cuntions or code in Marlin.
If I understand the code correctly than the timers regulate the movement and the power levels now.
Since one affects the other it might be as simple as syncronising it somehow.
Like doing all calculations first and store them before actually executing them.
But I hate getting timers right at the best of times so where possible I try to find code that is reported to works as expected before even start to mess around.

But if the problem only exists for acceleartion settings noone will ever use why bother too much?
If it is there at low speeds or still a problem with higher power levels and normal accelration values I would start digging, but at settings below 100 or 200?
Don't know about you but even with enough time to spare I prefer to finnish my engravings in one day LOL

[HakanBastedt]

It is still there, always, also at the highest acceleration. It is just much more easy to ignore it at high accelerations. It's on my CO2 Due so I won't bother you with this, that is something I have to work out myself. And it is not with the power levels, that is fixed. It has to do with timing. The scope shows that all pulses have the same width when I run an all-black image so that is ok. But during acceleration one would expect a seamlessly increasing and decreasing distance between the pulses and yes it is there. But there are also a lot of missing pulses, quite often, like one of ten or more is missing during acceleration, not regularly. I said I have to wait with this and yeah I have to wait with this.

[HakanBastedt]

I found the cause for power truncation. Laser.laserrasterpower i just a byte large. I trhouhj it away and use laser.intensity instead.

[Downunder35m]

Well, that was an easy fix then :)

[Downunder35m]

I managed to get the engraving speed on my K40 up to 6000mm/min now.
Simply set the jumpers for the stepping a bit down ;)
Still have to check the accuracy during vector works, same for lost steps during vector works at higher speeds.
I though the motors would be much louder with the reduced stepping but turned out the fan on the power supply is still louder.
So far the reduced stepping is just a test to check if the higher speed helps to get a wider range for the power.
Not so easy to find the perfect settings for 2.5D engravings, even harder to find the right wood for it LOL

[HakanBastedt]

10000 mm/min? :) Disable the lcd if you haven't done so already. I run the laserdiode with 200 steps/mm, it is overkill, 100 or even 50 steps/mm should give no visible change for me. And then set the pixel size to a multiple of the step length, that has turned out to be best when I engrave black paint on pcbs.

I have been looking for the acceleration issue a bit, there is some kind of interaction between laser steps and movement steps. I still don't understand fully how it works. I see some artifacts I can't explain on the oscilloscope. The effect is noticeable when running with really high speeds and rather low acceleration. For now I use max acceleration, but still there are a few millimeters with intensity that varies if looking too close. I can get the effect to change by - using the same G-code file - by changing acceleration and changing engraving speed. So it is not the G-code itself, it is the interaction during acceleration. It is the same code in Due and Mega so I will see if I can provoke this in the Mega as well. It might not be an issue on the Mega.

[Downunder35m]

I noticed the difference in darkness on the left and right border too sometimes.
Not sure if it can be fully eliminated as during acceleration and decelleration the laser would have to be turned down accordingly.
For critical images I actually prefer to generate a new one that has some white borders on the side.
This way the laser is off during the speed change and nothing happens.
Bit of a hassle for darker pics or 2.5D engravings but so far I have not found a reliable way to add borders through the TT plugin in Inkscape.
Also at higher speeds I sometimes get "hickup lines", either the laser is stuck at a fixed value for a base64 segment creating a dark line or the power it totally off resulting in nothing.
I have the display and SD deactivated for now (don't need them really) but I really think a Marlin version without the 3D printing ballast would help to solve some of the timing issues.

[HakanBastedt]

One thing I noticed is that the movement i Y between lines doesn't happen between lines but in the first G7 move - over a distance of maybe a cm. That explains one part of the look at the edge where I often can see short parts of white lines. There are just a few lines of code in Marlin_main to correct this, have a look here if you want to https://github.com/HakanBastedt/Marlin/commit/e33d2a09bbfe1ee03d91f5dc73e268aee2bb4df4

I can get the acceleration artifacts also on the Mega. But under normal circumstances this should not be so obvious, but you can see it sometimes as I do. It is much more obvious on the Due, so I will have to try to fix it.

[Downunder35m]

I've spent most of last night and today to correct some error I made when changing some lines of code.
But no matter what I did I always had the engraving ruined bacause sooner or later the x-axis would massively shift to the right.
Reverting back to my working copy suddenly caused the same troubles so I supected faulty hardware.
Checking, replacing, double checking, nothing worked.
When I was about to give up I followed all wires as good as I could and found the culprit form the ruined weekend.
Thanks to chinese working and soldering skills one wire of the endswitch was hold in place just by the heatshrink covering it.
So every now and then it would fail and the axis would not move to the left.
Really pays off to question every nut and bolt coming from china LOL

[Downunder35m]

I checked for the white lines you mentioned and can't seem to replicate that problem.
Considering the tiny amount of movement for the Y-axis it should not be an issue unless the speed is really high.
But even then it should not result in white areas.
However, I noticed that the overburn on the edges is due to several things happening.
For starters there is the issue of total black with the interpretation of the base64 alphabet in Pronterface.
This claims to cause a loss in total black but to be honest it looks like the opposite because the slightly lower levels will be the same as all black.
Then (at least in my config) there is the issue of power levels when changing directions.
I tried to confirm this raster behavior during vector jobs and could only notice overburns if there are a lot of tiny sections that slow the movement down to a crawl.
No issues changing directions at moderate to high speeds at all.
Since I am engraving at much higher speeds than my vector jobs I don't think the problem is within the movement itself.
Do an engraving of an image with a added border of about 5mm left and right.
When you get the power levels so that total white barely marks the paper you will see a nice shadow forming on the white borders.
When adjust the min engraving power so that these shadows are gone I still have really good contrast in the brighter image areas but clean white borders.
Doing the same with total black borders results in burnt through holes and marks in the border where the direction changes.
It also seems that neither the acceleration, nor the jerk really affect this.
Only if the speed is lowered quite badly these unwanted affects disappear.
For me and at this stage it makes no sense why the overburn is almost equal from a certain speed upwards.
In some severe cases I can definately say there is a power surge happening during the direction change as I can produce destinct pinholes that have always the same distance from the actual image border.
Already started packing my stuff as I have to move house soon otherwise I would love to see this happening on my oscilloscope in real time.
Not sure if you noticed but when the laser is activated at the beginning of an engraving it also causes a small pinhole on paper if you are on higher power levels and speed.
By using evenly shaded images I could confirm that there is nothing happening to the image levels in the G7 command so the culprit must be within the firmware as a job from SD causes the same issues like a job through pronterface.

If the acceleration is turned down to a crawl the unwanted affects disappear and the overburn at the ends is not worse than at higher speeds.
My current suspicion at the moment is focussed on the buffer handling.
Engraving lines are terminated either by the amount of pixels or the beginning / end of the line in the image.
The buffer is emptied and filled while checking the segment times.
At very high speeds you can see the jerking around of the head when the buffer is refreshed.
It is like a slight interruption in the communication.
Here I can often observe that the distance from a pinhole to the next interruption is almost the same as between interruptions.
Current conclusion would be that despite a bigger serial buffer and deactivated display and SD support there is still a timing issue.
Would love to have a little gadget on the display that shows how much the processor is doing and how the buffer / memory levels are.
I might have to check if messing with the encoding line lenght it would be possible to get better buffering.
I assume that at least over SD the speed should be still fast enough to allow for a length of just 32 or 34 instead of 68.
Smaller segments here should allow for faster access of the buffer as less time is spent reading and writing.
In case this turns out to be much worse I might increase to 80 to check for an improvement.
If that all fails it could be down to the look ahead planner that is not optimised for 180° turns, which are interpreted to be new segments all the time.

[HakanBastedt]

I don't have so much issues with overburn but rather underburn. I spent the
weekend searching for my logic analyzer which I supposedly have somewhere
but I begin to doubt it. But I think I now understand how timings and such
things are.
Some overburn can happen during acceleration. The start of a laser pulse is
always synchronized with a step in X and/or Y-direction. The length of the
pulse is determined from nominal speedrate and is independent from the X/Y
step rate. Yet, the pulse extuingishing only can take place at the
beginning of a X/Y step, so pulse length and steps are dependent anyway.
The pulse can never be shorter than nominal pulse length, but it can be
longer. Normally there are like 20 movement steps between every laser
pulse. At nominal speed the extuingish time is not necessarily exactly at
a movement step, but rather close. When accelerating and at the end with a really low
speed, the problem comes with matching the time to extuingish a laser pulse
with the occurance of a movement step. The time to extuingish the laser
pulse might occur after only one movement step, but the actual extuingish
can only happen at start of the next movement step. Resulting is almost
double the laser pulse energy = black spot. This type of interference
problem do exist for this method.

To change this behavior I would go for changing the method to extuingish
the laser pulse. Perhaps when starting the laser pulse also start a timer
to switch the pulse off. Then the laser pulse length is independent of the
movement totally. There is already some code to extuingish the laser pulse,
I don't think it would add much code, if any, by switching off the
laserpulse that way. Perhaps I'll give it a go in the weekend,

The issue with Y-movement in first G7 block I noticed only on the
laserdiode where I have a really really fine spot. In the microscope I
could follow individual laser pulses on the engraved board and see the
steps in the Y direction, one by one. For me it looks very much better now,
so I think it is a worthwhile change. The change doesn't slow down the
engraving.

[Downunder35m]

I was looking for ways to overcome the high speed issue on another level.
AFAIK the standard motor drivers all use a bang-bang method for the pulses.
Use the highest current possible to get the motor to the next step and hold it ther until the next step is due.
So the critical point is the timing of the steps to avoid resonace but this never works with these simple drivers.
In fact the motor will swing in the position until the next pulse arrives or it comes to a full stop.
After reading some articles on how to manage the timing here I came across this:
https://youtu.be/8_iJ-XGpFvs
Mind you that only a tiny Arduino is used to provide the pulses for these speeds!
It should be no big problem to make a fix for something like that on the Ramps board but I can't find any supplier for these drivers.
Might have to make my own after moving house to test if it is capable of breaching the speed barrier to reach the firmware/CPU limits without always loosing steps or terrible noises.

Will check you suggestions and make some code changes if find some time between packing packing and sorting.

Edit:
Your code change for the L command gives indeed better results but still there are pinholes left.
But I think I found the culprit for them :)
During my tests with the acceleration settings I noticed that we can only adjust the onramp but not the offramp.
So we get smooth acceleration to top speed but no decelleration at the end of linear move.
Which means the bumping sound during line changes is actually the sudden stop to move a line down.
This is quite odd as I would expect the acceleration settings would also take care of the end of a movement :(

[HakanBastedt]

Could be that there is something to be gained with another approach in stepping. Afaik the limiting factor is the Mega's ability to produce steps/sec. I run my laser machines on the "standard 3D-printer" setup, drv8825 drivers, Nema17 motors really in the middle of the road, nothing special. The Mega can do something like 35.000 steps/sec which translates to just over 10000 mm/min at 200 steps/mm. That is exactly what I see on the laserdiode machine that use Mega. On the Due the exact same driver and motors and setup run with more than 100.000 steps/sec. This points to the processor and the code being the culprit, not the step driver and motor. But engraving at 10.000 mm/min is not bad.
Are you sure about the onramp/offramp? I sure can get the head to accelerate up and down reeeally slow like 10 mm/s2. I think I remember that it is the travel acceleration that makes a difference which is a bit odd.
The change introduce a little bump, I noticed that as well.It is distinct now - stop engrave. Move Y. Start engrave. Well, see if you like it. I'll keep it.

I already worked on the pinhole timing issue on the Due. There are plenty of 32-bit timers to choose from so it only took an evening to change the laser firing. I won't say too much before I have tested it. On the Mega i suppose there is one 16-bit timer available - the servos take all timers they can get and perhaps I have to steal one of them.

[Downunder35m]

I was able to solve the pinhole problem, at least for my current configuration.
After some endless tuning on the acceleration settings and steppings I can now reliable engrave at 7200mm/min - did not try any higher yet as I first want to get proper results at this speed.
Of course I had to reduce the stepping to 1/8 but the real clue was to make the calculations easier.
Not 100% certain if that was all and since my firmware settings might not work for you anway try just this:
In the Inkscape plugin change the export resolution the just 254DPI.
gcode += 'M649 S'+str(laserPower)+' B2 D0 R0.1n'
and
command="inkscape --export-dpi 254 -i %s --export-id-only -e "%stmpinkscapeexport.png" -b
"%s" %s" % (node.get("id"),tmp,bgcol,curfile)
Additionally use a high res image as a source like the Billy the Kid one we all know and reduce it to 254DPI and 20% of the original size (if that fits in your machine).
Now let the machine engrave it and check how the borders look and how high you can crank the speed before it gets jerky.
I know your Due is speedy, so you might want to first try this on something slower.
For a diode laser of a low wavelength like deep blue you could also try 508DPI as the next even value for calulations but that would only work for serious speed on the Due.

[HakanBastedt]

7200 mm/min is not bad, that must be okay. It is all good? No odd effects creeping up?

The CO2 laser is being rebuilt for the moment so out of service perhaps a few more days. When I said pinhole maybe that is the wrong term, I am making the laser pulse more precise in length. I assume unprecise laser pulse length can cause pin-holes.

I already had the same mod you show, I have an input field in the Inkscape plugin where I set resolution and it ends up in exactly the code you show. I too think it is beneficial to have image pixel resolution a multiple of the movement step resolution. I sometimes use 1016 dpi when doing pcbs on the laserdiode engraver. Takes forever.

I will engrave with the due in a few days. Interference effects and such things more easily show up on the Due, and it can engrave slow also. Don't bother about me using the due, I will do the same thing on the Mega when it works. It is just easier for me to engrave with the CO2 than the laserdiode.

[Downunder35m]

Ok, thought it was worth to mention but I see you were again a bit faster LOL
How did you include the DPI in the plugin?
For some reason it seems my Python is getting a bit rusty as I always end up with errors when trying to add some form of input for DPI, same for minimum power for engraving, which I would like to include in the M649 command.
But then again I did not reall try too much as I see no problem using two plugins for two fixed DPI values, just an on the fly adjustment for the minimum power would be nice.
At least you confirmed my thoughts on the pulses and that all works better when the movement really matches the pulses.
With the CO2 laser I don't see much real life benefit for 508DPI over 254 DPI as the 508DPI would be already over the pysical capabilities of my optics but for diode systems it is well worth it.
Will do some more tests to see how high I push the max speed without running into troubles.
I guesstimate that around 8300 should be the absolute maximum with 254 DPI based on calculations so maybe 8000 would be realistic.
With the different stepper driver I linked earlier theoretical speeds could go as high as 24000mm/min but I doubt the Mega CPU will cope with the timings, so I am actually more than happy to be able to use 7200mm/min reliable on a Ramps system.

[HakanBastedt]

The code comes later today. It's a line in the Gui file and two or three lines in the py file.
I agree on the resolution for CO2, have not seen really a benefit for 508 dpi there either. For the laserdiode, though, I just yesterday evening used 1016 dpi and yeah it took forever. I am running at 1000 mm/min so no speed records there. The way I use it, a max speed of 3000 mm/min is enough.

The CO2 machine is now rebuilt and I will do some engraving tests tonight with the new laser pulse extinguish method. I am really hopeful there will be an improvement.

The "standard" drv8825 can drive a nema17 motor at least 40000 mm/min.

[Downunder35m]

Yes, normal stepper driver can be fast...
But not powerful or really reliable at the same time.
In the last weeks I learned about timings and pulses and how motor coils are positioned, makes much more sense now and tuning easier.
But don't you think 1016DPI is a bit of overkill?
Unless you are 2010 SMD parts the 508DPI should be sufficient!?
When I worked in the SMD business we had our protype boards done at just 300DPI and never any problems.
The mass produced ones were based on vectors though.

I don't know if you already noticed:
When using proper DPI values there is far less problems with patterns forming in large all black areas.
Also your code change for the pinholes works muc, much better with these coordinated pulses.
First I just thought the pattern is due to the stpper pulses and not to a slight calculation mismatch LOL
Even with SD and display support I can now still reach around 6000mm/min :)
One thing I am still not really happy with is the movement and command buffer.
It works great for complex vector jobs but really comes to the limit during raster jobs, especially at higher DPI rates.
Would love to find way to switch the planner from normal to engraving so that only a few G7 lines a buffered and calculated for straight line movements.
This way the planner can take care of the start and stop at the end of lines instead of just the acceleration and jerk settings alone.
But not really a priority at this stage as the current speeds are more than sufficient for me.

Was thinking of adding a shunt resistor and some code to display the actual current to the laser together with the set power level.
Do you think it is useful and doable directly without adding a lot of protective circuitry?

[HakanBastedt]

Here are the code changes for setting dpi
Line 77 in turnkeylaser.inx
<param name="exportDPI" type="int" min="0" max="5000" _gui-text="Default DPI">270</param>

Line 470 in turnkeylaser.py
self.OptionParser.add_option("", "--exportDPI", action="store", type="int", dest="exportDPI", default="270", help="DPI of bitmaps")
Line 656
gcode += 'M649 S'+str(laserPower)+' B2 D0 R' + str(25.4/self.options.exportDPI)+ '\n'
And the command
command="inkscape --export-dpi " + str(self.options.exportDPI) + " -i %s --export-id-only -e \"%stmpinkscapeexport.png\" -b \"%s\" %s" % (node.get("id"),tmp,bgcol,curfile)

While you are in those files, you can try to change "int" in
<param name="laser" type="int" min="0" max="100" _gui-text="Default Laser Intensity (0-100%):">10</param>
to "float" and see if the decimals come over.

[Downunder35m]

Doh!
Now I feel like I can't see the forest because all the tree are blocking the view!
Sure, why bother with the M649 command if adding it directly into GUI is soo much easier LOL
I doubt the laser change to float will help without reverting the calculations in Marlin back to float too.
Already checked with some line tests to confirm that (at least currently) the decimal values are only used as ABS values with no regards to the digits behind the comma.
Not 100% sure if changing all back to float is worth the hassle, especially if you consider that the base64 calculations won't work properly with float values either.

[HakanBastedt]

It is just the intensity value in M649 Sx that gets decimals in that case. In Marlin the problem is with rasterlaserpower which is a byte(?). Change to float. Don't touch base64.

The 1016 dpi is not needed really, well it is for a stupid reason. I engrave black paint sprayed on the pcb and most of the paint evaporates but some stick back to the copper. And then there will be lines when etching, so I want to get rid of the lines. One way is to run the laser at high dpi.There are probably better ways to do it, but I am ok with this. The pcb came out great btw.

Ok, about testing the new laser extinguishing method. Photo:

https://onedrive.live.com/redir?resid=13918A12FA0E915E!223&authkey=!ACvAr6raE-uZJcg&v=3&ithint=photo%2cjpg
The two engravings on the right are with high/normal acceleration and they come out pretty okay I would say. The one on the left top is run with 1/10th acceleration and it also comes out really good.

But the banding, the two whitish streaks are there, the size and position scale with acceleration it seems. All engravings have them. My best guess is that it is related to switching between acceleration and constant speed. It is not a complete lack of engraving, so perhaps only in one direction? I am guessing. I know I can't debug that before I get a logic analyzer which should come next week.

And the speed gets a hit of this. Before engraving was possible at 27000 mm/min, it is now down to 18000 mm/min, so 1/3 of the top speed is lost.

But all in all I would say this is really an improvement, all interference problems are gone. Remains a whitish strike to look into why it is there. The price to pay is reduction of top speed.

There is also another effect when running with really slow acceleration. Doing one dot. Short pause. One dot. Is different from doing Dot Dot Dot Dot even if the same laser energy hits the material. I wont try to correct that, just note that highest possible acceleration is best.

[Downunder35m]

I guess the high speeds are on the Due and not the Mega? Otherwise I feel the need to shoot me now LOL
I have not done any banding test since the latest mods as I wanted to wait for your results for comparison, but I will run one now to see what happend without adding white borders to the image.
It the banding happeing for you at all speeds or only when running quite high?
In any case the stuff on the cardboard looks nice any clean now.
Let's see what comes out of mine...

[HakanBastedt]

Its on the Due. Hehe...
But it probably have the same effect on Mega. On the other hand it might not. I even thought this method should be faster than original, so I'll stop guessing on that.

I tested with different speed and get different behavior. I got some ideas...

[Downunder35m]

Ok, without adding white orders I still get lower power levels along the left and right edges but only at really high speeds.
http://oi66.tinypic.com/24xq74j.jpg
The left was done at 6000mm/min, the right at just 4200mm/min.
Can only be a timing issue IMHO.
The question is why would the laser power get seemingly down instead of creating a deeper burn due to the lower speed?
When I change the acceleration I can see this band changing slightly too but not really in a way that relates a 100% to the area of acceleration.
Might also be related to the moir effect that happens during 2.5D engraving where you sometimes can see that the laser was off between pixels resulting in a tiny bit of unengraved area.

[HakanBastedt]

I think it looks very good but with weak edges.
6000 mm/min is not bad with the Mega.

I have isolated the problem here, and understands why it happens. There is an overlap with the timer expires to shut down the laser pulse and the reloading of the timer for a new pulse. At constant speed those times are so equal the half of the pulses are missed. At acceleration when there is long enough time between pulses it works perfectly. I'll see what I can do about it.

Edit: I have solved it now. Amazingly enough it helped a lot to read the datasheet for the processor. Actually it seems to be a win-win here, I got most of the speed back as well.

[HakanBastedt]

Now also for the Mega. The new laser_pulse() function for RASTER and PULSED mode works very very well. NO pinholes, extra lines, grayness variations - all gone! And speed increase. Win-win.
laser_pulse() substitutes TT's laser firing method for raster and pulsed modes. The intensity of the raster is set using Timer3 (so far nothing new) and the pulse length is determined by Timer4 - this is new. The pulse length is not anymore coupled to the motor's step movement, it is separately determined by Timer4. Now, as before, the start of the laser pulse is synchronized with the stepper motor but the laser pulse length is always correct. At nominal engraving speed the length of the pulse is such that the pulse is not normally ended, the next laser pulse join seamlessly. The pulse length is normally enforced by Timer4 during acceleration of the head and when the motors stutter for whatever reason. The Timer4 is there always to ensure the right laser pulse length.

The tests I have done show that the engraved picture comes out as good as it gets - no timing-related artifacts whatsoever.

The implementation in my work space - the relevant commit is here - https://github.com/HakanBastedt/Marlin/commit/520aca42b7cba56d58deee9d13d90180394928ed is a significant improvement of TT's laser engraving feature, at the same it is compatible with TT's G-code.

• Quality improvement of the engraving.
• G7 command compatible with TT's Marlin version and TT's Inkscape plugin
• Engraving speed tested at 6500 mm/min at 0.1 mm/pulse and step motors at 200 step/mm with lcd display. Without display 8500 mm/min. This is with smooth movement, without motor stuttering.
• Full Timer3 resolution for the pulse intensity such that LASER_PWM_FREQUENCY*PWM_DUTY_CYCLE = 16000000 is used.
• The code chain keeps full 256 resolution from the G7 raster command all the way to the laser pulse. Run at 100% intensity or 0.1% intensity - 256 grayscale levels are available. You have to match this with proper setting of PWM_DUTY_CYCLE. Full 256 range at 0.1% intensity requires PWM_DUTY_CYCLE=256/0.001 = 256000, thus LASER_PWM_FREQUENCY=62 which might be low. This is the trade-off that has to be made.
• Floating point intensity levels are now supported, like 3.14%
• Pulse lengths in the range 0.5 microseconds - 32.7 milliseconds. Pulse length resolution is determined by the pre-scaler used by Timer4. For me this is right in the middle of my usage - for really long/short pulses one might have to manually change prescaler and do the associate Timer4 tick calculations.

A sample can be seen here. Laser-diode 2W on masonite. 0.1 dots/mm, 2000 mm/min, 200 steps/mm https://onedrive.live.com/redir?resid=13918A12FA0E915E!224&authkey=!AMRJGHUCFfzi-s8&v=3&ithint=photo%2cjpg

[Downunder35m]

That looks great!
I had no time so far to get your code and try it out but I made some progress too.
Remember the patters during engravings I mentioned?
I made them gone together with another speed improvement.
Now I am able to engrave over USB with up to 8000mm/min - with active display and SD support.
Still fighting the power problem on the left and right edges though.
For me the key point was the PWM setting that I never checked and it was still on the default 8kHz.
Changed that to the K40 default of 23.5kHz and most of the problems went away for good.
At around 8600-9000mm/min I get the stuttering due to the timing issues again but I think anything 4000mm/min and above is plenty for normal engravings, bigger sizes however will benefit from the higher speeds for sure.

Not sure if I find the time this month to test your code changes but will certainly give it a try once O have the time for it.

[HakanBastedt]

These are pretty good numbers you have there. At these speeds, and at good resolution, it will work really nice on a 40W Co2 laser.
The problem at the edges must have to do with the acceleration and the way the laser is extinguished. I solved that in the last change.

I asked here it they were interested in adding the TurnkeyTyranny code - with modifications - to Marlin and they are interested. So I will prepare a pull request, and then I hope this takes things a bit further toward adding laser functionality in Marlin. In a week or so the pull request should be available.

[mkeyno]

@HakanBastedt please let us know its link, although this topic initiated to THC feature but I hope its pull request also be available,
by the way, regards to Peter comments on Smoothi , what would be your opening about choosing between Marlin and Smoothi? as you also mentioned, block function in planner tight our hand to control times for another feature such as THC

[HakanBastedt]

I will for sure give a pointer to the PR and I will for sure not comment on Peter's comment.
Regarding the details of the code, it is better to wait until the code is available to actually comment.
If you have seen TT's code well it is almost the same so you can draw conclusions from there at this stage.

[Downunder35m]

If there is one thing I learned so far from this firmware field trip then that the hardware used is only relative.

Sure using an Uno or Mega might not be fancy but for most projects it is more than enough power - if the firmware runs properly.

Using high speed hardware to compensate for coding issues is cerntainly the modern approach but always the right one.

Same for stating that Marlin is dead, if it would be people would not use it and still work on it....
When it comes to laser engraving Piclaser is very aggressive to keep free code limited by leaving bad comments and even spamming threads with their product ads - this alone is enough for me to know that people working on free alternatives are on the right track.

GRBL has its meaning and uses but certainly not for anyone using a CO2 laser unless he is willing to convert all the hardware to match the firmware - totally beats the point of configuring machine settings.
For me part I am glad to have some people still working active on adding laser features into Marlin and the response to my Instructable on the K40 conversion shows that too.

People always love to complain about adding new features to "their" firmware while at the same time adding tons of other stuff all the time.

Added laser functions in Marlin won't harm anyone using it just for 3D printing and so far it is working great.

Show me another firmware that allows the same in similar or even better quality/speed ;)

As for integration and pulls I can only say that if it won't be joined with the main release Hakan should release it as a standalone version for guys with lasers.

I mean what's the point of all this discussion?

Is it about adding features or about not adding them because the people behind don't use it?
TT's plugins are old, outdated and won't work for everyone but still they are the first things to pop up in related Google searches if you ignore the stuff from Piclaser.
So it is neither dead nor unused ;)

And for some people/projects it does matter if the "outdated" hardware is available for under 50 bucks or if you already need to pay that much ;)

Edit: Before I forget, I am now at 9600mm/min @ 254DPI for the engraving speed.
That is with active display and SD.

[HakanBastedt]

Not bad, not bad. Regarding release 1.1.1 was mentioned if all goes well. Don' t know at all what that means in months/years. There is time available to get it right I guess.
I have most of the code intended for the Pull Request running on my laserdiode machine since a few hours. Something has been done with the memory usage, there is a lot more free memory now. The speed is down somewhat but not too much. I reduced microstepping to 1/16 that is 100 steps/mm and tried with 254 dpi. Between 10000 - 11000 mm/min. No lcd, usb. It ran very smooth. Amazing.

[thinkyhead]

what that means in months/years

Version 1.1.0 is getting pretty close. As soon as it's released we can start a branch based on it, add cutting features, and get it into shape for the next release as a disabled-by-default feature.

I think this should be in the main Marlin project as an option, and perhaps even a "switchable" option, because I happen to know there are hybrid machines in the works that would very much benefit from having full printing and engraving features included.

[Downunder35m]

I agree on the hybrids for sure.
Not only new machines but also people adding laser diodes to their existing machines.
Already back when TT started it all there was a discussion on the pro and con of having laser features included - especially the added G7 commands and the handling of laser and normal moves.
For most it was the issue of still activating the laser during 3D printing as the functions are shared.
But I think it should quite easy to use otherwise unused pins for the laser control and to disable laser functions completely in a similar way unused extruders are "switched off".

IMHO a laser dedicated Marlin version with most of the 3D printing features gone would be good for CO2 system, while a properly integrated combo would be perfect for the users of diode systems with intentions to print as well.
Just thinking of possibilities in terms of surface finish with dual system that use laser and print head together would make the efford worth while.
Considering what is now available in terms 32bit processors and touch displays would make me drool if I could afford it all LOL

[HakanBastedt]

Activating/inactivating the laser function on the fly is no problem as such. I have more problems to switch off the 3D printing function, specifically I am forced to use at least one heater. 998 works well for now but is it switchable and is it a good solution? Also in the lcd area there may be choices to be made for example how the main info screen should look like - printing or lasering. Timer3 and timer4 are used for laser pulses, to give the timers back to servos for 3D printing I guess is doable with some work.

[Downunder35m]

Had to do the same with the extruder and so far no issues.
But I also fail to see tha point of having an active extruder if no extruder is present.
IMHO the best solution would if the laser could be defined as an extruder.
Extruder one as default for printing, extruder 2 as default for laser works.
Maybe even based on a simple M command so it can be acivated/de-activated "on the fly".
But here comes all the criticism about Marlin being messy into place :(
I am digging through Marlin on and off now for a long time still fail to see why it has to be so huge and with so many references back and forth through the files.
The LAC stuff so far is no real concern to me as I don't really need a stand alone solution but I agree having that sorted too make sense.

Was also thinking of modifying GRBL to match the machine but it seems there is reason why the developers simply told me to match my machine when I asked for a proper laser support...
But I already thought Marlin is a bit complex, GRBL makes even less sense to me in terms of modifications and additions ROFL
Considering that some modern boards like the Alligator already work on including full laser support The remaining question would be: How to convince people that a cheap 8bit board is still enough for 90% of the time....
Right now it is like the race for PC's: Why bother with my slow hard drive, I just buy a new computer...

I had a quick look at your code changes, can you explain the thing with the PWM_DUTY_CYCLE a bit more please?
Especially in regards to the laser PWM frequency.
If I go below 15kHz here the laser struggles, so I use mine at the default 23.5kHz which the original controller would have provided.
With 62 do you mean 62Hz for the PWM? That would certainly not be good for a CO2 laser and very noisy LOL

[thinkyhead]

IMHO the best solution would if the laser could be defined as an extruder

Well, a "tool." I think we're moving in the direction of Marlin "thinking" more in terms of "tools" than "extruders" and being a little more abstract about the capabilities of different "tools." Opening up options for ink pens, cutting tools, lasers, etc.

[HakanBastedt]

What I really would like to see is other firmwares also adopt the G7 raster engraving. It has its clear benefits both you and i have discovered. Wider acceptance means better support for this engraving method in tools and better engraving results hopefully = win for the user.

Yes in that example it would mean 62 Hz. It was a stupid example.
With regard to PWM timing, this is how I understand things. The shortest time the Mega2560 can produce is one "tick". There are 16000000 "tick" per second = CPU frequency 16 MHz. One "tick" per CPU cycle.
You want to use a PWM frequency of 23.5 kHz, so these 16000000 ticks are divided in 23500 pieces with each 680 ticks. 680 is your pwm duty cycle. At 23.5 kHz you can have less pwm duty cycle, but there can't be more because there simply isn't more than 16000000 available during a second. So 23500 times every second a new PWM pulse is generated and the length of every pulse is between 0-680.

Made some engraving tests today on the laserdiode
https://onedrive.live.com/redir?resid=13918A12FA0E915E!227&authkey=!AOlEfIaSHtMPMGE&v=3&ithint=photo%2cjpg
The three with the same fish are run with my 2W laser at 10000 mm/min, 4000 mm/min and 2000 mm/min. The diode isn't powerful enough for max speed. The odd fish is run at 3000 mm/min.
All at 254 dpi, 100 steps/mm. What is important I think is to note that the edges look just right.

[Downunder35m]

Ok, this might get a bit longer...
I tried in a few places to "promote" the base64 encoding and use of the G7 command.
Let's just say the result was similar to trying to place an order for ham in a muslim restaurant...
It seems that most coders are quite proud of their work and overreact to feature request that seem to have no relevance to their project.
Best example for is GRBL where we are told to match the machine to the firmware LOL
Currently most of these diode laser toys on Ebay come with GRBL or some homemade creation of sorts.
Promotion is the best to get attention!
We need more Youtube videos to show off what we can do already, with links in the description so people who watch it can come and join the club so to speak.
I will give GRBL another try in terms of modifying it for the use on a Mega with my CO2 laser.
These K40 closes seem to be standard and share the same hardware config no matter where they come from, so ahould be as good as any..
But even if that works out and without thinking of the G7 problem it already it also get's complicated as there are no proper programs or plugins for our purpose.
Sure some already work on implementing basic laser stuff but as usual based on Fans and simple on off control.
We need something similar to the TT plugin to work with GRBL.
A program or plugin that allows us to define raster and engraving jobs under one roof.
Nothing is worse that creating a raster engraving with one program and then trying to align everything 100% to do the vector job.

For the tools I agree, makes more sense than extruders as in the future will we see much more things here, like paste, clay, wax and so on.
But we are also again at the point of decision.
So far all Marlin releses had a pure focus on 3D printing.
If we want to up the bar than we need to agree on "features" or "tools" to be selctable.
Maybe even in the form of a new config file that takes care of all hardware relevant things.
Currently all this is only done through the board definition an results in fixed pin configurations.
It might be good to be able to allow for changes here so for example:
Pin 5 is used by standard for an extruder fan.
In the config the user can list pin 5 and set it to an unused pin or declare that Pin 5 is now used to switch the water pump on and off.

Now with your explanation it starts to make sense :)
Now I only need some time and a clear mind to implement the changes for some tests.
Hopefully the last question until I actually start testing it: How does that work now with pulse definition in the TT plugin?
I mean with the pulses per mm setting? Any conflicts at higher speeds with a PPM value of around 200 for example?

I notice in your pics that you have these fine lines in the engravings.
Mine disappeared at some stage, so I was wondering if that is due to the sharp focus of your diode or maybe a thing of line spacing?
Don't know you spot size but if it is that much smaller than the actual pixel size you might need a higher resolution.
With the "massive" spot size of cheap chinese CO2 lasers I don't really have that issue unless I do really deep 2.5D engravings.
Did you ever consider to modify the buffering for the Mega?
I run with a serial buffer of 256 but still struggle to set higher than standard values in Marlin is the whole thing becomes instable and unreliable after that.
My aim was to optimise the buffer for the length of the G7 commands so that a decent amount of them can be stored for the planner.
Which brings me to the next culprit spoiling our fun: The y-move between lines.
I tried to compare the movements of the laser with similar patterns on my 3D printer and noticed the laser works really different for the directional changes during a G7 move with a Y-change.
Of course it works similar when you create corresponding vector files.
During a linear G7 move the planner makes good use of the accelleration settings and realised there is no stop or speed change required (until the speed is too high for the timíng).
When we change y this goes all down the drain.
There is bug somewhere messing with the planner.
The distance to travel is short enough to fall within the Jerk settings but they don't affect it all.
Instead the axis is always taken to a full stop, then y is moved and it starts again in the opposite direction.
If you the dragon from the TT plugin at a quite small size you notice a similar behavior with the vector moves too.
Extreme short moves force a dead stop.
So I am not 100% if it just distance related or a real problem with G7 in the planner.
But if it is fixable it would mean even higher speeds and no more dead stops - which I hate as they mess with my engravings and cuts LOL

If you mainly use wood for your test engravings:
Dissolve some sodium silicate (silica gel, crystal cat litter) in boiling water, about a table tablespoon per cup of water.
Use a brush and apply a thin coat of it on the wood.
You can speed up the drying by mixing some methylated spirit in it.
Once dry your engravings should turn out much darker and with more contrast.

[HakanBastedt]

Can't really blame other developers, they have their focus and priorities. Me too. At least they now know about the raster engraving option.

I am not sure I understand exactly what you see with the movements. There is a small change made to really small movements, during 3D printing very small movements can be combined into a larger movement, perhaps that is what is seen. TT removed that shortcut to have the head moving precisely. Also TT absorbed the Y motion into the first 51-pixel block on the next row. It didn't look ok so I changed that to engrave - move Y - engrave. There is a small "bump" when the Y-motors go forward. Is that what you see?

There are no changes to the Inkscape plugin. For convenience I have added, like you did, the option to choose engraving resolution, and the intensity level. All G-codes remain the same and are 100% compatible with TT's original work.

PPM. For 200 ppm which is more dense than the stepper resolution in X than the laser pulses will act as an extra axis and determine the internal step length. Normally the axis that need to take the most steps during a move determine the step length in time, now it will be the laser ppm that determines that. And that should just work.
PPM pulses should not normally be a problem. There is a choice I made that can be discussed and that is the resolution of the length of the pulse. It can now be between 0-32 milliseconds on 0.5 microsecond steps. The 16-bit resolution of the timer, well it would have been better to have a 32-bit timer. The same goes for the length in time of a laser pulse during engraving, max 32 milliseconds. Easily changed, but is there a right value? The user will change between long pulse/short pulse?
Also pin 5 is hard coded for the moment. It is possible to choose between 6 pins if considering timer3 and timer4. Easily done, but how to handle that? Options in config?

I did test with larger buffers and I think it helped a bit. But it took an awful long time to interrupt a job, so right now I haven't changed buffers from default sizes.

I have seen the lines, I get them a lot. Always thought it was something with the laser spot. I usually don't engrave like this, it was a test to verify that all was well in the code. I'll test with silica gel if I can find some.

Here is a link to the code if someone wants to test. It follows the current RCBugFix branch here. https://github.com/HakanBastedt/Marlin/tree/laser

[Downunder35m]

Ok, the stop with y-axis might be expainable and I understand that it is better this way than what TT did.
I think what mean with the problem is the simple fact that this move seems not be considered in any way for the planner.
So instead of moving on with the max possible speed based on acceleration and jerk it all comes to a dead stop.
IMHO and if the moves are considered correctly in the planner functions thenit should be an almost smoth change from one direction to the other.
Can't be from your code changes as I noticed the same already with the TT code.
But not too worried about this little bug anyway;)

And I guess I understand now how your stuff works with the pulses and timing - thanks for the additional explanations!

As for the lines: Do you get them the same way in higher resolutions as well?
I think it is related to the spot size together with the engraving resolution.
After all, the max power is in the center of the spot, with the power decreasing to the outside of the spot.
On my CO2 system it forms more like an oval or olive insteaf of a round dot.
And as luck has it this oval is amlost 90° to the engraving lines, so I have some overlap if you like to call it that.

As for the sodium silicate: If the wood is quite soft or soaks really well you don't want to use it if you need cuts too - if the amount of silica get's too high even my CO2 laser struggles to cut through 3mm plywood.
But if some experimenting with speed and power is to your liking you should be able to max out the speed with your diode system, at least for photo engravings.

[HakanBastedt]

Does the movement look a bit like this?
https://www.youtube.com/watch?v=O494kbtoX84

Edit: Added a second video to show a test with really low acceleration.
https://www.youtube.com/watch?v=ppNvOaiu3ko
I would say this worked pretty well.

Got cat sand made of silicate sand. Didn't dissolve very quickly. I'll let it soak over night.

[Downunder35m]

It looks like it could be similar.
If I am not mistaken I even hear the little bumping at the end of lines.
Got rid of the bumping (most of it anyway) but would love to know why the directional changes are not counted for in the planner calculations for the movement.
If I manuall change the Gcode to let's say 3mm between lines the movement is much smoother.
Then it looks almost like the head is not even fully stopping but cracks the corner with a bit of speed.
As said nothing that really hinders the working of the machine, just the little extra to make it really smooth ;)

I had similar issues with the cat litter of my last batch.
Turns out if the crystal look pale white they are already cracked, nice and shiny crystals are not.
The later take forever and a bit to dissovle, I used boiling water to speed things up.
Only good thing is that you don't have to worry about the stuff drying hard as hot water always dissoves it.

Started to play with some new air assits nozzles I printed out, well until my extruder decided to drop the grub screw that is now nowhere to be found LOL
My aim was to find a design that allows decent work with just a fish tank air pump instead of the fridge compressor.
Being lasy with simple prototypes that go in the bin anyway I left two layers of plastic on the underside so the laser would need to make to hole in the right spot.
The last one was a bit too long and only had about 1mm of clearance to the surface but this one got me thinking during the testing:
I noticed (at least with the compressor) that cuts look much cleaner and seem to go deeper in the first pass too.
So I replicated the action of an industrial laser cutter and added a dot to the Gcode for the box to cut out.
Laser would fire at 20% and basically just burn a hole through the ply with full air assist.
Now, when the box is starting to cut the cut goes all the way through in a single pass, although I had to reduce the speed slightly for that.
A test with a shorter nozzle was no success here.
I think for cutting thicker wood it could be beneficial to have hole function added somewhere in the plugin.
To prevent eccessive burning of the actual cut maybe 2 or 3 mm away from the start of the first cutting line.
Only problem is that I really see no way of defining this in Inkscape.
Bitmaps and vector graphics are recognised and it seems there is nothing else that could be misused for the plugin to recognise a hole shut be made.
Will do some more testing next month assuming that I find a new home by then.

[HakanBastedt]

Yes there is a bump and it can clearly be felt when I keep a finger on one of the Y belts. The bump is from the Y movement. I can do a comparison with and without the separate Y movement to see how big the effect is now. How exactly do you change 3 mm? I can hopefully duplicate here. I tend to think in principle the right thing is done. The Y motors can not start before X is totally stopped, otherwise their would be a rounded corner. The axis run at 8000 mm/s2 so the Y movement is a bit violent and takes only some 7 milliseconds.

Hadn't dissolved a whole lot during the night. I'll start crushing the sand into dust tonight.

Inkscape is largely a mystery for me, although I find my way around to do the necessary things. What about looking at how the TT plugin picks up the geometry of a circle, add a short line inside the circle that connects to the beginning of the circle, group that and hope for the best. I guess it just means a circle will be made and after that comes a line LOL. I can forget cutting with the laserdiode, well perhaps paper and similar but it is really not any good for cutting.

[mkeyno]

hi @Downunder35m, @HakanBastedt , glad to receive to your both comments about enhancing the features, however as I discussed with Haken one reason that should move to ARM core board is the missing capability of AVR core to prioritize the different interrupts as the other modern cores does.
Many talented programmer usually, sequence the tasks and calculate precise timing for handling those, and I saw how deep they go to get through it , but in ARM core you can simulate multi-threading like Windows , and get over of this hard timing process, I think with Marlin on Due we could do much enhanced feature compare to Mega5260 , also I find following fascinating library for Due board that suggest to look at
https://www.arduino.cc/en/Reference/Scheduler

[Blue-Marlin]

@mkeyno
Multitasking a la Windows is exactly what we can't use in Marlin. We need a real time operating system - at least for the time critical parts.

[mkeyno]

@Blue-Marlin I don't mean the exact term which is happened in windows because in windows we have threads while in real time OS we have interrupts ,I've just to emphasize , how good the prioritized interrupt is and can save lot of works , I've had experience in autopilot with XMEGA core long ago when we should check signal control and concurrently do PID loop , we did it so easily with prioritized interrupt whereas we weren't pro to do precise timing with ATEMGA core, my idea is while in Marlin we have to do timing for pulse and serial , add the extra event-driven feature like THC would be much easier with prioritized interrupt

[Downunder35m]

@HakanBastedt the 3mm were just added with an additional G1 move :(
But I get your point with the movements, might have to tweak the y-axis a bit to overcome the bumping.
Seems the actual culprit is the fact that the line change is not considered in the planner as a fast move because it is too short and would otherwise cause lost steps.

@mkeyno I do get the point of using modern controllers but simply fail to see why they would be required for a "simple" laser machine.
GRBL lacks the flexibility and G7 commands but is otherwise a happy comper on a simple Arduino UNO.
Might just a personal thing but I think the game should be to optimise code to make it work and not to use hardware that is totally overpowered.
Marlin has come a long way but it still is overcomplicated and with just too many things active by default that noone uses.
On every corner you find float calculations because it is convinient, despite the fact that a lot of them could be completely avoided if the corresponding code would be adjusted.
The focus is again on features and ease of coding instead of optimising.
And let's face it: 32bit proccessing would only be required if you do have a lot of features like touchscreens but there should be no need for it just to move 2 axis and firing a laser - no matter what.
I can get a the entire hardware based on a Mega for around 50$, this includes everything required.
For a proper 32bit board alone we are looking at over 100 bucks already.
If I would plan a nice 3D printer with laser support then I certainly would go for 32bit but not for just a laser machine, it's just overkill.

[thinkyhead]

On every corner you find float calculations because it is convinient, despite the fact that a lot of them could be completely avoided if the corresponding code would be adjusted.

We love PRs to address such things. Love them.

[HakanBastedt]

@Downunder35m ok, in that way. I'll give it a try tonight.

@mkeyno well Mega doesn't have prioritized interrupts, and it works well as it is. I did look at the concept in the data sheet for Due some time ago but felt how my brain started to melt so I had to stop. It is not for me.

I looked yesterday at testing the pulsed laser mode. There are two settings that both need to be set: pulses per millimetre and laser pulse duration. To get this right the feedrate need to be considered, in the same way as in the G7 pulse length calculation. But I have a hard time thinking an average user is able to get this right. At least I can't without a calculator. So I will modify wherever the laser pulse length and pulse per mm are set, 'L' and 'P', so if only one is set, the other is calculated. Aah, and if the feed rate is later changed, then what? Guess laser pulse duration need to be adjusted. So the laser pulse length can really first be decided uhhm in the planner from feedrate and pulses per millimetre.

Edit: It should be enough to do the duration calculation at the time of receiving G0/G1/G2/G3 command.

[mkeyno]

@Downunder35m I'm surprised how to get the Due board this much , mine buy the Due only around 8$ from china and with other supported IC, PCB, connector ,.. and shipment never wont get over 20$, and its not different to choose Mega, also I know control the 2 axis CNC laser wont be hard but I open this topic for feature like bind the 3th axis with feedback loop function for cutting tools (laser, plasma,..), I looked around and investigate couple of firmware on Due and find ambrop72 & Hacken repository , I tested both firmware and very promising for cutting machine but the Aprinter not Arduino compatible and Ambrop72 not really interested to join the topic, I was hopping Hacken not give up and received more hands on his amazing project

[Downunder35m]

I was not talking about the DUE.
The Due can already be considered quite old and never really got great support in terms of shields and such.
And I meant complete: Controller, display, SD support, stepper drivers - add all that and the due comes a bit higher than 20$ ;)
Sure there are many purpose build boards out there on a 32bit base but trying to get your hands on them is not always easy.
I looked into all this before deciding on the Mega and trust me I read a lot and tried a lot in terms of actually getting some of the nice things I found.
Might be a few more years until we see how many boards actually survive and will stay available...
Aprinter looks quite nice so far but not sure if I will join the project.
I might give GRBL1.0 a try and see how well I can modify it to run my laser with it.
In case that works out there will still be the G7 problem as I simply fail to see why this should be done with an endless amount of G1 commands.
In the long run I think it will come down ease of use.
Nothing is worse for a new user than actually learning how to get results.
With simple to use plugins or better still printer drivers things will change.
The approch of some coders to write an entire application for all this is not bad either but they are all still in the early stages.

[ambrop72]

Hey all,
Aprinter currently has very basic laser support, which essentially means it will drive a PWM output at a duty proportional to the (real-time) speed. You specify the desired "energy density" in the gcodes; more info is in the readme. If anyone needs something else (maybe a laser-on digital output - that's easy), please ask me about such a feature, and also specify as precisely as possible the specs as far as software is concerned. Depending on how complex it is I may be able to implement it myself else just provide guidance. Please understand that I have no intrinsic motivation to implement complex laser-specific features - I don't have a laser cutter or anything.

I consider "Arduino incompatibility" not as a problem but a feature. I honestly don't care about any of the Arduino software because it is aimed to quick-and-dirty prototyping not professional programming. And you don't need the Arduino software to write code for Arduino boards, you just need to write software that can run on these boards.

[HakanBastedt]

@ambrop72 I like the approach you have with energy/distance. That should give a predictable blackness of the material no matter how fast/slow the head goes (inside possibilities of course). If I understand right, your laser mode is comparable to the pulsed mode here. A bit different implementation it seems but the end effects is the same. I have so far not used the pulsed mode myself, I either cut with "on"/"off" or engrave. For anything where not full power is wanted I think pulsed mode is the right thing. How are users normally exposed to the laser power setting? i mean manually in the G code or via some tool that generate the code?

@Downunder35m This is what my machine sound like when extra 3mm Y movement is inserted between every line. Not the prettiest sound, I would reduce acceleration if I were to run in this way often. I tested with 1000 mm/s2 (video is 8000 mm/s2) and the motion is already much more pleasant. It is very clear that the X axis stand still while moving in Y, but I can't image it can be done differently. https://youtu.be/vT9Z62FXj70

[Downunder35m]

I already said not to bother too much with it ;)
Considering the speeds involved I think it is pretty close to what can be done anyway.
Was more worried it is a problem with my setup, so thanks a bunch for the testing!

Had a look on how the speeds are done with proper machines and it seems for pure engraving machines DC motors are the way to go.
Works silimar to those in out inkjet printers with an encoder inside the motor.
At least from the videos the speeds they reach look insane.
On one website it was mentioned that stepper motors are not suitable for these speeds anymore as it is very hard to get pulses for the motors right.
That got me to any abandoned project about highspeed stepper drivers.
The guy who started it was able to run a normal Nema17 at over 2000rpm with really impressive speed up and down times.
His trick was to use a driver board with a little processor.
When a stepper motor works the coils produce as current when the motor jumps to the next coil(s).
This is used as a feedback to place the pulse for the motor always right before the swing hits the dead point.
Due to this way of driving the motor there was no reduction in torque at higher speeds and no problem at all with lost steps at any point.
Quite genius approach but sadly with no code or anything offered since the project died a few years ago.
But it got me thinking:
If we can find a suitable driver chip that allows for this current sensing and use a tiny arduino...
Something like a computer controlled stepper driver.
Will try to find more info on the driver chips used assuming that 5 years should have been enough for some company to provide a complete chip for this purpose.

@ambrop72 I should have more time next month and if you want I can do some testing for your laser functions assuming I can get the firmware to accept my current hardware configuration.
As for the implementation of other laser functions and commands the Turnkey stuff is actually quite good documented and most of it should be relatively easy to implement if you check how it was done in Kimbra.
I could not make full sense of the power settings from the readme but will check it next month on the machine if I can.
One thing of a concern for CO2 systems would be change in the PWM frequency as they are meant to be used with around 20kHz.
Pulse width changes are no problem at all as this is they way the power is controlled anyway.
On most chinese systems this power regulation is actually analog.
So by reducing the PWM amplitude to let's say 4V instead of 5V the power will be reduced as well
And I do get your point about adding laser functions but IMHO it should be considered as laser engraving and cutting with CNC machines like 3D printers or routers will become more popular.
Since you already started a nice new approch to the power problem I would really like to see it grow ;)

[ambrop72]

I've updated the info about laser control in my Aprinter README, with an example. If someone needs help setting up Aprinter please let me know.
@HakanBastedt: I'm not aware of real users using my laser feature :) You'd have to provide the right gcodes to the firmware, maybe if your tool cannot generate what it needs, make a program to translate it.

[nextime]

@HakanBastedt i've added your patches to TT even on MarlinKimbra, thanks for that, just cause i've not yet well tested them i had added a configuration switch to choose between the "old" TT original implementation and your one.

Also, if anyone is interested, on my patch to MarlinKimbra there is the code to manage to drive a cooler for the water on CO2 lasers, managed as opposite as heaters using soft or hw PWM, and the support for a flow sensor.

https://github.com/MagoKimbra/MarlinKimbra/pull/113

[HakanBastedt]

Aha, head to head comparison, interesting! I think the two methods overall produce the same engraving. The areas where there might be differences

• engraving quality at the edges, especially at less than max acceleration
• at reduced intensity say S10, check that number of greyscale levels are not reduced
• and max engraving speed.

I added the last changes from TT for the LCD - it kind of ruins the niceness of the code, which is a pity. WIth this change I don't see I will do much more on the code, more than keeping the giant commit in sync with RCBugFix. Here it is for anyone interested: https://github.com/HakanBastedt/Marlin/commit/150a86976dd51ffa396cda5ef1fd5b712d04d0a7

@nextime if I remember right you offered early on to create a Pull Request for the laser functionality we now discuss. Actually, I personally prefer that you, or another developer, do the Pull Request when the time comes for it.

[Downunder35m]

I tried to give the versions a quick test.
First I tried Nextime's version and there are two issues.

1. The laser fires at full power when the machine is turned, only stops when the USB is connected - not good for the laser tube and operator.
2. When I activate the new laser method with #define LASER_PULSE_METHOD then nothing fires at all, commenting it makes the original work again.

For some reason I am not able to download anything complete from HakanBastedt's changes, so that will have to wait until I can implement them myself sometime next month.
Or did just miss the obvious again for the download?

[HakanBastedt]

I think (hope) this should give you a zip file with all the code with the latest changes https://github.com/HakanBastedt/Marlin/archive/laser.zip

The thing with the laser on at power up I think it is like this. During reset all Megas pins enters a high-Z mode with a floating voltage and your power supply interprets this as "high".

@nextime I see you have a few revision old code. It is better you use the latest, which is stable inasmuch as I don't plan any more work on it.

[nextime]

@Downunder35m uhmm, never disconnected the usb :P anyway, it's probably cause the laser fire on down? so, a pullup is needed to avoid that, in my case there is no issues as i have the "laser enable" down until i start a jon, but indeed is something to be worked on...

With LASER_PULSE_METHOD it use the HakanBastedt code, but there is something wrong somewhere probably in how i've ported it. I will debug and fix it in next few days.

@HakanBastedt yes, i plan to update it soon and also better debug it as it seems won't work well actually.

[Downunder35m]

That is exactly what I love about Github, people actually care and work together :)
It is not a really big deal that is does not work as planned at the first try - I can't even count how many time I tried until I got what wanted to work LOL
If you two can agree on how to merge the two than all should be well and good, and I am willing to do the testing on my machine as it seems there are not too many people actively trying on these chinese lasers.
Sadly I have to move out by the end of the month and so for nothing worked out to find a new place.
If worse comes to worse I will be offline for while until things are sorted, which also means I won't be able to join here, but I will be back as soon as possible :)

[HakanBastedt]

I added the G7 raster function to LaserWeb2. Haha but I have been blocked from that repository hehehe, wtf? And I had a tip to speed up the rasterizing of images by at least a factor 40, but ok never mind.
I can put a copy of LaserWeb2 with the G7 additions and speed increase for anyone that want to test with the G7 laser raster function. The status is that I have just got it to work, don't expect a whole lot.

[Downunder35m]

Well I am always happy to test new things and programs especially if this help the person offering it.
But I am not too surprised about you being blocked out, I had some rude experiences with them myself when I offered some code changes.
To me it seemed like thing not coming from the developing team are treated like someone would not like Laserweb at all instead of being happy people want to use and impove it.

[HakanBastedt]

So after a bit of tinkering, the LaserWeb2 version with G7 raster generation is available here http://hakanbastedt.github.io/index.html The software shows more promise than maturity imo. This was an exercise in how difficult it was to add G7 generation option, and it wasn't particularly difficult.

[HakanBastedt]

Tested the pulsed mode and found a bug, it is corrected in my repo.
The pulse mode seems to be a winner - when engraving black &white like pcb masks. For photos G7 is best. I tested at 15000 mm/min which was a tad to much, but 12000 mm/min was no problem except that the whole laser started to shake due to the fast movements.

For pulsed mode any standard laser tool using g0/g1 can be used, they output lines like
G1 X200 Y100 S100
and this is understood by the laser mod. To set up pulsed mode a line
M649 B1 P30
is needed, B1 = pulsed mode, P30 = 30 pulses/mm which is quite dense but well why not?

As a final note, the LaserWeb folks have now adopted me and I will do some work on that tool and will of course make sure that also the new laser mod here will work with that tool.

Edit: it is not black&white that is important, what is important is that intensity doesn't change every pixel. When multiple pixels can be combined into a little longer line with the same intensity, then pulsed mode is good.

[Downunder35m]

Will have some spare time next month after moving house, so I will do some testing on my modded K40.
If there is anything you want checked in detail or require a detailed feedback let me know and I will make sure to check what needs testing.
Should be back up and running somewhere around the 15th of June, hoping that won't be too late for you.
Can't wait to see the differences and also think Laserweb is a good base to use for most jobs out there that can be done with out home made machines.

[HakanBastedt]

There is nothing that can't wait until you have settled and have the K40 in its own room in the new house.
I am kind of just waiting until it is time for a Pull Request. I ran the laser diode the other day and I am quite happy with how well it works. I use the space here a bit like a blog and write some thoughts and findings for the moment.

About LaserWeb, I think it is good to have an alternative. Inkscape and the plugin works fine, and Inkscape is a million times better on manipulation. But I hear some drawbacks like impossible to install due to python issues. The learning curve is, well, there. A lightweight tool where the image/dxf/pdf/etc can be read in, converted and sent to the laser is what I many times prefer. And browser based, which I now think is great, was quite skeptic first. At this point LaserWeb is unable to work on large images like a HD photo, it uses up too much memory at display of path. I am working on that and have already a quite acceptable version at home. I think that after this weekend I can push the changes back to LaserWeb. I will not have a snapshot or so to test, when I work with the code it changes every minute.

[jbrazio]

Closing due to inactivity.
Please re-open this issue if still valid.

[thinkyhead]

I'd like to keep this topic alive, because some modders would like to keep in the loop, and I feel we should accommodate the use of Marlin with more kinds of tools, where we can.

[Bob-the-Kuhn]

I'm hoping to see one of the Marlin branches implement a couple of commands that come in usefull for CNC milling.

The SketchUcam plugin for SketchUp sometimes generates G02/G03 commands that use the radius syntax rather than the IJK syntax.

Setting the machine workpiece origin would be much easier if the G38.2 command was implemented.

For details see the following issues

• Feature request: add ability to use G38.2 command (CNC) #4677 https://github.com/MarlinFirmware/Marlin/issues/4677
• Feature request: add ability to use radius format of G02/G03 commands (CNC) #4676 - this one has example code attached. https://github.com/MarlinFirmware/Marlin/issues/4676

Bob

[HakanBastedt]

If you are doing CNC milling, at least on short term I think your best bet is to look at for example grbl which has these features and more. Marlin miss more things that are useful for milling, such as G54 coordinate system, tool compensation, arcs are only in X-Y-plane, spindle speed and more.

[Bob-the-Kuhn]

I’m just starting out with a small machine. Right now Marlin does all I need.

That may change as I do more projects.

The G38.2 is a convenience item.

The radius item was a requirement until I got my Excel macro running properly.

[HakanBastedt]

You can try with G30 - single Z probe - to see if that does something similar to what you want.

[Bob-the-Kuhn]

The code to implement G38.2 and G38.3 commands has been uploaded to:
Feature request: add ability to use G38.2 command (CNC) #4677 #4677

Bob

[thinkyhead]

The code to implement G38.2 and G38.3 commands has been uploaded to:

Please submit a PR so we can review it properly.

[Bob-the-Kuhn]

Pull request 4845 was just created to implement the G38.2 and G38.3 commands.

https://github.com/MarlinFirmware/Marlin/pull/4845

[boelle]

@thinkyhead has PR 4845 been reviewed ?

[Bob-the-Kuhn]

The G38.2 and G38.3 commands are now in the RCBugFix branch.

PR #4900 merged the code into RCBugFix on 1 Oct.

[thinkyhead]

I've added M450, M451, M452, M453, laser, pick-and-place, and foam-cutter support to Marlin in my MarkerArm branch. That will be published officially once the MakerArm is completed and released.

[martindb]

I would like to use new G38.2/G38.3 features with my mpcnc. There is some documentation about it (connections, gcodes, procedure) ? I've arduino mega + ramps 1.4.

[Bob-the-Kuhn]

The only Marlin documentation is in the Marlin_main.cpp file. Pretty sparse.

A good video to get the basics is this YouTube video.

You can specify any (or all) axis in the command along with a feed rate.

I use a touch plate from Triquetra. They have a lot of info on their website plus there's YouTube videos covering it (example:).

Here's the gcode I use for zeroing to my work piece when I'm using a 1/8" end mill. It was generated by the Triquetra tool and then fine tuned.

Bob

G92 X0   ; set current position as 0,0,0
G92 Y0
G92 Z0
G21      ;  use millimeters
G38.2 X-50  F1000   ; move in -x direction a max of 50mm, stop when Z_MIN activates
G92 X51.8           ; set current postion to touch plate X offset
G91                 ; go to relative coordinates
G0 X12.7            ; back off from the touch plate
G91 
G0 Y50              ; move far enough along Y to be past the touch plate
G91 
G0 X-25.4           ; move over enough that you're sure that the Y probe command will make contact
G38.2 Y-50   F1000  ; move in -y direction a max of 50mm, stop when Z_MIN activates
G92 Y51.725         ; set current postion to touch plate Y offset
G91 
G0 Y03.175          ; get into position for the Z probe
G91 
G0 Z24.05
G91 
G0 Y-15.875
G38.2 Z-25.4   F1000  ; move in -z direction a max of 25.4mm, stop when Z_MIN activates
G92 Z20.4             ; set current postion to touch plate Z offset
G91 
G0 Z3.175             ; back away from the plate
G91 
G0 Y25.4 X25.4
G90

[martindb]

Thank you Bob.

[TGit-Tech]

I ran across this issue while looking for ways to use Marlin on a CNC mill; and it got me thinking.. So I figured I'd waste everyone's time and share my own personal thoughts on what I'd read going through this discussion :).

For me, the benefit of using Marlin is its up-keep, trust, and abilities. Coming from GRBL and not being too impressed led me into thinking about a Marlin based firmware. That said; support for laser and milling as a base part of Marlin would seem to complicate it severely making the thing I love about it harder to obtain ( up-keep, trust, and ability ).

It occurred to me that this is the very reason for code abstraction/libraries and along that basis; perhaps the best solution would be a effort towards a structural layout plan for a sub-component set Marlin API/library.

If Marlin had a standard interface to major components like an XYZ engine, a G-Code Engine, etc.. etc; then I was thinking the mill, laser, and 3d printing top layer implementations would become more feasible. For example;

// Add laser support

if defined LASER_SUPPORT

include laser_support_file which overloads the 3dPrinter_support.cpp

instead of #define LASER_SUPPORT
In 3dPrinterFile.cpp

if LASER SUPPORT

adhoc code

endif

I guess the point of this blabber is to steer away from using #defines to add/modify machine differences code blocks within a class and implement them by overloading just that class that makes it special to the machine -- Changing into a #define -> #include implementation with a universal '.h' API. Anyways, just wanted to share that thought with those involved.

[Roxy-3D]

It occurred to me that this is the very reason for code abstraction/libraries and along that basis; perhaps the best solution would be a effort towards a structural layout plan for a sub-component set Marlin API/library.

If Marlin had a standard interface to major components like an XYZ engine, a G-Code Engine, etc.. etc; then I was thinking the mill, laser, and 3d printing top layer implementations would become more feasible.

Yes. At a higher level everybody is in agreement on these thoughts. If you compare the current Marlin code base today with a year ago, you will see a lot of progress on these points. And if you look at topics such as Object Orientation you will also see significant progress when you do the comparison. Also, we have on going efforts like trying to move Marlin to a 32-Bit platform. When you examine the work that is being done, much of that effort is drawing a clean line between the different hardware platforms and the lower layers of the software via a HAL (Hardware Abstraction Layer).

But the use of #define's allow a lot ability to selectively compile in (or out) different code blocks to match the user's desired configuration. To eliminate the #define's would be a total re-write of the firmware and I don't think that is going to happen over the next 6 months.

As the various interface layers get better defined and more stabilized, your approach of overloading class members will probably work. And we already are well along on turning different code blocks into objects.

[thinkyhead]

M3 / M4 / M5 for laser / spindle is in the works at #6268, but it's a separate and independent function rather than part of a multi-tool system where you can switch tool modes. However, that is something I'm working on for MakerArm at this time. I have also been tasked to implement the following CNC GCodes:

G10 L1    Set Tool Table Entry
G10 L10   Set Tool Table, Calculated, Workpiece
G10 L11   Set Tool Table, Calculated, Fixture
G10 L2    Coordinate System Origin Setting
G10 L20   Coordinate System Origin Setting Calculated

G17       Select Plane XY (default)
G18       Select Plane ZX
G19       Select Plane YZ

G38.4     Probe away from workpiece, stop on loss of contact, signal error if failure
G38.5     Probe away from workpiece, stop on loss of contact

G40       Cancel Cutter Compensation
G41 & G42 Cutter Compensation

G43       Use Tool Length Offset from Tool Table
G49       Cancel Tool Length Offset

G53       Move in Absolute (Machine) Coordinates

G54, G55, G56, G57, G58, G59, G59.1, G59.2, G59.3
          Select Coordinate System (1 - 9)

G73       Drilling Cycle with Chip Breaking

G96       Spindle Control Mode (Constant Surface Speed)
G97       Spindle Control Mode (RPM Mode)

…so these will all be implemented over the next few weeks for inclusion in Marlin 1.2.0.

[boelle]

should this not be added to the 1.1.2 milestone?

[rameliot]

I am working on a bi-polar printer I made and have the proper calculations figured out, but still struggling on how to make it work using Marlin. Any of you programmer have worked with true bipolar before?

[Roxy-3D]

Any of you programmer have worked with true bipolar before?

I don't know what bi-polar is. Are you talking about a Scara type of machine?

http://www.ukcnc.net/scara-protoype-wired.jpg

[rameliot]

An arm rotating from a center point without any other arms. I calculated the cartesian to polar points and using gcode, It will move to the correct angle and position. But I am trying to change the firmware like it is done for scara, just not sure where in the planner.cpp to insert the formula.

[Roxy-3D]

Please explain why that is Bi-Polar instead of Polar.

I think I would start with the Scara code... And modify that...

[rameliot]

Thanks, the arm extends in both directions from the center and the print head can go posituve or negative direction.

[Roxy-3D]

Do you have pictures or drawings of its movements? If I understand correctly... For sure I would start with the Scara code. I think your calculations to reach a position are going to be simpler than the Scara case.

[rameliot]

Thanks, I will send you a photo and more details. We are willing to pay for assistance. I have solved the issue of poor resolution that moving an arm from a central position has.

[Roxy-3D]

Thanks, I will send you a photo and more details.

You can also send me a Private Message at: www.3dprintboard.com Send it to user name Roxy.

[rameliot]

Roxy:
Thanks, I will be out of home for a week or so. I want to be on the printer real time next time we talk. 
Thanks in advance for your help. [email protected]

[Roxy-3D]

OK... I'll wait to hear from you.

[ciita]

This is a very nice project. If I use with galvanic scanner head for laser engraving, which point should I change code in Marlin firmware. How should I approach to chaging code for manupulate arduino DUE DAC0 DAC1 send biporal current into galvano scanner driving controller (20-30kpps). https://www.google.co.kr/search?q=galvos&ie=UTF-8&oe=UTF-8&hl=ko-kr&client=safari#imgrc=6xy-AT9aVXQ-MM: example item: http://www.ebay.com/itm/20KPPS-30KPPS-laser-scanning-galvo-scanner-ILDA-Closed-Loop-max-30kpps-for-laser-/261517002270

[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.

[HakanBastedt]

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?

LOUIS

2018-03-15 22:11 GMT+01:00 Scott Lahteine [e-mail]:

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
https://github.com/MarlinFirmware/Marlin/issues/3208#issuecomment-373524196,
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).

LOUIS

2018-03-19 11:13 GMT+01:00 Scott Lahteine [e-mail]:

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
https://github.com/MarlinFirmware/Marlin/issues/3208#issuecomment-374162325,
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[bot]]

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.