8bit engraving with a CO2 laser

Sure that is one option but I prefer to either calibrate to avoid this or if the hardware is on the limit to use a lower speed.
At 2400mm/m I have no pinholes at all, they start at around 3000mm/s and go really bad at 4000mm/s.
It is slightly better without display and SD support but not enough for me to say this is still related to serial comm issues.
What made a huge difference here (before I had the pinholes already at 1800mm/min) was to get rid of some floating point operations and to assign integers in some places where float values have been used.
So far I only conectrated on the laser part for this and the base63 decoding.
I (hopefully) narrowed the pinholes down to the direction change routine in conjunction with the buffer tail.
The right left calculations need slightly more time for the processing and since the buffer always stores complete commands these long base64 lines can be a problem.
Keep in mind the original string goes into the serial buffer, the decoded string into the ring buffer.
This means the timing for this is important as well as the size of the buffer.
The planner loves to annoy me too in this case.
A raster line is interpreted as a single line in the planner but the power changes are calculated on the pixels.
So the final line is done as a line in pulsed mode where the pulses are adjusted on the go.
Sadly this is only possible with float values and I have not found an accurate way of removing the floats here.
Only way I see is to multiply all position values by a factor of let's say 1000 and use the absolute value for the calculations as integers.
But as you guessed this goes on the loss of accuracy and so far I could not make it work properly.

For a normal picture engraving it is easier to add a 2 or 3mm white frame in the picture to be engraved instead of adding a frame later
I want to move on to 2.5D relief engravings and here you really can't have or hide these pinholes at the end of the line.
But until I get something that works better than MDF in this department I can't do any proper testing.
Final goal at the moment is to be able to do 2.5D engravings on glass

Here is a pic of test engraving on 3mm playwood:

As you can see there is a slight problem at certain power levels where the material simply vanishes instead of just going darker.
And as always, when you clean the surface there is no real contrast left - but who cleans a 8bit engraving?

And here is a little test of a 2.5D engraving:

... this "colour adjusting" is one of the tricky parts with most materials - either it's simply evaporating at a specific level, or the color changing effect is not linear.

You have to adjust/calibrate this for every single material to get perfect results ... the other part is time/experience ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

That was one of the reasons why I wanted the higher input range for the power levels.
CO2 is too powerful without very fine control of the energy going into the workpiece.
Now with the latest changes I can at least vary the speed to wide degree which helps a lot for sensitive materials.
And similar to my filament I started a collection settings used to have a reference to build on.
8bit on copy paper worked out quite well though with only a few holes created.

Maybe once I think the firmware is doing exactly what I want and need I will start to create some tables.
Fixed values for the 255 shades of grey for different materials I use more often.
Never though a laser could be so much fun once working properly LOL
Started to experiment with metal marking solutions as well.
Just checking what household chemicas produce any result as base for marking fluids.
Black and gray are quite easy on steel and copper other colors are a bit hard.
Burning some CaSO4 right now for some new marking paint in the hope to get a smooth surface this time.

With a powerful laser it would be handy to have PWM mapping that takes care of the non-linearity of the output. ( Like thermistor tables )
You could adjust the mapping by engraving a greyscale test pattern and put it on a scanner to compare each greyscale.

But then again, wood is always unique and differs in humidity too.
Would we need a mapping for every type of wood then?
Probably dry the wood before use to have constant results?

With reduced laser current I was able to engrave on thin cardboard without burning holes, but it was difficult to get a good contrast.
It's a trial 'n error game everytime...

For photo engravings I have a substitute for wood that gives really good contrast: 2 parts flour and 1 part salt mixed with litte water.
Roll out and let dry for a few days then fully dry in the oven.
Needs higher power levels to burn away than wood and has a much wider power span than paper or cardboard.
Only problem is getting the dough air free and with only a little bit of water.
Trying to mix the water with some alcohol for the next batch in the hope to shorten drying times.

At higher power levels it is also good for 2.5D engravings but same as for the engravings on it you need to seal everything once cleaned and finished as the salt will attract moisture from the air.
If you don't want to seal you can try wall paper glue or corn starch as a binder instead of salt - still add some salt to prevent thr flour from rotting over time.

As for the wood I tried the same sort of hardwood but with different densities (judged by weight).
All were quite similar bad to cut with the saw so I confident there would not be any problems with the light stuff being weaker.
The heavy pieces caused a lot of charring and carbon build up while the lighter pieces only got a nice shine added to the surface.
So there is a balance between resin content and density.
Also the reddish parts of the hardwood caused more carbon build up on than the light colred parts - again with worse outcomes for heavy wood.
I did some tests with alcohol and my vacuum pump to dissolve the resin in the wood and it worked to some extend but did not help at all with the fact that the grain burns away much faster than the rest.
Might try again with some salts as a flame surpressor if I have more time one day.
The washed out resin areas and the softer grain should soak up more salt water and hopefully last longer in the laser fire.

If anyone with a K40 clone or diode laser would like to try my modded Turnkey Tyranny firmware:
Download
Please use XLoader for an easy upload to the Mega2560.
Power levels go from 0 - 10000, 10000 being max power.
All things are optimised for the K40 clones so if you want to try with a diode laser you will have to adjust the stepping for the axis.
Info on the wiring can be found in my Instructable or here, where I got my inspiration to start all this.
A modded version of the Inkscape plugin by Turnkey Turanny can be found in my Instructable as well.

Do you think it would be ok if the full intensity range 0-255 can be maintained at every speed?

What kills the resolution is the range adjustment in planner.cpp (the 7% thing).
That can be kept as a small remapping from 255-0 to 255-7 (or whatever) and the laser power is
placed in a new variable in the block and brought into the stepper isr. At the point of actual firing
the multiplication of laser power and greyscale intensity is done. That would maintain the greyscale
resolution fully, or at least up to the resolution of the pwm duty cycle. What do you think about this?

That is implemented into the firmware.
I increased the input range from 0-100 to 0-10000, giving the same resolution as if you could use decimal values.
The rest was an adjustment of the range setting to match the 255 shades of grey.
I can print with the full range mapped to new power values at any given speed - within the hardware restrictions of course.
Before there was less than 100 different power levels as all below 7 was ignored, but since the resolution was too small too the raster mode ended up with 2-5 shades of grey.
This is fixed for good and I also changed the Inkscape plugin to allow for the greater input range without limitations.
Currently testing what max resolution gives the best results compared to the original 270DPI.
But things might speed up now as I found some nice people porting it all to the latest Marlin release including support for more boards like the Alligator.
With that firmware I still have temperature problems as even with all thermistors set to 0 I get an error for heater0 0 but I hope this can be address soon so testing can continue.
The Instructable was updates with my latest testengraving on Arakaria wood, which I think worked out quite well.
So despite some companies claiming it is not possible to do 8bit engravings with a CO2 system it works

MarlinKimbra is here!
I implemented my changes into this great new firmware and it is now all aup an running what I need.
Time to get going and include more relays, sensors and switches.
If you just want the hex file for your K40 based on my mods then check the Instructable please.

I'm trying out your MarlinKimbra and i'm running into a compile error... I think it's a simple one. I'm trying to orient myself to the new code but thought I would ask here in case this was an easy one... I think might find more of these once I resolve the first one.

exit status 1
'ORIG_PS_ON_PIN' was not declared in this scope

Thanks

Did you use the 1.6.8 IDE?
The older ones all give me various errors for no good reason.
If you did not make any changes to the firmware than it should complie with no errors at all.

yep 1.6.8... I commented the line out, it compiles but, the laser doesn't fire... So i tried your MK.ino.hex file and i get the same behavior. I'm using drv8825 stepper motor drivers so i would like to be able to make my own adjustments.

I'm having other problems with computer rig ATM so I'm going to do a complete reinstall of windows and see if just happens to clear up this problem as well.

although, I don't know why MK.ino.hex won't fire the laser. I use Turnkey K40 Laser Arduino + Ramps Firmware without problem.

Is you power supply set for dual pin control or single pin control of the laser? The default in the firmware is dual.
I noticed there are different configurations for the power supplies out there, it might be that you need to double check if the laser on pin of the power supply really goes on the right pin on the ramps board.
If laser on and laser PWM are switched over the laser won't fire.
But to make sure all is ok I downloaded the firmware from Github again and it compiles here with no complaints at all.
There have been a few slight changes I made a fe days ago and the testing was a success, so I will update the Github files accordingly.
With the changes I am now able to engrave @ up to 7200mm/min with no problems at all, using 1/8 stepping though, so jumper MS3 has to be removed or you need to turn the stepping back in the cartesian configuration.
I just added a diver so it is pretty straight forward either way.
Not sure how fast you are with installing your system but check the Github for updates and once you all is at new dates download and try the new version please.

Alright I have a fresh new system with new install of Arduino 1.6.8 and a clean copy of your MarlinKimbra and I'm still not getting the laser to fire. Code now compiles fine (unless i enable my full graphic smart controller and then only compile warnings). I have checked the wiring and that looks good, plus with Turnkey K40 Laser Arduino + Ramps Firmware the laser fires and i have full control over it. I have a dual pin power supply, high turns the laser off and low turns it on. If i switch the pins around I get the laser firing all the time at full power. I'm starting to go thought the code to get myself up to speed but at this point i'm just poking at it. Any clues?

Another problem i'm having is, I don't see how you get the max end stops to work. If i do a M119 command I don't get any status on the max end stops just the min end stops. I'm not sure how they are turned on and off in the code. I see that there is some configuration options in the Configuration_Feature.h file but not seeing how to enable them.

Anyways, any help would be great.

Thanks

BTW, i'm mostly testing this with the "test fire" option in the LCD menu. What does the first number mean? I.E. 800 50ms.

Edited 1 time(s). Last edit at 04/30/2016 01:21AM by chalen.

What max endstops? There are none in the machine.
If the original firmware fires than mine should do the same as all the laser stuf in this regard is the same in terms of pins and firing control.
Is it possible that you missed the fact of the increased power levels?
The Turnkey release has 0-100 for the power control, mine 0-10000 for a greater resolution here - so to get 10% power out you need a setting of 1000 for the power level!

I installed some max end stops...

Are you saying that the options in the menu of the LCD controller to test fire the laser are set to values to low to actually fire the laser?

Can you talk me through your workflow process? What program do you use to edit image. What generates the gcode and what program you use to send the gcode to the laser cutter? i'm having a hard time try to find a program that lets me generate S gcode with values over 255 or 100.

Max endstops are realised through the firmware and dimensions of the bed, if you need real endstops to function you need to make the corresponding changes in the firmware.
The menu functions will fire the laser, they are set to working values and show as such on the display.
Inkscape with the supplied plugin and a standard 3D printer software like Pronterface is all you need.
You can still create your designs in Corel or other software but the G-code generation happens in Inkscape, so use supported fileformats like SVG, ai and so on.

hmm... yes i see if i turn the values up above 2000 I start to see the laser fire. Still the max setting in the menu "1500 100ms" still isn't enough to mark paper. I use Laserweb and Visicut. The 32 bit version of inkscape and the plugin Crash every 30 seconds on both my computers and therefore I don't use the plugin. The 64bit version of inkscape works great. Most plug-ins or programs (including Turnkey Tyranny) will out put values of at least 2 decimal places so instead of requiring values between 0 - 10000 it might be better to accept values of 0.00 - 100.00. This should keep the precision we want but also make it more compatible with existing software.

Ill figure out the max end stop thing.

Thanks, I think this firmware is a step in the right direction and i hope you keep at it.

There is a reason the 0-100 is not kept - try to base63 calculations with decimal points
If the plugins or Inlscape crash then it is quite possible your porblem is python but not the programs or plugins.
Needing more than 20% of power to make the laser fire can't be correct and either your power supply works way different or the tube is not 100%.
Keep in mind the testfire only give a short pulse meant for the alignment but still at 1000 or 1500 it will mark paper.

I don't suppose the changes you have made to MarlinKimbra could be easily ported back to the turnkey build could they?
And maybe what's the best way of doing that? like, which files you have modified to get it to work?

Why would you want to use a very early and buggy Marlin release if you can use current versions that run much smoother?
Sure, with a lot of work it could be possible to port it back but I fail to see the point.
Like any other firmware all that needs to be done is match the settings to the machine in use - and that would be much faster and better than modding an outdated Marlin with new features...

I've been trying for weeks now to get MarlinKimbra to work for me and it's just not working out it. MarlinKimbra has a lot of features I simply think just don't work. If something is broke in Turnkey i been having a lot of luck fixing it myself. Turnkey has A LOT of problems but at the end of the day I can get it to work, at least for laser cutters, I don't think MarlinKimbra is the answer or at least it's going to need a lot more work. Also I just don't want to be tied to that Inkscape plugin as my only way of generating G-code for my laser cutter. I like your work and what you are trying to do. I did manage to get one engraving out of it and it was vary nice but, it took hours of screwing around to get it.

I think the only answer is that someone is going to have to spend a lot of time fixed/updating Turnkey or someone is going to have to spend time making a Configuration_LaserCutter.h for MarlinKimbra and modify all the backend code to support it.

Sorry but I can't really follow you here.
So far the modified Kimbra is working really well but of course for good results some testing is required as well as a proper machine configuration.
The laser control works exactly as planned so issues here should only come from lack of experience or wrong settings.
The Inkscape plugin is no must have as standard Gcode is accepted, which mean programs like Image2Gcode and anything else generating cutting or engraving Gcode can work too.
What exactly is your problem with Kimbra, assume you tried my release with laser support?
As said, I support my work and try to help if someone has problems but I can't help based on comments like not working, not good enough and so on.
Currently I can engrave at speeds of up to 9000mm/s and complex vector jobs at up to 4000mm/s before loosing steps.
The photo engraving is complicate, I admit that but you have to consider that all materials are different, even wood cut from the same tree will differ badly within the grain structure and resin/sap content.

Yes I have been using your download of Kimbra which I got here: [github.com]. I have a working K40 and can configure it to work with turnkey.

Today I just extracted a new copy of Kimbra and made only two changes to the config files.

1. in "Configuration_Feature.h" I un-commented out the line "#define REPRAP_DISCOUNT_SMART_CONTROLLER"
2. in "Configuration_Cartesian.h" I changed this line so Z table will move correctly "#define DEFAULT_AXIS_STEPS_PER_UNIT {157.4802/2, 157.4802/2, 160, 625, 625, 625, 625}"

Problems with your version of Kimbra:
1. None of the "Test Fire" functions work in the menu of the REPRAP_DISCOUNT_SMART_CONTROLLER.
I can test that the laser is working fine by sending the command "G1 X0 S1500" from Pronterface. This fires the laser fine, so something isn't working when try to test fire the laser from the LCD Test Fire menu.

2. From Pronterface sending the command "G0 Z20" dose nothing. The Z axis doesn't move. It seems to acknowledge the command but doesn't try to move the stepper. I can test that the Z axis is working fine by sending the command "G28 Z F150". This homes the Z axis like you would expect but no G1 or G0 commands will move the Z axis.

3. The "Set Focus" Menu just homes the Z axis and doesn't move the bed to the selected height. Part of the problem seems to be with problem #2 but looking at the output from Pronterface i see:

Echo: enqueueing "G28 Z F150"
Echo: enqueueing ""
Error: Unknown command: "
[ERROR] Error: Unknown command: "

If we look at the code in MK\module\lcd\ultralcd.cpp
on line 1691 we see:

static void laser_set_focus(float f_length) {
   if (!TEST(axis_was_homed, Z_AXIS)) {
      enqueuecommands_P(PSTR("G28 Z F150"));
   }
   focalLength = f_length;
   float focus = LASER_FOCAL_HEIGHT - f_length;
   char cmd[20];

   sprintf_P(cmd, PSTR("G0 Z%s F150"), ftostr52(focus));
   enqueuecommands_P(cmd);
}

Notice how "enqueuecommands_P(PSTR("G28 Z F150"));" seems to have been understood by Kimbra because we saw "Echo: enqueueing "G28 Z F150"" and the Z axis homed like we expected. But, the output:

Echo: enqueueing ""
Error: Unknown command: "
[ERROR] Error: Unknown command: "

Seems like "enqueuecommands_P(cmd);" didn't send what we were expecting which was "sprintf_P(cmd, PSTR("G0 Z%s F150"), ftostr52(focus));" from this char array. I don't think there is anything wrong with laser_set_focus as it's the same code in Turnkey and it works there just fine. Something seems wrong here but I haven't been able to figure it out.

I will leave you with these bugs I found a few more but i think i have fixed them myself and am trying to test them.

Some of the other problems I have found have to do with Endstops but, I downloaded the real version of Kimbra and found that they have added a endstops.h and a endstops.cpp in the "MK\module\motion"Dir. I haven't tried it yet but I'm thinking there might be some valuable changes in code here.

To test this I think your going to need at least a stepper motor and an end stop hooked up to your RAMPS board. If you don't use an LCD, Z axis or Endstops I see why you might not be running into these issues.

Thanks.

Thanks for testing and the feedback!
To the problems:
1. The tesfiring from the menu worked fine for me but I have not used the display for a while.
Will check this and if working here will adjust adjust thepower levels a bit higher, if not working here I will fix this.
2. I did not configure any Z-axis as my machine does not have a motorised table - that is a planned upgrade.
As it is not defined in any it simply means it runs be the defaults set in Marlin, including the pin config for the stepper and the stepping itself.
Right now there is not much I can to make it work without having the hardware ready for it.
3. Again, my machine neither has a adjustable table nor focus - the firmware was optimised for the standard K40 machines.
If you require it for a diode laser you need to configure this for your machine.

If you want to use all axis I suggest to first check the defines.
As said my version is made for the K40 lasers which have none of the features you have problems with right now.
The addititional files should not be required either as the standard Kimbra does not have laser support - things are slightly different.
It should be pretty straight forward to get the z-axis working as it should.
The focal height adjustment I can not test but if I am not mistaken it will only work without errors if it is activated everywhere in the firmware and setup correctly.

What type of machine are you using?

I'm using a k40 the third revision if you believe the ebay seller. I have add quite a few upgrades... I have gotten some nice engraving with your firmware, but the setup time and effort to get it working right for me is too much. I will keep my Marlin RAMPS board, but I just bought a Smoothie board so, i'm going to see how that works out for me. I plan on building out a second k40 and will keep an eye on your project. If you have something you think needs testing I would be happy to give it a try. I feel that I need to take a brake form trying to fix Marlin a just run with what i know works for me.

looking at the code for a while now, I really feel that Mega 2560 is at it's limits as far as asking it what we want it to do. Sure I think it could work well given enough effort but looking at an Arduino Due or my favorite Teensy 3.2 i'm thinking that's where RAMPS needs to go.

... I'm actually using ArduinoDues in different configurations, mostly with a RADDS 1.5 shield.

Yesterday searched for different halftone-programs and found some with interesting options ... some even with source-code, so I can fine-tune the export for my modified Pronterface

Yes, the 32Bit-Arduinos are the way to go ... until the next generation will occure

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

32-bit Due works fine for Co2 laser imo. Mega works fine for laserdiode which doesn't need to run very fast. Hybrid laser diode and 3d printer perhaps?
There will be laser support in an upcoming version of Marlin if all goes well, for Mega then.
Wish for more than 32-bit? Speed can always be faster like 10x. FPU. More utlities like wifi, touchscreen. Extendability through apps or Lua perhaps? Soon it is a linux...

Enqueuecommand_P() can't be used there, enqueuecommand() or what it is called, the version that reads strings from normal memory not program memory should be used.

Edited 2 time(s). Last edit at 05/16/2016 07:03AM by falwty99.

Sorry to bump up this old thread but I ended up in the same place Chalen did with my Z-table. I took it the next step as suggested elsewhere in this thread and edited "enqueuecommands_P(cmd);" to read "enqueuecommand(cmd);" in MK\module\lcd\ultralcd.cpp. Per the serial output the G0 commands for the Z axis move are enqueuing but now I've uncovered another level of Z-axis issues.

My table homes properly with a "G28 Z" command. I can adjust the Z height using the Move Axis menus and it moves accurately. However, if I use Move Axis, then for any G0 code I issue afterwards (regardless of Z value or whether or not Z is even specified like "G0 F150") it returns the Z axis back to the homed/zero position.

I suspect the Z value is getting accidentally zeroed out in the code somewhere but I'm too much of an amateur coder to figure out where it might be happening.

I also could be mis-configuring my Z-axis in general, because I really don't know what's expected. On a printer, increased Z means increased distance between the head and the bed. I set my Z-table up the same way with a Z-min endstop at the top of the Z-table's travel and homing to it. Increased Z moves the table down. This looks like it may be the opposite of what the Laser Focus menus expect, so I'm second guessing this approach. I'm not sure why this would cause a return to zero on any G0, though.

I've done a ton of searching and there's just not that much info about Z axis issues with laser cutters out there. Any wisdom from the forum on this is greatly appreciated.

Thanks!