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

[MetalMusings]

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

[nextime]

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

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

[Blue-Marlin]

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

[nextime]

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

(this one: 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

[MetalMusings]

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

[MetalMusings]

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

[Downunder35m]

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

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

[Downunder35m]

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

[MetalMusings]

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

[Downunder35m]

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

[emartinez167]

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

https://github.com/openhardwarecoza/LaserWeb

They are now working on an improver LaserWeb2 version.

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

Regards,

Ernesto

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

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

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

[nextime]

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

@Downunder35m i'm working on a patch to implement all TT modifications ( and few more ) on the MarlinKimbra (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 < notifications@github.com> wrote:

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

@Downunder35m https://github.com/Downunder35m i'm working on a patch to implement all TT modifications ( and few more ) on the MarlinKimbra ( 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

[MetalMusings]

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

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

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

[nextime]

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

[MetalMusings]

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

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

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

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

[MetalMusings]

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.

[MetalMusings]

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.

[MetalMusings]

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

[MetalMusings]

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.

[MetalMusings]

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.

[MetalMusings]

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.

[MetalMusings]

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

[MetalMusings]

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.

[MetalMusings]

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.

[MetalMusings]

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

[MetalMusings]

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?

[MetalMusings]

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.