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

Feature: The ability to exit out of a Macro mid script #1318

Open
rvalotta opened this issue Sep 11, 2024 · 13 comments
Open

Feature: The ability to exit out of a Macro mid script #1318

rvalotta opened this issue Sep 11, 2024 · 13 comments
Labels
enhancement New feature or request

Comments

@rvalotta
Copy link
Contributor

Machine Context

With the recent addition of Flow control the ability to bail out of the script if certain conditions are met would be helpful.

Feature Description

LinuxCNC documents M99 which is documented as returning from a numbered program

https://linuxcnc.org/docs/html/gcode/o-code.html#ocode:fanuc-style-programs

Usually it is used along side M98 but as there is no support for functions numbered or otherwise it can be omited... The same code is supported by GRBLHal as well

Other Approaches

Not sure how else to do this outside adding the functionality to the macro processor

How I Can Help

I can provide code examples to test with

@rvalotta rvalotta added the enhancement New feature or request label Sep 11, 2024
@MitchBradley
Copy link
Collaborator

Would an IF construct that ends at the end of the file or macro do the job?

@rvalotta
Copy link
Contributor Author

rvalotta commented Sep 11, 2024

Some examples that could be applied for a tool change macro.

  • If the current tool = the new tool just exit
  • If the current tool is less than 0, exit
  • If the settings are not appropriate, exit

You can see this being used in the following script for the rapidchange atc that was developed for grblhal.
https://github.com/greilick-industries/rcatc-scripts-grblhal/blob/main/macros/TC.macro

yes if's could be used to encapsulate the whole function but it would not be as clean or easy to read

@MitchBradley
Copy link
Collaborator

We don't support subroutines inside of files or macros. The entire file or macro is treated as a unit, i.e. a subroutine. I'm not sure to what extent M99 depends on the smaller-than-file subroutine construct. What do you think?

@rvalotta
Copy link
Contributor Author

It is being used only to short circuit the gcode incase something isn't right... I mean if could be re-written to its is nested if / else but I believe its harder to read at that point...

@MitchBradley
Copy link
Collaborator

If something goes wrong, what should happen in the calling context? Should it continue on or should the exit propagate, as with an alarm?

@rvalotta
Copy link
Contributor Author

M99 Should just return the the calling script or exit out if there is no calling script.
M30 (Which is implemented) is a program end

So if new tool equals current tool just return back and continue to run the code from where you left off and not evaluate the rest of the programming.
M30 would be the one that is used to exit the program... Off to report that bug to the developer of the script i linked above realizing the mistake that was made there :)

Neither of them need to throw an error as a print can be used to display what is going on at each so the user is aware.

@MitchBradley
Copy link
Collaborator

So if new tool equals current tool just return back and continue to run the code from where you left off and not evaluate the rest of the programming.

"continue to run the code from where you left off" and "not evaluate the rest of the programming" seem contradictory.

@rvalotta
Copy link
Contributor Author

If you think of it in terms of M6_macro a M99 would resume running your gcode while a M30 would end it and not continue the original gcode that called the tool change.

@MitchBradley
Copy link
Collaborator

MitchBradley commented Sep 11, 2024

If M99 is used in the case where "something isn't right", shouldn't that information be propagated to the caller? Suppose that I have a macro like "prepare_for_tool_change" that, say, docks the dust shoe. That is in turn called from a higher level "do_tool_change" macro. If "prepare.." fails and executes M99, shouldn't "do.." also fail?

@rvalotta
Copy link
Contributor Author

I've seen people to (print, with a error message) more so then a complete failure

@rvalotta
Copy link
Contributor Author

Not when you think of it as the M6 T2 in your gcode is calling another script. Continue to run the code refers to the original gcode that was called. Not evaluate the rest of the programming refers to the code below the M99 that does not need to run

Hope that clears it up

@bdring
Copy link
Owner

bdring commented Sep 12, 2024

It seems like you could do what you want with the proper nesting of if statements.

With that said, the fail case is an important one. Currently gcode or FluidNC can generate errors, like soft or hard limit alarms. FluidNC cannot proceed safely when an alarm happens, so it kills all jobs.

We currently do not have an elegant way to force an alarm with a gcode conditional. Say you want to alarm out if someone asks for a tool position that does not exist. We have no way to do that other than hacking a gcode alarm condition.

We might want something like M30 P<alarm?>

@MitchBradley
Copy link
Collaborator

$Alarm/Send=5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants