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

how to continue from interrupted operation? #153

Closed
itxitx opened this issue Nov 4, 2017 · 4 comments
Closed

how to continue from interrupted operation? #153

itxitx opened this issue Nov 4, 2017 · 4 comments

Comments

@itxitx
Copy link

itxitx commented Nov 4, 2017

At times i got malfunction in the power or the hard limit somehow hit accidentally in the middle of operation. i found it's impossible to continue from the last position of the operation. continue from the start has 2 drawbacks : too much scorching (uneven result between double burn and single burn) and wasting times.
any suggestion on how to do it?
i usually worked on gcode that using G90 or absolute positioning, so i can simply edit the g-code and delete operations that i have done, so no need to repeat what i have done before in the previous operation.

@arkypita
Copy link
Owner

arkypita commented Nov 4, 2017

Hi @itxitx
This is a very good question! This is also match with something that is already in my mind in this days.
When this appens to me I usually act as you, I edit the file to begin t the very first line non already executed by grbl.

I think that in this scenario LaserGRBL should offer a choiche to "continue from last position" Instead of resetting and start from beginning.

This could be easy to do, expecially for absolute movement, with the only small risk that you could not be exactly sure of what is the really last command grlbl executed (maybe you disconnect and miss some "ok" and some state (last state of laser ON/OFF, speed...) could be missing.

More difficult in relative mode because if you don't match exactly the line to starting from, you add an offset and you waste your result.

@arkypita
Copy link
Owner

arkypita commented Nov 4, 2017

There is also an idea in my mind about grbl "hang" detection and recover.
I see that sometime grbl stop responding, or self reset. This usually appens on poor arduino clones or stressed condition where some data is corrupted during tx-rx.

I am thinking about detection and recovery (if possible, I am not able to do miracles) to made LaserGRBL not only the faster grbl streamer but also the more robust avilable.

@itxitx
Copy link
Author

itxitx commented Nov 4, 2017

i'm looking forward to the improvement ... thanks

i'm suggesting that the program gives the line number of the gcode file, so i can locate what's where easily. For the problem i was facing, i edited the gcode file, and set S0 in everything that has been executed in the previous operation. so there's no double burning. but simply finding the last line of the previous operation that got interrupted is difficult.

@arkypita arkypita mentioned this issue Nov 7, 2017
83 tasks
@arkypita
Copy link
Owner

arkypita commented Nov 9, 2017

Please join #161 and give me your feedback

@arkypita arkypita closed this as completed Nov 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants