Well, sadly it is not all that easy
I tried different stepping and although the accuracy does not suffer my nerves do.
These tiny motors make terrible noise if they get enough current to do the engravings fast enough.
Another problem I noticed last night was that from the SD the engraving wanders out to the left with every line, another thig to address and fix
Just to be clear:
Reducing the stepping certainly allows for a slightly higher speed but I doubt it will fix the current issues of data overload.
For the hardware there is little difference as the amount of commends are still the same.
An optimised GCode sender for this purpose would be the best starting point to eliminate other causes.
Right now I am not really convinced that it is all down to the Arduino and the china hardware.
Have to check if proper flow control can be enabled and if I get a USB logger to check the actual traffic for any problems.
If someone wants to try my modded Turnkey Firmware I am happy to supply the hex file or source code.
But as I am still tinkering with it to get it better I won’t be of much help in terms of support for different hardware.
I’ve looked at the turnkey tyranny software and it wouldn’t be of much use to anyone that’s using a diode laser. Lots of extra , unnecessary laser-related code bloat there. For us diode laser users, all we need is a simple pwm output through the m106/m107 gcode. That’s all the firmware should be responsible for. The laser software takes care of the rest.
I did personally modify my Marlin firmware for 11bit pwm resolution instead of the 8 bit used by vanilla Marlin code and also created m03 and m05 gcode to drive the laser instead of the fan commands but these were minor changes. I’ve looked at turnkey tyranny and it’s hard to figure out what’s even going on in there.
Now that you have mentioned it…
I have to agree the Turnkey release is not what you call neat and easy.
My best guess is that at the time it was started there was not much else to try for a CO2 system.
And you are right, for a little diode system it is total overkill.
But some code hungry features like the base64 encoding for raster engravings do make a lot of sense in terms of code reduction.
Similar for the pulse and frequency control of the laser, especially when working on glass it helps a lot to have these additional controls.
The confusing part is that all laser functions seem to be added on top of the normal printer firmware.
Have not tried to use it on a 3D printer but am quite sure it would work right out of the box.
Co2 compared to a little diode laser is almost like comparing an exacto knife with a heavy splitting axe LOL
Both are perfect in their own field but trying to be precise with the brute force while still keeping full control over the finest power changes is a challenge.
I am quite happy with my findings and mods to get everything going and it was a great that I learned on the way, however there is still plenty of room for improvement.
Even the guys at Picengrave said it would not be possible to do 8bit engravings with a CO2 system on “fine” materials like wood or even cardboard.
Still it is possible with only minor tweaks
Would love to make my own Mini-Marlin without all the 3D printing stuff and just include the base64 and laser pwm and pulse controls from the Turnkey release.
But seems to be more complicated than what I thought.
Had a quick reading this morning in regards to my SD problem.
The combo of Mega2560, Ramps and the Discount controller seems to trouble a lot of people.
For most it does not work at all or only shows a black display when no USB is connected.
The black problem is going here as well as I noticed this morning.
Seems to be stuffed with the initialisation somewhere:
You start the machine, plug the USB in and the display comes on - apperently this is is meant to be like this.
But if no USB connection is detected for a few seconds the display should go on an initilise all standalone functions - this does not happen.
If I plug the SD in after turning the machine on, the controller states it was inserted but also that there are no files on it.
Turning on with the SD already inside and all of a sudden the files on it are found.
It now also shows up in Pronterface.
But and that’s a big but - starting a job from the SD blocks Pronterface, do anything within Pronterface and the SD seems to be unreadable again.
Same the other way around, start from the SD and nothing works over the computer anymore until you reset.
Quite annoying once you abort a test engraving and realise there is no menu function to turn the laser off ROFL
Here is a pic of an aborted test from the SD:
It seems that the problem is not constant, more like some steps are miing here and there.
Here is the beginning of the code for the file, entire thing is over 25mb, so I doubt there is need to upload it all.
;(Generated by 3dpBurner Image2Gcode v1.0)
;(@Mrz.15.2016 16:43:12)
@Doreen the first post in the thread has a github link which will always point to latest release. It will be in the bin folder. See if this link gets you there…
Ok, as it turned out my problem was a combination of the wrong (or unsuited) SD library and timing problems on the serial communication.
Also unlike in 3D printing higher acceleration and jerk setting can improve the outcome quite bit.
With my combo of Arduino Mega, Ramps 1.4 and this Smart Discount Controller I failed to realise that both the SD and the display itself use serial communication.
So everthing relies on the correct timings and buffer sizes to make it work at higher speeds.
I can now engave (from SD) 20x15cm pictures at 0.10 resolution @ 2400mm/min.
For what I do this is now quite enough and with the great Image2Gcode program I can now finally engrave the way an engraving should look like.
I still agree that for diode lasers a simple PWM approach is the best way to go.
After all you can adjust the focus by rising the Z axis and have not much else to worry about.
Althoug I see little problem in running a CO2 system on a simply Marlin firmware through FAN PWM control (with mods for the PWM signalof course) the hardware has different requirements.
One way of additional control is the pulse mode where you can define a PWM frequency and laser pulses per mm and their duration time.
A feature noone needs for a low power diode but if you engrave glass, ceramic or other brittle things it comes in handy there is far less heat transfered this way.
Diode lasers are also quite slow in the speed department unless you invest serious money in the higher power range.
GRBL is really slim, fast and should be the first choice to run laser stuff, but I still struggle with it especially as I would need massive hardware mods on my machine to get it conform to CNC standards as used by GRBL.
I think it is only matter of time until someone put out a cut down Marlin firmware that only has what is needed to run a laser and without all the bloat that is only used for 3D printing.
The market got flooded with these little CDROM motor driven laser engravers in no time.
Once more people convert their cheap and otherwise useless chinese laser cutters into proper freeware machines things might change.
But only if tools like Image2Gcode are kept free and people keep developing new stuff we can move away from expensive solutions that are still not perfect.
Leo69 and Bryan made the impossible possible for us and they give support, something that is hard to find for other freeware
Now with everything working at least half decent I took some time to check on the problem of stuttering during the engraving.
After maxing out the hard- and firmware settings for speed I was back to the Gcode to find the cause.
One thing just to be clear here:
These speed issues might not affect everyone with a diode laser but the info might still be of value for those with a CO2 system or with the need for more info.
All Gcode is tansfered through a serial connection no matter if you use UBS or the SD card, but the SD card requires less processing power.
This means that systems like mine should better use a display with a parallel connection or no display at all.
The Smart Discount Controller uses a serial connection to provide quite some info on the screen and even with lowered refresh rates it interfered with the engravings.
At high speeds it was enough to go through the meu settings to make it all stutter.
I tried to direct the SD stuff through a software serial connection, did not work, and if done for the display I was unable to find a onfiguration that would not mess with other factors.
So all further tests have been done with the display completely inactive and the controller only used as a card reader.
Being aware now that the Gcode is transfered through a serial connection that relies on the CPU timing my first attempt was to use a slower SPI rate of quarter instead of full speed for the SD.
It did not improve much but I left it that way.
Increasing the serial buffer of the Mega from 64 to 256 gave quite better performance but still massive stuttering at higher speeds.
At this point I started to think that the slimmer code already made a big difference so maybe it is the amount of data that needs to be transfered?
Mind you the SD uses 9600baud for the serial transfer - this is an important factor!
The higher the engraving speed the more commands per second need to be transfered through this serial connection.
From here they end up in a buffer that is used for the movement calculations - the RX buffer that was increase to 256.
So everything that goes into the buffer has to come out as well, this means the buffer must be filled before it runs empty and can’t be allowed to overflow either.
As a result the 9600 baud are one limit, the buffer handling another.
If we take into account all the othe code the CPU has to process it becomes clear that more Gcode is transmitted per second the faster the firmware and arduino will reach their limits.
Without claiming I understand all the inner working of Image2Gcode I think that the pixel information becomes more detailed the higher the image DPI and the set resoltion in the program is.
You can basically adjust how many power changes happen in an engraving per mm of line.
Taking all this into account I think it could be possible to create a calculator for the max speed.
Quite a few variables I know
My tests showed that images with less power changes allow much higher speeds than let’s say landscape images.
Also of course that the higher the resolution settings in Image2Gcode the lower the speed has to be to get proper results without stuttering.
So using a dedicated Gcoder sender will not really help much here.
I think one way of optimizing would be to eliminate the resultion settings in favour of a calculation based on laser spot size and image resolution.
Meaning that the image informartion is not calculated based on the pixel information but instead the pixel value for the laser spot size/image resolution is averaged.
This way the engraving quality in terms of data generated will be based on physical factors that reflect the machine and should provide optimized results on all systems.
I did some test trying to figure out a way to implement this but it over my limited capabilites.
Just touching base, any new changes to the software? Been looking at getting or rather building a CNC machine for light duty stuff but with a cutting range of 24"x24" wood, carbon fiber, and perhaps some lighter materials as well. Like I needed another project lol. I want to do the 3dprinting as well but seems to go really slow in regards to print process. Right now I am still kickin it with v4 of image2gcode.
I seem to be getting the same problem as PeterT #7926, except the modified version did not work here.
I have installed visual studio and have run the software through that.
Seems to come up with the same error but with different presentation.
Is there an error report I can get from visual studio for better understanding of the problem?
Edit:
Found out that if tbWidth was set to 99 instead of 100 everything worked without a problem.
Seems like tbHeight gets an infinite number of decimals.
Here is my latest test, done at 4000mm/min, size 65 x 55mm.
The only problem now is the fact that CO2 rather vaporizes than darkens at higher power levels.
As a result the material just disappears at certain power levels with only a little darkening.
But this makes it perfect for 2.5D relief engravings
@rokzin sorry for late reply. Post a screenshot of error if you get a chance and I’ll look into it. Also, make sure you’re using the exe file that’s linked In the very first post of this thread. Unfortunately this thread has gone off course a few times and you could spend a week reading it:)
HI, I am very new to laser engraving - and i had some questions about the settings in this program:
what does “laser power command - S or Z” mean?
and what do i select for ‘Power on/off Mcode’
i have a 2.5w diode machine
The entries you make in this section are dependent on the GCODE commands that you use to trigger the laser. The information that’s really needed is the firmware that you’re using. Most likely you have one of the configurations below so post back if you have a different set-up.
GRBL-If using GRBL firmware then your laser is likely connected to the spindle on/off pins so you’re settings will be :
Laser Power Command : Choose ‘Use S Param’ option
Laser Power On MCODE: Choose ‘M03 S’ option
Laser Power Off MCODE: Choose ‘M05’ option
GRBL uses 8 bit PWM resolution so in the ‘Laser Profile’ tab you should enter 255 for MAX value.
Marlin- If using Marlin firmware then your laser is likely connected to the fan on/off pins so you’re settings will be :
Laser Power Command : Choose ‘Use S Param’ option
Laser Power On MCODE: Choose ‘M106 S’ option
Laser Power Off MCODE: Choose ‘M107’ option
Marlin uses 8 bit PWM resolution so in the ‘Laser Profile’ tab you should enter 255 for MAX value.
You have a fairly high-powered diode so if your engravings are coming out to dark you can try increasing the feed rate first. If increasing the feed rate doesn’t work then try lowering the MAX power value in the ‘Laser Profile’ tab a bit. Keep in mind that your grayscale resolution will be compromised if you lower the MAX power value too much. Let us know if you have any questions…
Heh, just saw your heated bed off to the side of where you’re lasing. We could build a really long table, then have a printing section, an engraving section, and then a routing/milling section all on the same machine!
now on the ‘laser profile’ tab, under the profiles, there is a rate- in the case of ‘wood’ its 3000mm/min, is that the speed of the laser?, because on the next tab “Gcode” there is a separate option labeled ‘feed rate’ that can be a different number - does one override the other, or are they for different things?
it has Resolution set at 0.18 - should that ever be changed?
I also noticed that in the image tab, width and height boxes, you set a value, and then if you go to the title bar menu - and change the ‘Units’ from metric to imperial, the values in the boxes do not change to reflect that, is that a bug?
@quietmike : The original software only supported one “profile” and the ability to set custom profiles for different materials was added by Bryan in a later revision. The feed rate setting in the “Gcode” tab applies to the default “MAX” profile while the other profiles have their own feed rate setting that can be entered.
Yes, if the values in the height and width boxes aren’t converting when the global units setting is changed then this is likely a bug that has been present since day one. I’m pretty busy so I have to admit that it’s a simple fix but one that I likely won’t get to anytime soon. Easy way around it is to set the units of measurement before you import and edit your image.
So I should receive a 2.5w Eleks maker Chinese engraver soon, it seems to be based on a Arduino nano.
I want to be able to use PWM on the laser to get 8-bit shading and better engravings.
Will this be the correct procedure for setting it up with 3dpburner:
change jumper under the board from 8 to 9
flash custom grbl firmware (sketch_apr15a.cpp.hex) using Xloader
use 3dpBurner Image2Gcode program to import images and settings
use 3dpBurnerSender to send code to machine for engraving.
I think you’re posting on the wrong forum.i doubt anyone here has that engraver or knows the function of the jumper you mentioned. Laser pwm control is dependent not only on the microcontroller and firmware but also the laser driver.If the driver doesn’t accept ttl/pwm control signal then grayscale raster engraving can’t be done. I just browsed through a couple of listings for this machine and the specs are very poorly documented. I think you have your work cut out for you.
In the Laser tab, Can someone explain to me what the 'experimental features: enable decimal values, and, Optimized Raster" do and when they should be used
