Alarm: 3 Reset while in motion

I have an atomstack 5w laser that recently throws an Alarm 3 error and the laser won’t move after that. If I run the job there is no problem, only if I try to frame or move the laser does the error occur. Verified grid size, reset GRBL, using absolute coordinates. When selecting “Get Position” the coordinates do not match up. New user so I am sure it is a setting I am not understanding. Any suggestions would be helpful. Thanks.

Does the Atomstack home on it’s own or do you have to place it?

If you google ‘grbl alarm 3’ you can find what the error means.

Here’s a list Grbl v1.1 Interface · gnea/grbl Wiki · GitHub

For some reason, like it hit a limit switch, the operation was aborted.

Before or after the error?

:smile_cat:

I have to manually home the laser. The coordinates do match up after the error. From the research that I have done, I am wondering if somehow I set my work area in the negative.

Strange part is laser moves as expected in GRBL

1 Like

Can you power on with laser at front-left and run these commands in Console? Return results please?

$I
$$
$#
?

Thank you for helping!
[VER:1.1f.20170801:]

[OPT:VI,15,128]

Target buffer size found

ok
[VER:1.1f.20170801:]

[OPT:VI,15,128]

Target buffer size found

ok

$$

$0=10

$1=25

$2=0

$3=0

$4=0

$5=0

$6=0

$10=1

$11=0.010

$12=0.002

$13=0

$20=0

$21=0

$22=0

$23=0

$24=25.000

$25=500.000

$26=250

$27=1.000

$30=1000

$31=0

$32=1

$100=80.000

$101=80.000

$102=250.000

$110=6000.000

$111=6000.000

$112=1000.000

$120=1000.000

$121=1000.000

$122=10.000

$130=410.000

$131=400.000

$132=200.000

ok
[VER:1.1f.20170801:]

[OPT:VI,15,128]

Target buffer size found

ok

$$

$0=10

$1=25

$2=0

$3=0

$4=0

$5=0

$6=0

$10=1

$11=0.010

$12=0.002

$13=0

$20=0

$21=0

$22=0

$23=0

$24=25.000

$25=500.000

$26=250

$27=1.000

$30=1000

$31=0

$32=1

$100=80.000

$101=80.000

$102=250.000

$110=6000.000

$111=6000.000

$112=1000.000

$120=1000.000

$121=1000.000

$122=10.000

$130=410.000

$131=400.000

$132=200.000

ok

$#

[G54:0.000,0.000,0.000]

[G55:0.000,0.000,0.000]

[G56:0.000,0.000,0.000]

[G57:0.000,0.000,0.000]

[G58:0.000,0.000,0.000]

[G59:0.000,0.000,0.000]

[G28:0.000,0.000,0.000]

[G30:0.000,0.000,0.000]

[G92:0.000,0.000,0.000]

[TLO:0.000]

[PRB:0.000,0.000,0.000:0]

ok
?
<Idle|MPos:194.900,11.363,0.000|FS:0,0>

ok

Can you confirm that you ran this immediately after powering on? If so, not sure how this is happening but your laser position is not 0,0 which is what I feel like it should be. This also shouldn’t generate an Alarm:3. What’s odd is I see no reason why this should be the case.

Let’s try at least try getting you back to 0,0.

Can you power cycle the laser again at front-left then run this in Console:

G92 X0 Y0

Power cycle and then rerun these commands please:

$#
?

Please send back results. Also test and see if the behavior has changed. Not sure if this will make a difference but worth a shot. It shouldn’t do harm.

$#

[G54:0.000,0.000,0.000]

[G55:0.000,0.000,0.000]

[G56:0.000,0.000,0.000]

[G57:0.000,0.000,0.000]

[G58:0.000,0.000,0.000]

[G59:0.000,0.000,0.000]

[G28:0.000,0.000,0.000]

[G30:0.000,0.000,0.000]

[G92:0.000,0.000,0.000]

[TLO:0.000]

[PRB:0.000,0.000,0.000:0]

ok
?

<Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>

ok
If I run the laser it works perfectly but if I frame or use the move buttons the laser freezes and coordinates do not match. Thanks for the suggestions.

Can you take a screenshot of the coordinates not matching and the exact error message generated?

When I power on the laser is at X0 Y0. If I frame a project the laser goes to starting coordinate and freezes. This is the error created.
ok
Starting stream
Stream completed in 0:00
ALARM:3
Reset while in motion. Grbl cannot guarantee position. Lost steps are likely. Re-homing is highly recommended.
Grbl 1.1f [’$’ for help]
[MSG:’$H’|’$X’ to unlock]
[MSG:Caution: Unlocked]
ok
Then if I move laser back to X0 Y0 - get posistion it reads X=109.13 Y=12.2 Z=0 U=0


Place job in center of workbed and laser remins at X0 Y0 but lightburn shows laser as center.

Can you take screenshots of your Move window and Device Settings window?

I think for some reason your stepper is losing steps.

Sure. start at x0 y0 hit right arrow this s what comes up - included device settings too.

I don’t see anything too unusual here. Do you hear any odd noises when you try framing? Do you hear the motors struggling or buzzing when you try framing? It seems like somehow the controller is out of step with the steppers but nothing seems off to me.

One question, was your speed setting in Move window always 6 mm/m? Are your jogging moves extremely slow?

Just to confirm, you have absolutely no issues when running any job? It’s literally only during framing and moving that you see this issue?

If so, can you run a grid of evenly space squares? Want to make sure you don’t have any issues, particularly with the distance between squares potentially changing. Also, want to see if your coordinates lose track when running a regular job.

The link I posted has this to say about that error

Reset while in motion. Grbl cannot guarantee position. Lost steps are likely. Re-homing is highly recommended.

I wonder how grbl would know it has lost steps…?

:smile_cat:

GRBL is indicating that it cannot guarantee steps and so likely lost. Not that it actually knows that steps were lost. It cannot account for lost steps but also cannot account for all steps, so assuming worst case.

@mizfitcycle Try swapping out the USB cable and/or switch USB ports. It’s possible this is an electrical issue but would be odd if it only affected framing and move operations but not regular jobs.

Thanks for your help troubleshooting. I think I am just going to frame my work using low power to ensure correct placement. Here are the squares, job runs fine but I do have to power down and reset after each pass. Which is fine. I do appreciate you looking into this. I should be fine moving forward, I will bypass the framing.

I understand the English.

What I’m questioning is how would it know this occurred in the first place. The controller can’t complain unless it knows or suspects… What ‘signal’ triggers this response.?

There is nothing that I know of in the hardware I’ve looked at that allows the machine to know what has happened at the motor.

On all of my machines, you can leave the motor supply off and the machine will run the whole job… no errors … there are obviously missed steps if there is no power to the motors…

I don’t understand what would actually triggers an alarm 3, other than running into a limit switch… which he doesn’t have… At least on these machines.

@mizfitcycle it should still work correctly… Give @berainlb a chance to help you get a handle on it.

Good luck

:smile_cat:

It perceives a soft reset. It didn’t expect this while in motion which triggers the alarm. Under this condition steps cannot be guaranteed.

This is not about it knowing something happened at the motor. It’s simply saying something happened while in motion that probably means steps cannot be counted on. GRBL knows about the controller state in this case, not motor state. But it does know motor state can’t be counted on.

How? Psychic?

I’m just trying to understand where the ‘perception’ came from.

I can’t think of how it would know anything was a problem unless the machine operation triggered a limit switch… no limit switches here.

Thanks… I know I can be frustrating when I’m lost over something simple like this.

:smile_cat:

It’s literally detecting a soft reset message… I used “perceive” because it wasn’t sent deliberately but somehow registers one. Seems like a ghost signal.

The detection of the signal was not a problem identification… just an acknowledgement. The warning about missed steps was anticipatory based on the circumstances.