Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Laser mode spindle enable after pause #43

Closed
MadTooler opened this issue Dec 3, 2022 · 7 comments
Closed

Laser mode spindle enable after pause #43

MadTooler opened this issue Dec 3, 2022 · 7 comments

Comments

@MadTooler
Copy link

MadTooler commented Dec 3, 2022

When sending from UGS and rp2040 grblHal in laser mode, my M3 spindle/laser does not reactivate properly when resuming from a pause/halt of a program. It appears it will finish the rest of the g01 line it was halted within, then reactivate the spindle at the next g01. This means short distance segments are less noticeable in the issue as long segments.

I am not sure if this is UGS or grblHal issue, but my thinking is it may be in grblHal.

I also notice some of the same issue as noted in grblHal core issue #99 where the spindle/laser starts at the initial g00 of my program if the M3 S1 is set before the g00.

@terjeio
Copy link
Contributor

terjeio commented Dec 4, 2022

This is a bug, can you try with changing:

https://github.com/grblHAL/core/blob/d10804433c2b1060bb8ad6c5fa04218c2cf435a8/state_machine.c#L564

to

            step_control_t step_control = sys.step_control;
            state_set(STATE_IDLE);
            sys.step_control = step_control;

?

I also notice some of the same issue as noted in grblHal core issue grblHAL/core#99

Do you have an example for this? There is a bug but that will only show up if the G1 motion programmed after the G0 has the same target.

@MadTooler
Copy link
Author

I tried the suggested change to state_machine.c and it appears to work. Thanks!

Do you have an example for this? There is a bug but that will only show up if the G1 motion programmed after the G0 has the same target.

While checking on this issue, I did find some of the troubled gcode did g0 to same coordinate as the following g1. The CAM posting is a bit odd from the software I am trying (inkstitch out of inkscape). When I removed the like lines, the issue did not appear to occur again. Even odder, this was before I made the change noted above to state_machine.c. During that test, I could not get the above restart issue to occur on the longer straight sections of that gcode, in which they happened to be single axis changes (example x1y1 to x0y1). I am wondering if there was also an element for the restart issue to occur, it needed to be a coordinated change to multiple axis. Either way, it seems better for now.

Somewhat related non bug, at some point I may need a short delay for the spindle/laser to start and restart. Is this possible within the current setup?

Thanks again. Your impressive work is making my project look good;)

@terjeio
Copy link
Contributor

terjeio commented Dec 5, 2022

... I may need a short delay for the spindle/laser to start and restart. Is this possible within the current setup?

If you cannot use G4 then no - and it might be difficult to add for laser mode as the PWM value is set by the step interrupt handler.

@MadTooler
Copy link
Author

I could use G4 at the beginning of the program, but I don't see how for a pause/start case. For now, it does not seem needed while all of my gear behaves.

@terjeio
Copy link
Contributor

terjeio commented Dec 5, 2022

... but I don't see how for a pause/start case.

I could add a pre state change event you could subscribe to in a plugin.

@MadTooler
Copy link
Author

... but I don't see how for a pause/start case.

I could add a pre state change event you could subscribe to in a plugin.

For now, all works well without the delay. My potential need is based on a concern the rpi node-red doing the task of "spindle" starting in laser mode (not actually a laser) may get delayed in processing by other tasks. When it is running well, there is no problem. I was only thinking of adding some insurance since the different processors I am using run open loop from each other.

That said, I wouldn't chase a solution as you suggested unless you think others will benefit now.

@terjeio
Copy link
Contributor

terjeio commented Jan 26, 2023

Fix committed.

@terjeio terjeio closed this as completed Jan 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants