Laser On-Off Timing

[timothy-godfrey]

Hello!

I'm working on trying to get my laser cutter to cut accurately in a backwards-and-forwards 'scan line' toolpath in laser mode, similar to the movement in an engraving application. I'm getting some confusing results though. In a test that I've been running, it looks like the laser is turning off too early, and turning on again too early.

I've attached some photos of the test below. Each line is three consecutive G1 movements, each movement 100mm long, with the spindle powered in M3 mode, cutting from left to right. The cut movements are programmed with an increasing 's' setting (I was looking to see if the behaviour was power dependent), and the non-cutting movement is programmed with an S0 command. The feedrate is 20m/min. The perpendicular lines are etched at 100mm and 200mm as a reference.

The spindle setting changes are consistently too early. What is confusing about this is that if the laser tube switching frequency was too low, one would expect the opposite behaviour, ie the cut would (possibly, if the laser had a long decay time) turn off too late and (more likely) turn on again too late. Any insights into what could be causing the behaviour I'm getting in the test?

While I have been working on solving this problem I have been experimenting with SPINDLE_PWM_OFF_VALUE, to see if it changes the performance of the on-off timing. At the moment I can't see that it is causing any difference; neither in the laser cutting performance, laser tube current, or measured with a voltmeter at the spindle PWM pin. (Certainly no improvement to the on-off timing in the test cut). In laser mode ($32=1) with G1 motion mode, M3 constant laser power mode, S0, laser tube current is 0 mA rather than ~5% (~2 mA) that I expected to get (with SPINDLE_PWM_OFF_VALUE 16). Is there something I'm not understanding?

All help warmly received, thanks!

---

Config I have used the fit_nonlinear_spindle.py script to calibrate the laser tube. Calibration curve is below Linear fit from the script (scaled to have s commands from 0 to 1000) Solution from the script (that I put into config.h and cpu_map.h)

SOLUTION:

[Update these #define values and uncomment] [ENABLE_PIECEWISE_LINEAR_SPINDLE in config.h.]

define N_PIECES 2

define RPM_MAX 1011.6

define RPM_MIN 7.2

define RPM_POINT12 145.1

define RPM_LINE_A1 6.526415e-02

define RPM_LINE_B1 -1.553319e+01

define RPM_LINE_A2 2.654261e-01

define RPM_LINE_B2 1.350105e+01

[To operate over full model range, manually write these] ['$' settings or alter values in defaults.h. Grbl will] [operate between min($30,RPM_MAX) and max($31,RPM_MIN)] $30=1011.6 (rpm max) $31=7.2 (rpm min)

[Update the following #define values in cpu_map.h]

define SPINDLE_PWM_MIN_VALUE 16

I have also set SPINDLE_PWM_OFF_VALUE to 16.

I'm using grbl 1.1f. My grbl config is

$0=10 $1=255 $2=0 $3=3 $4=0 $5=0 $6=0 $10=1 $11=0.040 $12=0.002 $13=0 $20=1 $21=0 $22=1 $23=3 $24=1000.000 $25=5000.000 $26=250 $27=5.000 $30=1012 $31=7 $32=1 $100=20.810 $101=20.810 $102=80.000 $110=60000.000 $111=60000.000 $112=600.000 $120=2000.000 $121=2000.000 $122=300.000 $130=1400.000 $131=1000.000 $132=180.000

[chamnit]

@timothy-godfrey : Sorry about the late reply. This issue thread fell off my radar. This almost looks like some slo/backlash in your machine drivetrain, but it's hard to tell since you are running everything in one direction. How does speed and/or direction change this?

[timothy-godfrey]

@chamnit no worries regarding the late reply. It's gone onto the back burner for me; so sorry for my slow reply too. I will redo some tests cutting in alternating directions and at different speeds, and post the results.

[timothy-godfrey]

So, I have run the tests again with a few modifications. This time the test file cut in both directions, and the test cuts were 20mm long instead of 100mm long (just to save time and paper). The test pattern is

• M3 S400 and feed rate starting at F5000, laser mode enabled.
• G1 cut movement 20mm in +ve Y direction.
• G1 cut movement 20mm at S0 in +ve Y direction.
• G1 cut movement 20mm at S400 in +ve Y direction.
• move over 2mm in X direction
• repeat the three cut movements in the negative Y direction.
• There are horizontal lines cut at Y20.0 and Y40.0 for reference. That pattern constitutes one up-and-down pair. The test file cuts five pairs, and then moves an extra 3mm and increases the feedrate by 1000mm/min. The feedrate for each group is written below the group (in m/min). .

The overall trend that was present in the last test is present again (I think): the laser appears to turn off too early and turn on too early. I don't think it is a backlash issue, because I don't have any problems when I run other backlash tests (cutting circles etc.), and because the start and end points of the test cuts are all nice and even (repeatable) in the Y-axis. Running the test with increasing feedrate seems to show that the problem gets worse with increasing feedrate. Perhaps this indicates that it is a 'constant time' problem (in contrast to 'constant displacement').

I'm happy to do more testing if there are any requests/suggestions. All input warmly received.

Thanks! Tim

[timothy-godfrey]

Hello @chamnit. Just a friendly bump in case my updates to the issue didn't make it onto your radar. Looking forward to your input, thanks!

[chamnit]

@timothy-godfrey : Thanks for the friendly bump. I'll try to look into as soon as I can. Things have become unexpectedly crazy at my day job the last couple of weeks.

[PhysicsAnonymous]

I'm having the same problem. Mine shows up even more because i have higher feed rates. I'm running an etching job at 50,000 mm/minute with 20mm of over scan to rule out acceleration as a problem and i get a 6mm separation between the lines that run left to right, and the lines that run right to left. it seems there is some delay between the laser firing and the motors moving. the laser seems to be firing a head of the motor commands by 7 milliseconds if my math is correct.

[chamnit]

@PhysicsAnonymous : Just a clarification. Your are running Grbl-LPC so there might be something else involved with your case. Either way, I noticed that both you and @timothy-godfrey are using M3 commands. Is there any difference when you M4?

EDIT: @PhysicsAnonymous Mixed you up with another similar issue related to laser timing, but the question is the same. Is there any difference with M3 and M4.

[chamnit]

@timothy-godfrey : With regard to the PWM off value being changed, I think this is a bug. The spindle PWM output is disabled automatically when the spindle is off. This results in a 0V output. Not sure what to do about it as at this point, other than pushing it off to the next major version, because it may alter how certain things work for existing machines. It could open a bigger can of worms.

[chamnit]

@timothy-godfrey : Can you tell me if you get the same timing error with running the same job with each axis? If it’s Grbl it should show the same error at the same speeds. If not, then it may be something else.

[mayhem2408]

@chamnit @timothy-godfrey Just my 2 cents here. I had a problem similar to this with a Chinese K40 laser. I found that there was a delay in the stepper motor driver. I replaced the cheap driver with a higher quality driver and the problem went away. I was not related to the controller itself. Just food for thought.

[PhysicsAnonymous]

@chamnit sorry to confuse you with multiple threads. i just saw someone with the same problem as me, and i figured i would make sure he knew he wasn't alone ;) indeed I am running GTBL-LPC, so it might be another problem. Also i have tried it with both M3 and M4, same result.

@timothy-godfrey does your problem look something like this? https://www.youtube.com/watch?v=KmOhYRa-nv0&feature=youtu.be

[chamnit]

@timothy-godfrey : FYI. I ran a step counter test on the AVR version of Grbl. The test involved moving X+20 at no power, X+100 at full spindle, X+20 no power, X+100 full spindle, and another X+20 at no power. Then reverse. Speeds ranged from 5000 to 40,000 mm/min.

I found the spindle signal fired and shut off exactly on the same step counts regardless of speed.

This was for the standard Grbl build. Other than using the nonlinear fit code, you'll need to tell me of any other build options you enabled so I can do a one-to-one test. I'm not expecting any issues.

[timothy-godfrey]

@mayhem2408 Thanks for sharing your experience. Good to consider.

@chamnit good suggestion running the test on the other axis: I ran these tests at 40m/min with no change in the feedrate or power as the test progressed. The error seems to be larger on the Y axis than the X axis, which is interesting because I do have different drivers on the X and Y axes. Considering your test with the spindle signal firing and step count producing a reliable result, perhaps my problem is not an 'early' laser, but 'late' stepper motor drivers (would produce the same result). When I used M4 on the test, using the same spindle speed setting. the laser lines only barely marked the paper.

@PhysicsAnonymous I haven't done any engraving, so I haven't produced a result like the one in the video. I was cutting co-linear lines in a vector job in scan-line passes, so the error that I was getting was that my corners weren't joining.

[chamnit]

@timothy-godfrey : Good to know. I also recompiled Grbl this morning with your nonlinear spindle settings. Although I could only test with full power on due to the digital output (and me being lazy and not wiring in a capacitor and re-writing the code to read the PWM as analog), it worked fine. The spindle signal still fired at the same step counts regardless of speed.

[langwadt]

springy belt drive? so movement can stop/start late/early depending on how the belt tension/relax?

[chamnit]

@langwadt : That's definitely a possibility. Even if it's tight, the belt has the same stiffness, but usually this should only move 0.001" or so at worst, especially on a light weight laser machine. One way to eliminate this as a variable is to make sure the laser head is traveling at a constant speed during cuts by adding a lead in and out motion for each pass.

[PhysicsAnonymous]

I considered the belt tension as well. I am using some pretty thin belts on my set up. but in my engraving tests i had enough lead in and lead out to eliminate that as a possibility. I think @timothy-godfrey is right about the motor drivers being delayed. When I went from external drivers to the built in ones on my MKS board I got a significant improvement, but the problem was still there. @chamnit I think you are also right that the code is spitting out the laser fire signal at the exact same time as the motor signals, but the motor drivers need a small amount of time to "process" the data. It also seems like that amount of time can change pretty drastically depending on the driver. (I calculated my external drivers to be about 7ms delay, and the MKS board to be about 1ms)

It seems to be that the obvious answer is to build in a delay variable that can be tuned in for each motor driver. From what i have read, this isn't uncommon for other laser software.

[chamnit]

Unfortunately adding an accurate time delay for either the stepper or spindle will require quite a bit of refactoring. I could keep this in mind for later versions.

However, there will need to be some kind of validation of this problem. I wonder if there is repeater device that can delay the spindle signal for you to test this. It’d be tricky to write one for an Arduino but it’s doable. Perhaps there is one already published if your lucky.

It seems weird to me that a stepper driver would have that much of a delay. It should be microseconds not the milliseconds range. Perhaps it’s present in the budget ones but not the typical TI and Allegro IC drivers common on Grbl type CNCs.

[langwadt]

as long as the laser need to be delayed (and the time is a multiple of the pwm period) couldn't it simply be done by enabling the interrupt on the pwm timer and have a short ISR that count cycles before enabling or disabling?

milliseconds is ages for anything electronic, but I don't think it is far fetched that the mechanical bandwidth of steppers and hardware is in the low kHz range

[chamnit]

Closing this issue, since it seems like Grbl is providing the laser signal on time. @PhysicsAnonymous verified that introducing a laser signal delay program eliminated the timing issue completely here. This is seemingly caused by the poor response time of budget stepper drivers. In future version, I can look into adding a delay that Grbl controls, but it'd be a bit hairy to do right.

We can reopen this if there is more proof showing that this isn't the case.

[timothy-godfrey]

Hi all. Thanks for sharing your insights. I thought I should point out for completeness that the motor drivers on my Y axis are not budget stepper drivers but are Panasonic Minas servo motors and motor drivers. So while the servo motors are exceedingly accurate and powerful, it seems there are also some 'fit for purpose' considerations to weigh. My first guess is that there is some digital filtering in the servo motor driver that is adding a delay. A distance error of approximately 1mm at 40m/min is equivalent to a time delay of approximately 1.5ms, which is kind of large but within the realm of conceivability. The X axis stepper driver is an external high power module, so it too might be optimised for an alternative use case (high-power-low-speed);

I will have to dig around in the settings and see if I can reduce any delays. I'll post back if I discover anything interesting.

[chamnit]

@timothy-godfrey : Fair enough. I'll make sure to add a laser delay to the development list for future versions to accommodate motor drivers like yours.

[PhysicsAnonymous]

here's the code we used to delay the laser firing signal. https://drive.google.com/drive/u/1/folders/1O_6vE8vBIstp4J8dbozfsC1wr1kFVybs for more info on how we wired it up, you can check out this video: https://www.youtube.com/watch?v=PnpIq6Br-ss

[timothy-godfrey]

Hello @chamnit, more details for completeness. It turns out that I had incorrectly remembered the details of my laser cutter. The X and Y axes have identical Panasonic servo motors and drivers; The Z axis is the one with the different external driver module.

I did manage to find the settings that affect the delay of the stepper motors, and it had different values configured for the Y and X axes, which explains the different performance I was getting in my tests. I adjusted the settings to zero and now I get no latency (or at least much less) from the servo motors and drivers.

Cheers!