G code conditional execution (possibly looping)

[andrewmarles]

I think these are the key things are are left to make the macro functions in GRBLHAL transformative for the platform - and this is currently the biggest difference between GRBLHAL and other platforms with branching macros like Reprapfirmware and linuxcnc.

Implementing this functionality in the controller is inherently difficult because of the buffered nature of the GRBL interpreter and the fact that it does not keep track of where it is in the execution. But I think that since the macro functions always have the complete g-code it might be possible to track the current line being executed and manage branching that way?

Just throwing the topic out there for discussion.

[terjeio]

It is on my radar for macros...

I know I possibly opened a can of worms by adding G65 (call macro) support, there are several inherent problems related to this that I am aware of. Conditional execution and looping is one set, error handling and reporting another - both can be overcome.
A harder one is that a sender cannot know what is going on inside a macro without uploading it - and this will, IMO, be tough to get sender developers to implement. But then calling macros from gcode is likely to be used for probing, tool changes and the like, not cutting, so not a big deal?

It would be nice to hear about use cases that can be solved by G65 macro calls, especially those who would benefit from conditional execution and looping. Advanced probing with proper error handling is one?

A bit of background: grblHAL is the only Grbl variant that I am aware of that supports variables (parameters) and expression in gcode as an option. When enabled G65 macro calls can be made a lot more flexible than with plain gcode.

[andrewmarles]

The main thing that I am thinking about is an ATC plugin where everything can be done via macros instead of C code. This is because there are about 500 different ways of doing ATC, and everyone will want something different. Right now it could be done with the existing macro plugin but forward only, with no feedback from sensors for the tool-clamping or dust hood. So today I am having to do this in C code and while I can come up with something relatively generic using IOPorts with flexible assignment, you can be certain that someone will want something different as soon as it hits Github.

Passing variables with G65 is almost exactly what I would want for the above implementation, the only thing missing is conditional execution so that the user can script (via G62-68) to set outputs and check the sensors and issue a HALT if there is something wrong.

[terjeio]

The main thing that I am thinking about is an ATC plugin where everything can be done via macros instead of C code.

This means it should be possible to hook macros into M6 and M61 execution... A plugin? $-setting options?

[andrewmarles]

The main thing that I am thinking about is an ATC plugin where everything can be done via macros instead of C code.

This means it should be possible to hook macros into M6 and M61 execution... A plugin? $-setting options?

Yes, this would be the current approach and it works for many aspects, but it can't check a sensor and take alternative action. I don't think there is currently a way for a macro to do something like:

M62 P0 (activates the tool clamp)
M66 P0 L3 Q3 (waits up to 3 seconds for the tool clamp sensor to read high)
if <#5399 EQ -1> (checks that wait didn't time out)
     G65 <tool_change_error.nc> (execute failure macro)
else
(continue tool change macro)

So the logic for the above needs to be implemented in C code in the plugin using IOports.

[andrewmarles]

The main thing that I am thinking about is an ATC plugin where everything can be done via macros instead of C code.

This means it should be possible to hook macros into M6 and M61 execution... A plugin? $-setting options?

Yes, this would be the current approach and it works for many aspects, but it can't check a sensor and take alternative action. I don't think there is currently a way for a macro to do something like:

M62 P0 (activates the tool clamp)
M66 P0 L3 Q3 (waits up to 3 seconds for the tool clamp sensor to read high)
if <#5399 EQ -1> (checks that wait didn't time out)
     G65 <tool_change_error.nc> (execute failure macro)
else
(continue tool change macro)

So the logic for the above needs to be implemented in C code in the plugin using IOports.

Now that I think on it, as an interim step you could probably just make a custom ATC M code that reads an input for a specific value (with or without timeout?) and performs a test and halts the system on failure.

[andrewmarles]

Also, I personally don't think it is worth holding back GRBLHAL to maintain compatibility with plain GRBL senders. The sender developers that I know (bCNC updates for example) would be very interested in supporting more advanced features like this. As long as there is reasonable feedback to the sender that the controller is executing an sd or internal macro I think they will be generally supportive as it makes the whole package more interesting for users.

[terjeio]

Well, first steps first- conditional execution as step #1. This may take some time - summer is getting closer and I have other tasks I want to complete...
In the mean time it would be nice if someone could create some relevant examples for me to play with.

[andrewmarles]

Well, first steps first- conditional execution as step #1. This may take some time - summer is getting closer and I have other tasks I want to complete... In the mean time it would be nice if someone could create some relevant examples for me to play with.

Agree. Never enough time to get all the things done that I want to. The present framework with IOPorts (need to play with the new API) and macros is highly adaptable. There are advantages to a simpler plugin using C as it is easier for people to just flash and use it.

[terjeio]

Well, I took a peek at the LinuxCNC documentation and decided to go for it - seemed easier than I first thougth...

if, elseif, else and endif can even be used when streaming from a sender if the sender accepts the commands (ioSender has to be updated first). Looping is also supported but I have yet to test break and continue, with some luck these statements will work.
I have also added two grblHAL specific statements: alarm <expression> for raising an alarm and error <expression> for returning an error. All statements has to be prefixed (labeled) with the o word and a number in LinuxCNC fashion.

The implementation has a static stack 10 levels deep, this should be more than enough for most uses. Note that I have not yet added a stack overflow check.

Be aware that I have only tested this very briefly, I leave it to users to continue testing. Please add any failing macros to a comment in this discussion so I can use them to debug the implementation.

Some simple (and silly) examples I have used for testing:

P200.macro (this should work from a sender):

;G65P200X3
o100 if [#24 EQ 1]
G0X[#24*2]
o100 elseif [#24 EQ 3]
G0X[#24*3]
o100 elseif [#24 EQ 4]
G0X[#24*4]
o100 else
G0X[#24]
o100 endif
m99

P201.macro:

;G65P201Q7
o100 repeat [#17]
(msg, Hello, I am repeating)
o101 repeat [2]
(msg, Hello, I am repeating as well)
o101 endrepeat
o100 endrepeat
m99

[andrewmarles]

Thank you Terje, this looks quite good. I've been working on the I2C display stuff (still don't quite have it working with the Jog2K) but I think this is more important so I will try to get you some feedback asap.

[terjeio]

I have fixed some bugs (and hopefully not introduced some new ones), added a debugging comment and bit of documentation.

[infnorm]

This is pretty impressive development. Have you thought about how to handle M97 M98 (or LinuxCNC style subroutines). I guess my concern going down that route is then streaming becomes perhaps more difficult. Typical controllers have those subroutines as part of the main buffer that is assumed to have random access. I'm in general concerned as the semantics of the controller becomes more and more complex, then the sender will have to sync / understand more of the conrtollers semantics to create graphical estimates.

One idea for subroutines would be to treat a M97 entirely on sender. One could also require the sender to switch to streaming the subroutine once the M97 is reached (perhaps the controller has a way of indicating this.

[terjeio]

Have you thought about how to handle M97 M98 (or LinuxCNC style subroutines).

Yes, see below.

Typical controllers have those subroutines as part of the main buffer that is assumed to have random access.

True. AFAIK LinuxCNC style subroutines that has to be placed in the gcode program before they are called are possible to implement by storing them in a RAM filing system in the controller as they are encountered. I have a RAM filing system available in the networking plugin already...
Of course RAM will be a limiting factor, but then some controllers can have external RAM attached.

I'm in general concerned as the semantics of the controller becomes more and more complex, then the sender will have to sync / understand more of the conrtollers semantics to create graphical estimates.

Typically subroutines (or macros) will be for probing, checking inputs, tool changes etc that cannot/need not to be rendered graphically?

One idea for subroutines would be to treat a M97 entirely on sender. One could also require the sender to switch to streaming the subroutine once the M97 is reached (perhaps the controller has a way of indicating this.

This will limit the choice of senders, IMO not a good option. Graphic representation will still be an issue - not easy to solve without sender updates that might be difficult to get implemented. Even the relatively simple grblHAL tool change protocol has not been implemented by any senders (as I know of) other than ioSender.

[infnorm]

Have you thought about how to handle M97 M98 (or LinuxCNC style subroutines).

Yes, see below.

Thanks for thoughtful replies.

Typical controllers have those subroutines as part of the main buffer that is assumed to have random access.

True. AFAIK LinuxCNC style subroutines that has to be placed in the gcode program before they are called are possible to implement by storing them in a RAM filing system in the controller as they are encountered. I have a RAM filing system available in the networking plugin already... Of course RAM will be a limiting factor, but then some controllers can have external RAM attached.

I'm in general concerned as the semantics of the controller becomes more and more complex, then the sender will have to sync / understand more of the conrtollers semantics to create graphical estimates.

Typically subroutines (or macros) will be for probing, checking inputs, tool changes etc that cannot/need not to be rendered graphically?

If they are really limited to this, then I suspect this will be mostly ok. However, if people are doing like their entire program in a subroutine so they can do multiple work offsets or G92 hacking, this might make the sender blind.

If we are going to go further into this direction, it would be great to think about how senders can accurately show what the machine is doing. Currently the simple ok ack makes it hard to know when things are actually happening (since it is more of an acceptance of valid syntax + that it will be run).

Perhaps the LN status mechanism makes this work fine. The sender renumbers every line to be unique, and then the sender just watches Ln to figure out which of the commands it should highlight. This will work ok, but local subroutines (at least on Haas) do use N numbers around, so arbitrarily renumbering them is not good, because they are often used by programmers/operators to track where to start/stop.

Currently I am trying to make accurate visual display of currently what is going on in the controller. I'd like to highlight the gcode that is currently being cut (obviously on like an adaptive cut this might be a high water mark). the Ln: status code allows this I guess. With the addition of conditionals these N numbers will no longer be assumable to be monotonic increasing, so being able to mark parts of the graphic as definitevely done is hard.

@andrewmarles and I have been talking about protocol extensions, and one that would be super useful is that if the status report could report the numbers of lines that are fully retired. That would make it possible to for example not draw conditional blocks not done. Obviously this is an issue for sender backward compatibility, but there are certain things that don't fit very well. It would be also ideal if every command issued had a serial number so that responses to these could be tracked, resequenced etc.

Some further context: I'm currently reworking/forking bCNC to be much faster, grblHal compatible, and also have better visualization. It's introduction of Python scripting clearly makes certain aspects of the semantics non deterministic and undefined, because it can do arbitrary python conditions on variables sync'd from the controller that are themselves not very deterministic. I.e. if you do something based on a variable that is syncrhonized from the controller non-deterministic times.

One idea for subroutines would be to treat a M97 entirely on sender. One could also require the sender to switch to streaming the subroutine once the M97 is reached (perhaps the controller has a way of indicating this.

This will limit the choice of senders, IMO not a good option. Graphic representation will still be an issue - not easy to solve without sender updates that might be difficult to get implemented. Even the relatively simple grblHAL tool change protocol has not been implemented by any senders (as I know of) other than ioSender.

[terjeio]

@infnorm Do you know how LinuxCNC handles non-deterministic gcode? Ignoring it when rendering? Rendering when it becomes deterministic?

For deterministic gcode it will be easiest to handle it in the sender by translating parameters /expressions to constants and then render the result (and send this to the controller)? This is what I have did earlier in ioSender, but have now messed up a bit in the lates edge release.
Non-deterministic code could also be handled in the sender if reading the needed parameters from the controller at execution time and
outputting the correct gcode based on that. Parameters can already be read from the controller via the $# command.

Complicated... And perhaps one should not strive for perfection and rather accept some limitations. And if such limitations cannot be accepted by a user then it is time to move up to a more capable CNC control system?

[karoria]

Can somebody write an example macro for ATC with linear tool magazine? Tell me the parameter settings also if required to be changed. My setup is getting almost ready so I will be able to test it soon. If ATC is not viable this way (macro), I have to use plugin with IOports where I am really weak (C language).

[terjeio]

Tool change macros turned out to be a bit more challenging than I thought. Since the gcode parser function is not reentrant I have to delay setting the current tool to the selected one in the macro itself. And hooking in the macros has to happen when the file system they reside in is mounted. So a few changes to the core was needed, will commit these later when I am sure the changes do not affect normal function.

Here is how it will work:
On fileystem mount the macro plugin first checks if ATC code (from a plugin) is already in place, if not and a macro named tc.macro is found in the root directory it will attach itself to the HAL tool change entry points.
When a T command is executed the macro plugin will look for a macro named ts.macro in the root directory and execute that if found, otherwise it will silently return. This can be used to preposition a tool carousel etc.
When M6 is executed it will run tc_macro, if this has been removed since attachment an error will be returned.

A simple example:

(debug,Changing tool #<_current_tool> to tool #<_selected_tool>)
; save current position
#100=#<_x>
#101=#<_y>
#102=#<_z>
;tool change code here
G0G53Z0
O101 if [#<_current_tool> EQ 1]
G0X10Y30 ; move to tool rack position #1
O101 else
G0X10Y40 ; move to tool rack position #2
O101 endif
G0Z-10
M65P0 ; drop current tool
G0G53Z0
O201 if [#<_selected_tool> EQ 1]
G0X10Y30 ; move to tool rack position #1
O201 else
G0X10Y40 ; move to tool rack position #2
O201 endif
G0Z-10
M65P1 ; pick up new tool
; probe new tool or set offsets from tool table?
M61Q#<_selected_tool> ; this is needed to set the current tool to the selected one
; return to original position
G53Z0
G0X#100Y#101
G0Z#102
M99

[karoria]

Thanks terje! I will soon work on it. So the macro will execute on getting M6 command on gcode prigram, right? If so, what about planner buffer? And will it accept the new Z zero command (new tool height) in between?

[terjeio]

As stated the macro will be run on a M6 command. All G- and M-codes are available from the macro, you will have to save and restore the needed states (position, spindle, coolant, ...) in the macro itself.

[Dietz0r]

First i'd like to state what an absolute phenomenal milestone that is... i'm in awe how quickly you implemented that!

When a T command is executed the macro plugin will look for a macro named ts.macro in the root directory and execute that if found, otherwise it will silently return. This can be used to preposition a tool carousel etc.
When M6 is executed it will run tc_macro, if this has been removed since attachment an error will be returned.

Quick question about that one:
Does the ts.macro always run first when called from the same line or does it depend on which command comes first?
e.g.
N10 M6 T5
vs
N10 T5 M6
I know tool preloading is an option for the Postprocessor, i'd just wanted to know if it's deterministic?

[terjeio]

i'd just wanted to know if it's deterministic?

It is, order of execution is defined in the NIST RS274NGC specification (section 3.8):

...
5. select tool (T).
6. change tool (M6).
...

[terjeio]

The latest edge version of ioSender now accepts flow control statements and will pass them on to the controller as-is. I have yet to add validation of any expressions related to those though.

[terjeio]

Support for macro based tool changes added in the latest commit (build 20230607). More info in this comment.

To check if tool the change macros has been successfully enabled use the $I command. The NEWOPT element will include ATC in the list of options if so:
[NEWOPT:ENUMS,RT+,EXPR,ATC,SED,RTC,ETH,FTP,SD]

Since I do not have an ATC to test with I leave it to users to write macros and verify functionality. There are likely bugs to be ironed out so again, please provide feedback here if any shows up.
Be careful when testing, stuff might break!

[karoria]

Hi @terjeio
Thank you very much for ATC macro!

M61Q#<_selected_tool> ; this is needed to set the current tool to the selected one

This line in your example ATC code doesn't set selected tool as current tool, instead it throws an "error:47 in Program file at line 8". I have also tried:
#<_current_tool>=#<_selected_tool>
instead of that line but no luck.
Everything else seems working well. I have an ATC machine ready for testing. Once I do some testing, I will put my working macro here.

[karoria]

It turns out that when current tool and selected tool both are same, it throws above error:47. It just saves selected tool as current tool but I was testing with a program with T1 M6 within starting lines of gcode and I am not knowing how to see the tool table and current tool with $ commands. Kindly inform if such commands are there.
Upon powering up the machine, it losts current tool number and defaults to tool 0 (zero) and the macro executes tool release at the spindle's current position. Am I missing something to store current tool number in permanent memory?

[terjeio]

Which build date (from the $I command) - I fixed a bug in getting the _selected_tool parameter on May 7th.

Note that M61Q#<_selected_tool> can only be used from a macro running from a file, it will be ignored if in a regular file (or as a MDI command) sent from a sender.

#<_current_tool>=#<_selected_tool>

Predefined parameters are read-only so this is not allowed.

I am not knowing how to see the tool table and current tool with $ commands. Kindly inform if such commands are there.

$# can be used to ouput parameter values, both numbered and named, e.g. to get the _selected_tool parameter:

$#=_selected_tool
[PARAM:_selected_tool=2.000]

Upon powering up the machine, it losts current tool number and defaults to tool 0

The current tool is a volatile parameter and will not survive a hard reset, not sure it will be a good idea to change this...

[karoria]

Which build date (from the $I command) - I fixed a bug in getting the _selected_tool parameter on May 7th.

[VER:1.1f.20230610:]
[OPT:VNMZHS+,35,1024,5,8]
[AXS:5:XYZAB]
[NEWOPT:ENUMS,RT+,HOME,ES,REBOOT,EXPR,ATC,SED,RTC,ETH,FTP,WebDAV,SD]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:230604]
[DRIVER OPTIONS:USB.2]
[BOARD:BOARD_VALAY_V7P6]
[AUX IO:0,2,0,0]
[IP:192.168.1.77]
[NETCON:Websocket]
[PLUGIN:WebUI v0.17]
[PLUGIN:SDCARD v1.09]
[PLUGIN:FS macro plugin v0.03]

Note that M61Q#<_selected_tool> can only be used from a macro running from a file, it will be ignored if in a regular file (or as a MDI command) sent from a sender.

Noted. In my case, I was running tc.macro from littlefs. The program was running through webUI from SD card.

The current tool is a volatile parameter and will not survive a hard reset, not sure it will be a good idea to change this...

In my opinion, current tool should be non-volatile (if possible) so that upon machine restart, it remembers which tool is gripped by spindle. This will avoid any possible accidents.

I have tested following simple tool change macro extensively with my 8 tool linear rack. Kindly note that due to unavailability of additional outputs in my circuit board, I have used M7 and M9 for tool ungrip and tool grip respectively. The only real issue is it raises alarm when current tool and selected tool are same. Further, a non-volatile storage for current tool should be a better option.

(debug,Changing tool #<_current_tool> to tool #<_selected_tool>)
; save current position
#100=#<_x>
#101=#<_y>
#102=#<_z>
#103=#<_spindle_on> ;saving spindle status in a variable
#104=#<_flood> ;saving coolant status in a variable
;tool change code here
G0G53Z0
M5 ;stop spindle
M9 ;stop coolant
O101 if [#<_current_tool> EQ 1]
G0G53X-339.2Y-53.1 ; move to tool rack position #1
O101 elseif [#<_current_tool> EQ 2]
G0G53X-299.2Y-53.1 ; move to tool rack position #2
O101 elseif [#<_current_tool> EQ 3]
G0G53X-259.2Y-53.1 ; move to tool rack position #3
O101 elseif [#<_current_tool> EQ 4]
G0G53X-219.2Y-53.1 ; move to tool rack position #4
O101 elseif [#<_current_tool> EQ 5]
G0G53X-179.1Y-53.1 ; move to tool rack position #5
O101 elseif [#<_current_tool> EQ 6]
G0G53X-139.1Y-53.1 ; move to tool rack position #6
O101 elseif [#<_current_tool> EQ 7]
G0G53X-99Y-53.1 ; move to tool rack position #7
O101 elseif [#<_current_tool> EQ 8]
G0G53X-59Y-53.1 ; move to tool rack position #8
O101 endif
G0G53Z-136.5
G04 P1 ; pause for 1 second
M7 ; drop current tool
G04 P1
G0G53Z-70
O201 if [#<_selected_tool> EQ 1]
G0G53X-339.2Y-53.1 ; move to tool rack position #1
O201 elseif [#<_selected_tool> EQ 2]
G0G53X-299.2Y-53.1 ; move to tool rack position #2
O201 elseif [#<_selected_tool> EQ 3]
G0G53X-259.2Y-53.1 ; move to tool rack position #3
O201 elseif [#<_selected_tool> EQ 4]
G0G53X-219.2Y-53.1 ; move to tool rack position #4
O201 elseif [#<_selected_tool> EQ 5]
G0G53X-179.1Y-53.1 ; move to tool rack position #5
O201 elseif [#<_selected_tool> EQ 6]
G0G53X-139.1Y-53.1 ; move to tool rack position #6
O201 elseif [#<_selected_tool> EQ 7]
G0G53X-99Y-53.1 ; move to tool rack position #7
O201 elseif [#<_selected_tool> EQ 8]
G0G53X-59Y-53.1 ; move to tool rack position #8
O201 endif
G0G53Z-137
G04 P1
M9 ; pick up new tool
G04 P1
M61Q#<_selected_tool> ; this is needed to set the current tool to the selected one
G04 P1
; return to original position
G53Z0
O202 if [#103 EQ 1] ; restore spindle status
M3
O202 endif
O203 if [#104 EQ 1] ; restore coolant status
M8
O203 endif
G0X#100Y#101
G0Z#102
M99

[terjeio]

In my opinion, current tool should be non-volatile (if possible) so that upon machine restart, it remembers which tool is gripped by spindle. This will avoid any possible accidents.

Either way will be prone to accidents? LinuxCNC specifies _current_tool (#5400) as volatile so I'll leave it as-is. Complicating factors related to keeping the tool number will be how to handle tool offsets and possibly homed status so it will be safest to force the operator to always specify which tool is in the spindle with M61 and reestablish offsets if nso eeded.

Error 47: I'll add a check for tool changes and skip calling the macro if the current tool number is equal to the selected tool. From the NIST specification: "It is OK (but not useful) to program a change to the tool already in the spindle." - thus I assume skipping is ok.

[karoria]

Either way will be prone to accidents? LinuxCNC specifies _current_tool (#5400) as volatile so I'll leave it as-is. Complicating factors related to keeping the tool number will be how to handle tool offsets and possibly homed status so it will be safest to force the operator to always specify which tool is in the spindle with M61 and reestablish offsets if nso eeded.

I understand.

Error 47: I'll add a check for tool changes and skip calling the macro if the current tool number is equal to the selected tool. From the NIST specification: "It is OK (but not useful) to program a change to the tool already in the spindle." - thus I assume skipping is ok.

Right. I also think skipping is good solution.

[Dietz0r]

I have tested following simple tool change macro extensively with my 8 tool linear rack. Kindly note that due to unavailability of additional outputs in my circuit board, I have used M7 and M9 for tool ungrip and tool grip respectively. The only real issue is it raises alarm when current tool and selected tool are same. Further, a non-volatile storage for current tool should be a better option.

1.) Awesome! Cool to see someone utilizing the ATC macros.
2.) a simple if current tool == selected tool -> m99 at the beginning will eliminiate the alarm condition
3.) do you need the save position and restore position code? i was under the assumption that the core would try to touch off the tool at the toolsetter (if you have one) after the change anyways. (aka the toolchange.macro exectues (where it would present the TOOL status) and after that it's off to touch off and restore the position where m6 was called on its own? or does the macro disable all that and we'd have to put it in too?

[karoria]

I have checked for the above behaviour in communication using USB and websockets both connections one by one and found same message for both in iosender.

[terjeio]

Please try again with the edge version.

[karoria]

Hi @terjeio
Thanks for all your time and efforts. Finally I got the reason for $$ crash. It was my board map file as follows. Commenting out this line "#define AUXINPUT0_PIN (31u) // ST0" makes the controller hang when $$ is issued. I can reproduce it. I think there might be some code somewhere which requires AUXINPUT0_PIN defined.

`/*
valay_map_v7p6.h - driver code for IMXRT1062 processor (for valay machines)
Part of grblHAL
Copyright (c) 2020-2021 Terje Io
2022 Ravi Karoria
Grbl is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
Grbl is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with Grbl. If not, see http://www.gnu.org/licenses/.
*/

#define BOARD_NAME "BOARD_VALAY_V7P6"
#define HAS_IOPORTS
#define STEPPERS_ENABLE_PIN (30u)
#define X_STEP_PIN (2u)
#define X_DIRECTION_PIN (3u)
//#define X_ENABLE_PIN (10u)
#define X_LIMIT_PIN (19u)
//#define X_LIMIT_PIN_MAX (17u)
#define Y_STEP_PIN (4u)
#define Y_DIRECTION_PIN (5u)
// #define Y_ENABLE_PIN (40u)
#define Y_LIMIT_PIN (20u)
//#define Y_LIMIT_PIN_MAX (21u)
#define Z_STEP_PIN (6u)
#define Z_DIRECTION_PIN (7u)
// #define Z_ENABLE_PIN (39u)
#define Z_LIMIT_PIN (21u)
//#define Z_LIMIT_PIN_MAX (23u)
// Define ganged axis or A axis step pulse and step direction output pins.
#if N_ABC_MOTORS > 0
#define M3_AVAILABLE
#define M3_STEP_PIN (8u)
#define M3_DIRECTION_PIN (9u)
#define M3_LIMIT_PIN (22u)
//#define M3_ENABLE_PIN (38u)
#endif
// Define ganged axis or B axis step pulse and step direction output pins.
#if N_ABC_MOTORS == 2
#define M4_AVAILABLE
#define M4_STEP_PIN (10u)
#define M4_DIRECTION_PIN (11u)
#define M4_LIMIT_PIN (23u)
//#define M4_ENABLE_PIN (37u)
#endif
// Define spindle enable and spindle direction output pins.
#define SPINDLE_ENABLE_PIN (28u)
#define SPINDLE_DIRECTION_PIN (29u)
#define SPINDLE_PWM_PIN (12u) // NOTE: only pin 12 or pin 13 (LED) can be assigned!
// Define flood and mist coolant enable output pins.
#define COOLANT_FLOOD_PIN (25u)
#define COOLANT_MIST_PIN (24u)
// Define user-control CONTROLs (cycle start, reset, feed hold, door) input pins.
#define RESET_PIN (41u)
#define FEED_HOLD_PIN (40u)
#define CYCLE_START_PIN (39u)
#define SAFETY_DOOR_PIN (14u)
#define ESTOP_PIN (17u)

// #if MOTOR_FAULT_ENABLE
#if MOTOR_FAULT_ENABLE
#define MOTOR_FAULT_PIN (16u)
// #endif
#endif

//For LED blink plugin
//#define LED_BUILTIN (13u)
// Define probe switch input pin.
#define PROBE_PIN (18u)
#if QEI_ENABLE
#define QEI_A_PIN (30u) // ST1
#define QEI_B_PIN (34u) // ST2
#define QEI_SELECT_PIN (35u) // ST3
#endif
// Define auxillary input pins
#define AUXINPUT0_PIN (31u) // ST0
#if !QEI_ENABLE
//#define AUXINPUT1_PIN (32u) // ST1
//#define AUXINPUT2_PIN (33u) // ST2
//#define AUXINPUT3_PIN (34u) // ST3
#endif
#define AUXOUTPUT0_PIN (33u) // AUX0
#define AUXOUTPUT1_PIN (34u) // AUX1
//#define AUXOUTPUT2_PIN (33u) // AUX2
#if KEYPAD_ENABLE
#define KEYPAD_STROBE_PIN (41u) // I2C ST
#endif
#if EEPROM_ENABLE || KEYPAD_ENABLE
#define I2C_PORT 4
#define I2C_SCL4 (24u) // Not referenced, for info only
#define I2C_SDA4 (25u) // Not referenced, for info only
#endif`

[terjeio]

What is the last setting reported before a hang? And is $ES command output hanging as well?

I recently moved aux I/O settings handling to the core, if you comment out this line does it still hang?

[karoria]

1. Yes, $ES also makes it hang. I have noticed that when there are no AUXINPUT pins defined, it makes a problem.

if you comment out this line does it still hang?

It solves problem! Now both $$ and $ES works without issues.

Sending a screen recording with chrome dev tools console on.

Screen.Recording.2023-07-25.at.3.29.19.PM.mov

[karoria]

I also noticed that in my board map file, I can't define more than 2 AUXINPUTs even though I have free pins available, while I can define more AUXOUTPUTs. This may not have relation with above issue as I am defining those pins first time. Any clues?

[terjeio]

I can't define more than 2 AUXINPUTs even though I have free pins available

Any errors while compiling? I added pin 16 as input 1 to your map and it compiles and reports as it should:

$pins
[PIN:41,Emergency stop]
[PIN:40,Feed hold]
[PIN:39,Cycle start]
[PIN:14,Safety door]
[PIN:18,Probe]
[PIN:19,X limit min]
[PIN:20,Y limit min]
[PIN:21,Z limit min]
[PIN:31,Aux input 0,P0]
[PIN:16,Aux input 1,P1]
[PIN:2,X step]
[PIN:4,Y step]
[PIN:6,Z step]
[PIN:3,X dir]
[PIN:5,Y dir]
[PIN:7,Z dir]
[PIN:30,Steppers enable]
[PIN:28,Spindle on]
[PIN:29,Spindle direction]
[PIN:25,Flood]
[PIN:24,Mist]
[PIN:33,Aux out 0,P0]
[PIN:34,Aux out 1,P1]
[PIN:12,Spindle PWM]

$$ and $ES works too.

Any clues?

Corrupted source file(s)?

[karoria]

Hi @terjeio
Sorry to bother you for above issue. I could not figure out how that got resolved automatically. Now I can't recreate it. Not an issue now. But when it appeared, it was compiling fine but after compilation, the ethernet was not communicating at all. Those data lights below magjack were also not turning on. This is for your reference only as now I can't recreate it.

[karoria]

Hi @terjeio,
I have checked total of 4 aux output pins and 4 aux inputs pins with my board and they all seems to work fine. However, I could not figure out:

1. How to invert Aux pins (default is Aux Out = Active High, Aux In = Active Low)?
2. How to get their states in report?

Further, I was thinking about some features that can help:

1. Adding a state "Macro" when it is executing, just like "Idle".
2. Adding a state "TC" when tc.macro is executing, "TS" when ts.macro is executing.

[terjeio]

How to invert Aux pins

Use $370 and $372, send $$=370 and $$=372 for info. Up to eight I/O ports can be configured.

How to get their states in report?

Currently a plugin has to be written for that. Another user requested the same functionality a bit back and I provided some guidance, a search might find it? Note that the current API does not support reading back the current output state, the plugin has to redirect output calls to itself and save the state before calling the original code.

Adding a state "Macro" when it is executing, just like "Idle".
Adding a state "TC" when tc.macro is executing, "TS" when ts.macro is executing.

This will break sender compatibility and make the the state machine more complex so not something I want to do as standard. Add as addidional element to the real-time report instead?

[karoria]

Another user requested the same functionality a bit back and I provided some guidance, a search might find it?

Will go through it.

Add as addidional element to the real-time report instead?

That would be nice too! My intention was to get at least basic data on which macro is being executed.

[yuuahmad]

hi @terjeio
I'm very new to grblhal, but I really need grblhal for my college practical assignments because it's easy to set up.

but I was hampered when I wanted to implement ATC.

I myself use a cnc3018 whose board I have replaced with a nucleof446re

here is what my $$ and $I+ look like

$$ < $0=10.0
$1=25
$2=0
$3=0
$4=7
$5=0
$10=511
$11=0.010
$12=0.002
$13=0
$14=0
$15=0
$16=0
$17=0
$18=0
$20=0
$21=0
$22=0
$23=0
$24=25.0
$25=500.0
$26=250
$27=1.000
$28=0.100
$29=0.0
$32=0
$37=0
$39=1
$40=0
$43=1
$44=4
$45=3
$46=0
$62=0
$63=3
$64=0
$100=250.000
$101=250.000
$102=250.000
$110=500.000
$111=500.000
$112=500.000
$120=10.000
$121=10.000
$122=10.000
$130=200.000
$131=200.000
$132=200.000
$341=0
$342=30.0
$343=25.0
$344=200.0
$345=200.0
$346=1
$384=0
$398=35
$481=0
$484=1
$486=0
$534=0
ok
$I+ < [VER:1.1f.20231005:]
[OPT:NSL,35,1024,3,6]
[AXS:3:XYZ]
[NEWOPT:ENUMS,RT+,NOPROBE,ES,EXPR,SED,SD]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[FREE MEMORY:109K]
[DRIVER:STM32F446]
[DRIVER VERSION:230922]
[BOARD:Protoneer v3]
[PLUGIN:SDCARD v1.10]
[PLUGIN:FS macro plugin v0.06]
ok

I've read this discussion from start to finish but I can't find how to set ATC correctly. like @karoria in the #309 (reply in thread)

Can you explain to me the correct steps, and can be understood by lay people?

I have done several things such as setting $341 to values 1,2 and 3 but still can't get newopt:atc to appear

and I have also changed #define N_TOOLS 6 and #define NGC_EXPRESSIONS_ENABLE 1 but the results are still the same

[yuuahmad]

yes i do here is some output from comand $FM and $F+

[yuuahmad]

@terjeio
sorry in advance for my carelessness.

after I tried to understand what you were talking about, I tried to do it according to what you instructed. and here are the steps to activate ATC (for those who are still beginners)

1. Make your CNC machine support MicroSD
2. Make sure the tc.macro program is on the microSD, and is rooted
3. Insert the microSD into the CNC machine
4. Mounting microSD
5. finished. Please enjoy your ATC

here is a screenshot of how I did it

note:

1. ATC will not turn on if the microSD has not been mounted.
2. In my case, when I have mounted the microSD, my homing program sometimes errors (fails to homing) ((not a big problem and maybe my wiring is not good))

[terjeio]

ATC will not turn on if the microSD has not been mounted.

Correct, sadly using littlefs for storing tc.macro in flash is not possible with the STM32 microprocessors due to the large flash block sizes they uses. What could be done is to add the macro to a read-only embedded filesystem, but this is a bit complicated since the macro has to be converted into compilable code along with the filesystem code, like this, and added to the build.

[terjeio]

@yuuahmad In a coming update I will add a setting for automounting the SD card on startup.

[terjeio]

In the latest commit $650=1 will force mounting on startup.

[rvalotta]

Thought I give some feedback on my current attempt to use the macros... Spent the day getting to understand how everything worked together. My goal was/is to create atc macro to support the RapidChange ATC line of products. Since each product has a different spacing based on collet size I tried to create a script that would calculate X and Y for a specific tool position. This could would be used multiple times in the code (tool drop off and pickup location). Turns out we don't support nesting macros so calling a macro from a macro to get the co-ordinates didn't work. In this project there are many use cases where the ability to call a macro or subfunction would make things much cleaner... Open and Close the dust cover (done in different parts of the code) Check collet us mounted tightly or that collet came off for unloading (there is a IR sensor for this).... etc etc

I'm going to write this as a top down approach copy and pasting the code for the different functions.

Anyways my 2 cents worth....

[terjeio]

Adding nesting is a tad complicated since support for local parameters (variables) has to be added. One might also run into memory issues related to that since some of the supported processors are a bit on the low end in that department.

[rvalotta]

As a first step do local variables really need to be there? I was planning on just having a few throw away global variables that I recycled as needed for calculations or what not... I think it would make for much more manageable large macros to be able to nest functions at the loss of local variables. (Just a thought more than anything else)

[terjeio]

As a first step do local variables really need to be there?

I believe so. Anyway, just try nested calls - with luck they will work, but without support for local variables. E.g. calling G65 with parameters will overwrite existing values in the caller. You may have to increase the expression handler stack size to make it work though, that is set pretty low for now.

[terjeio]

Testers wanted, must compile locally.
New functionality to be verified: nested/recursive calls (G65 and o<n> CALL), LinuxCNC subroutines and saving/restoring of modal state.
Note that Fanuc style M99 calls is not (yet?) supported.
If anyone is interested in helping out I will add a zip with the modified code in a new discussion.
Note that the new functionality requires the gcode to be run from a SD card.

Here is an example file that seems to run correctly, I am currently away so cannot verify on a machine - at least it runs to completion.

[rvalotta]

More than happy to try and refactor the toolchange script to use this new functionality.. Count me in

[terjeio]

Discussion and code here.

[skasti]

Not 100% sure if this is the correct discussion to ask this, but is there a way to write to a programmatically determined parameter?

I see that you have added a built-in macro for reading a parameter value (G65P1Q[Param]), but I would love to have one to write a value (lets call it G65P2Q[Param]V[Value]).

The reason is that I am making a RapidChange ATC style tool rack, but I don't want to reuse tool numbers, so I want to loop through my tool rack to find the slot to park the current tool, and for picking up the next tool.

For this it would be lovely to have "arrays" I can iterate through, which could be defined by the starting parameter and the number of items, so that I could use a while loop, and then use the index to write back which tool is stored in that slot

(debug, find available slot for tool)
#<tool>=#20; 20 is T parameter
#<index>=0
#<rack_start>=500
#<rack_size>=5
while [#<index> LT #<rack_size>]
    #<slotTool>=G65P1Q[rack_start + index]
    if [#<slotTool> EQ -1]
        G65P2Q[rack_start + index]V[#<tool>]
        (debug,Place T#<tool> in slot #<index>)
        M99
    endif
endwhile
(debug,Unable to find slot to store tool)
M99

My goal would be that params 500-504 would be dynamically set by the macros. I have currently solved this with a chain of if's, but the ability to write to a numbered param would just make it so much simpler

P.S; It would also be awesome if it was possible to have M0 show any comment on the same line as a dialog to the operator (cncjs did this)

M0; Place T#<tool> in slot #<index>

P.P.S; Realized my P.S probably belongs in ioSender discussion 🤔

[terjeio]

If you want to store settings persistenly you will have to write a plugin that allocates the settings you need and traps/redirects grbl.on_macro_execute to your code for writing to the settings. Reading the values can then be done via G65P1Qn.
Setting numbers 450-459 are currently reserved for private plugins, if the plugin is to be published you will have to request a range of settings for it. Also, be aware that parameters and settings are not the same thing. Settable parameters (0-5000) are not persistenly stored (unlike LinuxCNC et. al.), settings are.

[skasti]

Persistence is not really what I need, as most of the time I would reset the tool rack to empty before running a program anyways.

What I want to do, is to start my program with a call to the above mentioned macro for each tool in the program, so that the machine tells the operator to put the tools in whatever slots they need to be in. To do that, I need to be able to store which tool is in which slot, hence the need to dynamically set a parameter.

I can, of course, solve this with an if-elseif-chain, since I know that my rack has 5 slots, but I was trying to write it more generic 😅

Now that I think of it. is there a reason why this should not work?

(debug, find available slot for tool)
#<tool>=#20; 20 is T parameter
#<index>=0
#<rack_start>=500
#<rack_size>=5
while [#<index> LT #<rack_size>]
    #<slotTool>=#[#<rack_start> + #<index>]
    if [#<slotTool> EQ -1]
        #[#<rack_start> + #<index>]=[#<tool>]
        (debug,Place T#<tool> in slot #<index>)
        M99
    endif
endwhile
(debug,Unable to find slot to store tool)
M99

I am pretty sure it doesn't, but syntax-wise it would make sense that #[#<rack_start> + #] would become #500, #501, etc?

[terjeio]

Now that I think of it. is there a reason why this should not work?

"Array" indexing is not part of the NIST specification and I have no idea about how hard it would be to implement. However, a plugin that implements an internal G65 macro that read/writes from/to a preallocated array would be straightforward to make since parameters passed to G65 can be expressions. E.g this works:

#1=100
#2=1
G65P1Q[#1+#2]
(debug, Call_level: #<_call_level>, $101=#<_value>)

[terjeio]

In the next build I will add an inbuilt macro for getting/setting parameters via G65:

Syntax: G65P3I<param>[Q<value>]

Examples:

g65p3i500 - read parameter 500 and return the value in the named parameter _value.
g65p3i500q123 - set parameter 500 to 123.
#40=4
g65p3i[500+#40] - read parameter 504 and return the value in the named parameter _value.

NOTE: do not reference parameter 4 or 17, or rather not any parameter below 30, as these are used to pass the arguments to the invoked G65 macro.

[terjeio]

Comitted now. I have added an optional extra word S<param> that can be used to set a target parameter instead of returning it in the named parameter _value.

[skasti]

Is it technically possible to store strings in parameters? I would like to provide the operator with a short description of the tool to load, but since the messages to operator to load/unload tools etc is inside macros, I have no way of passing the tool description to the location 🤔

I am considering writing a macro for this with the descriptions for all the tools in my library hard-coded, and do a huge if/then to print the correct message, but this seems a bit awkward and error-prone 😅

I could, however, quite easily modify my post processor to store tool descriptions in parameters if it was possible.
by inserting something like #605="3F D4 R0 - Endmill" when printing the tool list (#605 being an offset (600) + tool number(5)), I could have a more generic way of accessing the description without keeping a copy of my entire tool library in a macro 🤔

I get that this might be a lot of work, so I am just asking if you think it would be technically possible before I might spend time figuring out how I might do something like this 😅

I think I might want to implement #[<expression>] as a way to read/write parameters dynamically first, as having to use G65P3I[...] and checking the returned value etc is a bit clunky for something like this 🤔 😅

P.S; Yes, I do realize storing strings in parameters could be a memory-hog if used indiscriminately. So it would be up to the macro-developer to keep memory-usage in mind 😅 🙈

[terjeio]

Is it technically possible to store strings in parameters?

Sure is, but how much work it will be to make # variables type aware is not something I will try to estimate (or do). Perhaps a better idea to look into how other gcode dialects handle this? E.g. Fanuc string registers?
Or write a plugin that uses $ commands to set the strings and a custom G65 command to write them out?

I think I might want to implement #[] as a way to read/write parameters dynamically first, as having to use G65P3I[...] and checking the returned value etc is a bit clunky for something like this

Again, is there any dialects out in the wild implementing arrays?

[skasti]

Sure is, but how much work it will be to make # variables type aware is not something I will try to estimate (or do).

No problem, I briefly looked into how parameters are stored and also came to the conclusion that it would probably not be worth it 😅
I can think of several ways to achieve the desired result without needing string parameters 👍

I think I might want to implement #[] as a way to read/write parameters dynamically first, as having to use G65P3I[...] and checking the returned value etc is a bit clunky for something like this

Again, is there any dialects out in the wild implementing arrays?

I don't know. And I am not really asking for implementing arrays here either, so maybe I have not communicated well😅I am asking for controller-level support for reading and writing to a numbered parameter defined by an expression ;

; The way to do it with the current G65P3In macro:
G65P3I[#<_index> + #<_scnc_rack_start>]
O50 if [#<_value_returned>]
#<slot_value>=#<_value>
O50 else
error [39] ; Out of range?
O50 endif

; The way I propose it could work:
#<slot_value>=#[#<_index> + #<_scnc_rack_start>]

I do realize that the gcode convention of framing expressions with brackets, which most languages use for arrays, and in the same post writing about how I would use it to approximate arrays`probably did not help 😂

[skasti]

But yeah, not sure if that is defined in any gcode dialect, and don't spend your time on it if it does not feel right for how you want the grblHAL-dialect to be 😅