Add support for CO2/YAG lasers

[mikemaikaefer]

The included support for lasers is nice but somewhat rudimentary. I don't know what kind of lasers can be accessed with this mode, but industrial lasers are not usable. So I would request some changes which would make it possible to connect more professional lasers:

For CO2 lasers:

• free to choose frequency for the laser PWM signal with frequencies of up to 200 kHz (or even more when possible)
• basic tickle pulse, so also when the laser should be turned off, this minimum tickle pulse is emitted at the PWM output (this is a frequency with a very small duty cycle)
• maximum duty cycle - instead of going to 100% duty cycle in case of full power, this maximum duty cycle should be applied to full power; value should be freely configurable in order to support different CO2 lasers

For YAG lasers:

• all the above
• plus: FPK signal which is a short pulse of freely definable width applied on an separate output whenever laser is turned on

[chamnit]

@mikemaikaefer : Thanks for the concise list of features needed. For sure that Grbl should support CO2 lasers and other more powerful lasers, but the AVR is definitely maxed out in cycles. I'm in the middle of a Grbl re-write for much faster ARM MCUs and will focus on improving laser performance. There are other bottlenecks that need to be addressed to make more powerful lasers possible.

I do have some questions since you seem to know a bit about CO2 lasers.

• How quickly does PWM frequency need to change? Ideally would this be handled in a planner to dynamically change the frequency based on what's happening? Or something that is set for a particular job on some particular material?
• I'm not sure what a tickle pulse is. Can you elaborate?
• Maximum duty is something that you can set already in Grbl. I believe that is set in cpu_map.h as a maximum PWM value. You can also enable the new nonlinear spindle output and construct your curve to not output at a high duty cycle.
• Elaborate what a FPK signal is and why it is important.

Thanks.

[mikemaikaefer]

@chamnit how about the new PocketBeagle? It comes with a 1GHz ARM CPU that provides a lot of interesting features and all required outputs (GPIO, PWM,...)

About your questions:

• the frequency does not need to be changed fast or often - this can be done during movements where the laser is turned off. So it has not to be changed depending on movement speed or something like this.

• CO2 lasers never should be turned off completely, they would need way too long the next time they are needed. Thus they are already fired with a frequency - but during the times it should be "off" with a frequency using a very short pulsewidth. So this "tickle" is nothing more than a frequency with extremely low duty cycle just to keep the laser "warm". Typically this should be configurable from the user application.

• FPK stands for "first pulse killer" and is a separate pulse emitted at an other output (beside the frequency). This is a single pulse of a defineable width emitted every time the laser is turned on. YAG lasers can start with a very high power output at the beginning which would result in burn-in points. This FPK signal is used to suppress this first, way too high pulse. For some more details/an drawing you can refer to the documentation from https://halaser.eu/e1803_manual.pdf , description of command E1803_set_laser_mode at page 55

[chamnit]

I personally don't like programming on the Beagle PRUs. It's proprietary and limited, the last I checked. It's also overkill for what you need. There isn't much difference from using a cheap ARM chip in conjunction with something like an Raspberry Pi.

• If pulse frequency doesn't need to be changed often then what is the particular purpose of altering it then?

• If all you need is a minimum PWM signal, then this is already available. In Grbl's cpu_map.h, there is a PWM_OFF_VALUE. This is the output value set when the laser is considered off. It's zero by default, but can be changed to another value.

• Ok. So it's another IO output. This would be possible to add. There seems to some talk about a laser gate output as well. The suppose the question is when do you enact the FPK? After a certain amount of time, only at the beginning of a job, or only when you turn on the machine?

[mikemaikaefer]

@chamnit

• changing the frequency is up to the user and often material and motion speed dependent. So it depends on the laser type and which range of frequency is allowed to be used as well as from the cutting result. As example: when one has a too high maximum motion speed combined with a too low frequency, this can result in ugly, ragged cuts. So it is up to the user to choose a suitable frequency for every polygon

• FPK signal is emitted every time the laser is turned on (means every time the laser starts firing). This happens several time within a processing cycle, means whenever a new polygon starts

[chamnit]

Thanks @mikemaikaefer. That clears up the requirements. The FPK signal should be easy to include.

The frequency changes probably should be something that can be changed dynamically, based on what you said. Especially if a CAM program is configured to generate and command the changes. At this point, Grbl alters the duty cycle dynamically based on speed. This theoretically keeps the energy per unit area constant. Do you have a grasp on how the PWM frequency and the duty cycle relate to speed and material? It seems like there are a lot of nonlinearities there that need to be measured and modeled.

[langwadt]

@chamnit somewhat off topic but, if implementing grbl on something like a Beagle would be possible that only the stepper interrupt would need to run on a PRU, the rest just need to be reasonably fast with no strict real time needs?

[chamnit]

@langwadt : Yes. It is possible, but I did not find the programming language used by the PRU to be conducive to porting. It also locks you into the Beagle architecture.

[langwadt]

I agree it shouldn't be locked to a specific architecture. I was mostly out of curiosity because it seems there are more SOCs coming out with a small controller hidden somewhere in the corner.

and I believe there is a C compiler for the PRUs now

[mikemaikaefer]

@chamnit TI offers a free C-compiler for the PRUs, so they are programmed in plain C.

[mikemaikaefer]

@chamnit you are right, speed and duty cycle should be applied to each other but may be related to each other in a non-linear way. This does not depend only on the laser but also on the material - means this is nothing GRBL really can handle. I think here is is up to the user to define suitable maximum speeds and a suitable allowed power range for the laser to work within. And when a laser/material combination does not allow faster movements, they simply have to be processed slower in order to have acceptable results. But as said, this is know how the user needs to have. Btw: the document from https://halaser.eu/e1803_manual.pdf (already mentioned above) also contains some G-Code M-commands in range 7xx for all these laser specific things (starting at page 46). I don't know if this is really an industry standard for lasers, but it seems these commands are widely used for setting/changing laser parameters!?

[shamsiqbal]

@chamnit i am curios that what arm mcu you have chosen for grbl port i am sure you are working on arm port since more than 2 months but did not got clue about exact mcu you have chosen to port grbl