Laser not firing at correct time | Questions on pushing step rate limits

[tjhub3]

I am having an issue with my laser not firing at the correct spot relative to the actual job location. This in turns makes for some very jagged lines.

The problem presents itself as extremely obvious on paper and on wood to a lesser extent (though still far outside of what would be considered acceptable). It seemed to also be exacerbated at greater speeds.

Pictures of a paper and wooden example:

There is also a very odd hatching/wavy pattern when engraving woods. It shows up at the end of every scan line. Picture below.

Anyone know how to fix these issues?

---

I am also trying to push the upper limits of GRBL and want to effectively get as close as I can to the max step rate possible for a 20mhz ATmega328P.

After I get comfortable with GRBL and my cheap steppers I have some badass closed loop (@ the driver, not controller) servos + drivers from Advanced Motion Controls that I plan on using. Drivers that allow me to programmatically set the exact step -> rev rates and adjust the encoders accordingly (encoder processing is all handled onboard the driver; I just tell it step and dir same as a stepper). I want to run this at an equivalent to 600ppi resolution so my steps per mm needs to be just under 24.

Am I correct in understanding that @ 24steps/mm I should be able to push over 1,500mm/s accurately? Or am I going to hit some limitation (like laser switching) that I haven't foreseen?

---

Here is a copy of my settings at this point.

$0 = 10 (Step pulse time, microseconds) $1 = 0 (Step idle delay, milliseconds) $2 = 0 (Step pulse invert, mask) $3 = 0 (Step direction invert, mask) $4 = 0 (Invert step enable pin, boolean) $5 = 0 (Invert limit pins, boolean) $6 = 0 (Invert probe pin, boolean) $10 = 1 (Status report options, mask) $11 = 0.010 (Junction deviation, millimeters) $12 = 0.002 (Arc tolerance, millimeters) $13 = 0 (Report in inches, boolean) $20 = 0 (Soft limits enable, boolean) $21 = 1 (Hard limits enable, boolean) $22 = 1 (Homing cycle enable, boolean) $23 = 3 (Homing direction invert, mask) $24 = 50.000 (Homing locate feed rate, mm/min) $25 = 1000.000 (Homing search seek rate, mm/min) $26 = 250 (Homing switch debounce delay, milliseconds) $27 = 4.000 (Homing switch pull-off distance, millimeters) $30 = 1000 (Maximum spindle speed, RPM) $31 = 0 (Minimum spindle speed, RPM) $32 = 1 (Laser-mode enable, boolean) $100 = 23.921 (X-axis travel resolution, step/mm) $101 = 83.406 (Y-axis travel resolution, step/mm) $102 = 250.000 (Z-axis travel resolution, step/mm) $110 = 72000.000 (X-axis maximum rate, mm/min) $111 = 6000.000 (Y-axis maximum rate, mm/min) $112 = 500.000 (Z-axis maximum rate, mm/min) $120 = 8000.000 (X-axis acceleration, mm/sec^2) $121 = 1000.000 (Y-axis acceleration, mm/sec^2) $122 = 10.000 (Z-axis acceleration, mm/sec^2) $130 = 600.000 (X-axis maximum travel, millimeters) $131 = 500.000 (Y-axis maximum travel, millimeters) $132 = 0.000 (Z-axis maximum travel, millimeters)

---

Thanks for any help!!!

[chamnit]

72000 mm/min is very fast. You are likely seeing mechanical issues due to the waviness in your edges. 24 steps/mm is pretty rough and can excite mechanical vibration modes in your axes.

[tjhub3]

Ah, so my wavy issues are more than likely due to the limitations of steppers themselves and not something I've set in GRBL? Thats good news!

Good because it's something I am going to solve in the end with servos hopefully, no? I shouldn't be experiencing the jerky magnetic lock every step that steppers do.

Basically I need to get these machines up to par and competing with our old Epilog engravers.

They (our Epilog engravers) are able to do ~2.5+ 32" x-axis traverses per second at full speed; roughly 2,000mm/s when not including accel/decel times. I understand that's pushing the limits of GRBL on the 328, so for now 1,500 is completely acceptable if possible. Hopefully when GRBL-ARM is at a mature point I can unlock the full capability of our machines again!

---

As far as the laser not firing in the right spot though, any ideas? The pictures that I posted were engraved @ 250mm/s. I'd think well within reasonable mechanical limits, no?

Or is this also an issue with my steps/mm being so rough?

---

Thanks for all your work @chamnit! You're awesome!!!

[chamnit]

Up to par with an Epilog? I'm afraid we're not there yet. THere's a lot to be done to improve things to that point. A servo may help, but I don't expect it to be significantly better.

The offset errors can depend on how small they are. Are they about 1/24 of a mm? If so, then it's likely a rounding incompatibility between your CAM and Grbl.

[tjhub3]

If it's not too big of a question, what else would really be needed to get it up to par with an Epilog engraver? All of our Epilog engravers are ~15-20 years old and have very few bells and whistles (heck, we don't use rotarys nor bitmap rastering). As long as we have a laser that can scoot 'n shoot a simple raster engraving (albiet sometimes fine detail) quickly we're happy. (Not trying to imply that my companies specific needs are == to everyones specific needs. I just don't know what features we are missing that others use)

---

The offset errors seem to be much larger than 1/24mm. To double check I increased my step rate to ~1/48mm. It doesn't really seemed to have changed anything at all.

I went ahead and used some very basic gcode instead of trying to send it an image. ($110=6000, F=6000)

Here is the gcode

G0X2.5 G1X2.5 G0X10 G1X5 G0X10 G1X10 G0X20 G1X10 G0X10 G1X5 G0X10 G1X2.5 G0X2.5 and reverse + repeat 25 times.

In running that I end up with this

Zoomed in on some of the worst culprit pairs

It might be slightly worse on the 24step instead of the 48step. But I think that is my mind playing tricks on me as the errors and their placement are not consistent.

EDIT: Whoops, accidently tabbed over + hit enter on the close and comment.

[chamnit]

@tjhub3 : Interesting. Not exactly sure what would cause this. Your test seems pretty ordinary. Can you provide your $I build info strings and a complete list of things you've altered from the stock build?

[tjhub3]

I haven't changed anything inside the stock build/code of GRBL. For now all I have done is modify $ parameters.

$I shows

[VER:1.1f.20170801:] [OPT:V,15,128]

Our laser is a Coherent RF tube + generator. We're running shielded CAT5 for the TTL to it but... we're using a breadboard to breakout the Arduino to do stuff like limit switch filtering. The CAT5 is hooked up to that breadboard breakout and not the Arduino directly. Do you think this could potentially be the problem (us getting some stray and random L or C values from the breadboard)? If so I'll work up a more direct connection when I get the chance.

[chamnit]

@tjhub3 : It's possible. There haven't been any posted issues about Grbl's laser mode causing aberrations like you have. AFAIK, it's all working as intended.

Are the aberrations from the leading edge or trailing edge of a laser pass? If it's trailing edge, it possible that the laser signal from the Arduino is not ending when it should. Possibly from L or C values like you state. You could always hook up an oscilloscope to observe the laser PWM pin to see if the signal is not quickly responding.

[tjhub3]

After I posted it dawned on me it matters what side it's happening on.

Due to this picture I'm inclined to say it is happening on the leading edge.

But I seem to remember watching the laser in action and made a vague mental note of it happening on the trailing edge.

When I get a chance and am near the laser I'll figure it out. If it is on the trailing edge then I think that may indeed be the problem!

[nicolas-lang]

The second picture in the first post looks like there might be an issue while decelerating...

I am slightly unsure about the behaviour of grbl in lasermode, but in professional machines the cam often creates lead-in and lead-out moves with the laser disabled (outside of the the engraving area) to avoid variable speed during the rastering, maybe you could try to generate a single line in your cam, manually add lead-in and lead-out, duplicate the line and check if this part of the issue disappears... if it does, your cam is the guilty party, not grbl. btw. check your belts for oscillations, the vertical wave on the left side of the engrave might indicate some wobbling of the belt.

[chamnit]

@tjhub3 : Is there any news on your laser issues?

[tjhub3]

Sorry for the delay in responses.

Shortly after my last post I started going through the machine wire by wire and trace by trace with a scope. I was attempting to find the source of the stray signal causing the mis-firing. I recorded a few somewhat lengthy videos that I planned on posting to YouTube. Videos detailing my troubleshooting/tracing steps.

Before I got to the point of posting I came to the conclusion that my whole setup was improperly grounded. I was getting horrendous loops in certain areas.

So out came all the previous wiring and the rats nest of a perfboard to follow. They all needed replacing.

---

This project was then placed on the back-burner while waiting on some newly special ordered parts.

We got some properly shielded flex cable, a separate power supply to isolate the controller from our motors/laser PSU, we ordered an isolated/shielded Grbl specific breakout board for the Arduino, and we ordered 2x DPRALTE drivers.

Just this week, after a semi-lengthy lead time, we received the final piece of the puzzle in the mail. Our drivers. Extremely flexible little things that we can literally make sing....(Seriously they are fully programmable down to the point of being able to drive a voice coil...) Probably a bit overkill on the driver's part, but we wanted to have options available for experimentation. Those drivers are the jack (and master) of all trades; if you're willing to spend +$650/axis that is...

---

Now we are going through the process of setup and programming the drivers.

As briefly described in my first post, we are attempting to use these drivers in a sort of hybrid stepped-servo schrodinger-looped system.

Up to the point of the drivers we will treat it just like a standard open-looped stepper motor that 99% of Grbl users use. All we will be doing is sending the drivers Step and Direction. In our case, however, the DPRALTE drive will be running an encoded MOOG servo motor. It is up to each axis' DPRALTE to handle the momentary accels/decels to maintain it's own position within the virtually closed loop. If unable to maintain position, or it falls too far outside, it will kickback an error interupt (that I planned on just tying into the limit switch until I can find a more permanent interrupt based solution)

---

Unfortunately with so much "power" comes 10x more documentation and research.

These drivers require you to know pretty much every single piece of info on the motor's data sheet. From the big and easy stuff like Max Current/Max RPM to stuff that I didn't even know existed like Back EMF constants. Considering Epilog does an extremely good job at obfuscating part numbers/descriptions, it was a headache of it's own trying to find the motor specs.

Now that we finally got a hold of all that info we are going through the process of tweaking/optimizing the motors. Fine-tuning our driver's current/accel/etc params.

Hopefully we will have the whole driver/motor situation solved by end of day Friday and we can get back to running our new wiring and hooking up the new YR-CNC breakout board. I have a strong feeling the combination of properly run and terminated shieled cable, isolated inputs, and isolated power supplies, will solve my previous issue.

I'll report back when I get to that point.

---

EDIT:

@nicolas-lang

I would normally agree the waviness/hatching looks like mechanical vibrations. That was one of the first things we double checked. We swapped out the linear bearing + rail with new ones and made sure our belt was acoustically tightened/tuned similar to a guitar string. Didn't seem to have any effect.

It's been a few weeks since I've touched it/ripped it apart so I could be wrong, but I seem to remember that the problem was related to my micro-step ratio and the step-rate itself. The hatching seemed to be worse during accel/decel on lower micro-step rates (>1:5). Almost as if if the jerky magnetic locking action of the stepper was becoming much more noticeable at lower speeds.

As we need to eek out every bit of performance as we can out of Grbl, our steps/mm needs to be as low as possible. Ideally exactly at what would give us a 600PPI equivalent.

This is where the AMC drives come in handy. We can program them to whatever step/rev rate we need therefor ensuring as much performance as possible. We are also taking advantage of the fact that servos do not operate off magnetic steps like stepper motors do; thus in theory giving a smoother, less jerky, movement.

[X3msnake]

Awsome detailed report Master. Thanks for posting. I will keep on the lookout for the follow up on this.

No dia quinta-feira, 15 de fevereiro de 2018, tjhub3 < notifications@github.com> escreveu:

Sorry for the delay in responses.

Shortly after my last post I started going through the machine wire by wire and trace by trace with a scope. I was attempting to find the source of the stray signal causing the mis-firing. I recorded a few somewhat lengthy videos that I planned on posting to YouTube. Videos detailing my troubleshooting/tracing steps.

Before I got to the point of posting I came to the conclusion that my whole setup was improperly grounded. I was getting horrendous loops in certain areas.

So out came all the previous wiring and the rats nest of a perfboard to follow. They all needed replacing.

This project was then placed on the back-burner while waiting on some newly special ordered parts.

We got some properly shielded flex cable, a separate power supply to isolate the controller from our motors/laser PSU, we ordered an isolated/shielded Grbl specific breakout board http://www.yrcnc.com/product/arduino-cnc-isolation-shield/ for the Arduino, and we ordered 2x DPRALTE drivers https://www.a-m-c.com/products/?page=product&cid=root&id=dpralte-020b080 .

Just this week, after a semi-lengthy lead time, we received the final piece of the puzzle in the mail. Our drivers. Extremely flexible little things that we can literally make sing....(Seriously they are fully programmable down to the point of being able to drive a voice coil...) Probably a bit overkill on the driver's part, but we wanted to have options available for experimentation. Those drivers are the jack (and master) of all trades; if you're willing to spend +$650/axis that is...

Now we are going through the process of setup and programming the drivers.

As briefly described in my first post, we are attempting to use these drivers in a sort of hybrid stepped-servo schrodinger-looped system.

Up to the point of the drivers we will treat it just like a standard open-looped stepper motor that 99% of Grbl users use. All we will be doing is sending the drivers Step and Direction. In our case, however, the DPRALTE drive will be running an encoded MOOG servo motor. It is up to each axis' DPRALTE to handle the momentary accels/decels to maintain it's own position within the virtually closed loop. If unable to maintain position, or it falls too far outside, it will kickback an error interupt (that I planned on just tying into the limit switch until I can find a more permanent interrupt based solution)

Unfortunately with so much "power" comes 10x more documentation and research.

These drivers require you to know pretty much every single piece of info on the motor's data sheet. From the big and easy stuff like Max Current/Max RPM to stuff that I didn't even know existed like Back EMF constants. Considering Epilog does an extremely good job at obfuscating part numbers/descriptions, it was a headache of it's own trying to find the motor specs.

Now that we finally got a hold of all that info we are going through the process of tweaking/optimizing the motors. Fine-tuning our driver's current/accel/etc params.

Hopefully we will have the whole driver/motor situation solved by end of day Friday and we can get back to running our new wiring and hooking up the new YR-CNC breakout board. I have a strong feeling the combination of properly run and terminated shieled cable, isolated inputs, and isolated power supplies, will solve my previous issue.

I'll report back when I get to that point.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/354#issuecomment-365842533, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-lYXnUWqws9Nxp14coXTsuvHdegJks5tU9fWgaJpZM4RfAec .

-- Com os melhores cumprimentos, Vinicius Silva

[tjhub3]

Just posting an update.

We finally finished up the tuning process of our servo motors. The process was much more involved than I was expecting...

It involved changing PID values for 6 different motor states. In order they were: tuning it for unloaded straight current, then tuning for an unloaded velocity, then tuning the PID values for an unloaded position following velocity. Then the same 3 things fine tuned while hooked up to a load.

Long story short, it took a few days to get them to stop buzzing/humming, run at a cool temp, and tuned for our ideal raster speed. The way they are tuned (for higher velocities) and geared, the drivers + motors should be able to reliably hold a stepped position up to 1,875mm/s. (Max cont. RPM: 2250, gearing: 20T2.5)

Meaning the Arduino max of ~37.5kStep/s should be able to run max speed @ 500PPI or 1,500mm/s @ 600 PPI. In theory anyway... Perfect speeds for our 120W tube!

Right now we are waiting on our rf tube to be returned. We sent it out to be regassed + refurbed, along with the rf generator, over a month ago. Longer than normal for our usual repair guy, but it should be back soon. I'll post more updates when we are closer to firing the 2.0 version of our Grbl powered engraver.

[chamnit]

@tjhub3 : Thanks for the update.

Keep in mind that at 37.5kSteps/s, you won't be leaving much processor cycles for everything else Grbl has to do. Grbl will probably run ok with vector jobs, but I don't expect close to your expected performance during raster jobs in particular. There are other bottlenecks that will probably limit the execution to something like 500 lines per second at 250 PPI on your 20MHz AVR. I've seen 1200-1500 lines/second at 250PPI on the Grbl LPC (ARM Cortex M3) port, which is the fastest among all open source laser cutter firmwares the last I heard. But, still no where near adequate in my view.

Professional laser cutters have specialized hardware to manage and handle the data throughput required for raster jobs, like direct Gigabit ethernet connections. These bottlenecks exist on other open-source CNC firmwares too, which are based on Grbl. The problem is something intrinsic to how Grbl works, not just streaming bandwidth, which is actually a small factor. I have a plan how to vastly improve this in the ARM version of Grbl, but I've got a pretty long to do list before I get to it. After the improvements are installed, I think Grbl ARM can get close to professional CNC laser speeds on raster jobs.

[tjhub3]

That has been something looming in the back of my head and worrying me. I know there is some overhead + other things to account for other than simply 37.5kSteps/s in the x axis. Unfortunately I haven't gone through the Grbl source code line-by-line/file-by-file yet, so I don't know exactly how it operates and where that overhead comes from.

However, the more and more I think about it the less and less I am worried.

When I say raster it may be a bit misleading. We aren't attempting to do high quality bitmap rastering with varying powers/speeds. We aren't trying to engrave fine detailed pictures.

We specialized in solid-shade logo engraving with a considerable amount of dead/whitespace between logos. A single scanline for us should normally be <100 G0/G1 commands and we are aiming for just under 2 scanlines per second.

Even on our highest density jobs, I'd be surprised if any would peak >250~300 gcode lines/second. Is that what you were referring to?

[chamnit]

@tjhub3 : Yes. Laser jobs that have an average amount of distance traveled per line (guessing about >1.0mm or so) should execute fine. When you get smaller than that, again on average and depends on programmed feed rate, bottlenecks will begin to appear and execution will begin to bog down. Based on what you said, it should work.

[tjhub3]

Greetings!

I'm way over due for an update/post... but I have finally narrowed down where the problem is coming from and it seems to be the generated PWM signal. Not due to noise like I originally thought.

Finding that out required skimming a few GB of data captured by a logic analyzer.

---

My laser (Coherent GEM-100) can be fired in 2 main modulation modes:

1.) CW (DC) modulation using an analog differential RS-422 control signal. 2.) Gated CW (pulse) modulation using an unbalanced 5v TTL PWM signal.

For lack of an RS-422 converter/external DAC to give me the differential analog signal I have decided to use pulsed modulation for now.

When operating in pulsed mode the RF generator expects a TTL signal with a tickle frequency of 1-5000hz. This means in pulse mode the laser can operate with anywhere from 1 pps to 5000 pps.

Since we want as clean (ie as "pulse-free") of an output as possible, we need to drive the laser at as high of a pulse rate as possible. 5khz would easily be acceptable for our speeds/purposes.

Due to the unfortunate lack of a PWM interrupt/timer that could run @ 5khz I've decided to use 3.98khz. This was accomplished by appending cpu_map.h with the following:

#define SPINDLE_TCCRA_INIT_MASK   ((1<<WGM20)  ) // Configures phase corrected PWM mode
#define SPINDLE_TCCRB_INIT_MASK   (1<<CS21) // 1/8 prescaler -> 7.8kHz (Used in v0.9) || 3.9 in phase correct

This seems to give us a clear enough engraved output with individual pulses being nearly indistinguishable from their neighbor. However, we still get the pre-fired dots on the leading edge of the engraving.

---

I hooked up my logic analyzer to see what was going wrong.

After spending quite a bit of time looking for the wrong thing (I was expecting some stray noise/voltage spikes) I have finally found the culprit.

It seems as though, at a random interval, the leading edge's pulse is 2x as wide as it should be. Almost as if the PWM gen combined 2 individual pulses into 1 double-wide monster pulse?

Here is an album of screen shots of the capture from my LA.

https://imgur.com/a/3hx6s

You can see in the second image that the leading edge's pulse is 2x the width it should be. This in turn causes the laser to fire with 2x the power ~1 pulse earlier than it should.

Is this some sort of math/rounding error that is mistakenly combining the end of one pulse with the beginning of the next pulse?

[chamnit]

@tjhub3 : Thanks for the thorough report. I suspect this might be an issue with the PWM counter overflowing. I'll take a quick look at this.

[ThiagoCNC]

Hi, I need 5Khz but I'm not able to configure GRBL 1.1.

I made some changes as below, but I did not get improvements in the power of the 2.5W laser.

How do I make the change? Does this also influence laser power?

define SPINDLE_TCCRA_INIT_MASK ((1 << WGM20) | (1 << WGM21)) // Configures fast PWM mode.

   // #define SPINDLE_TCCRB_INIT_MASK (1 << CS20) // Disable prescaler -> 62.5kHz    // #define SPINDLE_TCCRB_INIT_MASK (1 << CS21) // 1/8 prescaler -> 7.8kHz (Used in v0.9)    // #define SPINDLE_TCCRB_INIT_MASK ((1 << CS21) | (1 << CS20)) // 1/32 prescaler -> 1.96kHz    #define SPINDLE_TCCRB_INIT_MASK (1 << CS21) // 1/64 prescaler -> 0.98kHz (J-tech laser)

Thank your help

[Fusseldieb]

Any progress for this issue, @chamnit ?

[chamnit]

@Fusseldieb : Unfortunately no. Had a lot of things come up, but will get to this asap.

[gn3481]

Did this issue ever get looked at ?

Thanks !