State of the AUX ports in realtime report?

[Avatario34]

Is there a way for a pendant to find out which aux ports are active? I know how to switch them on / off via e.g. M64P1 / M65P1, and GrblHAL responds with 'ok', but I can't see a report whether they are turned on or off. If there isn't a report available yet, would it make sense to add this to the A: accessory data field, e.g. with '0' (AUX0 active), '1' (AUX1 active) etc?

[terjeio]

Is there a way for a pendant to find out which aux ports are active?

No, and yes... The current implementation of the ioports API does not support reading back the state of an output port. However, a plugin could trap the hal.port.digital_out function to save the port status and add a new element to the real-time report by trapping the grbl.on_realtime_report function. This would be a lot faster to implement than modifying and testing all the driver implementations of the ioports API.

The coolant plugin is one example of how the real-time report can be added to.

[Avatario34]

Thanks Terje. That‘s good news, and bad news at the same time. I get the idea of the plugin, but I won‘t be able to build it in acceptable time, given my limited knowledge of the core. Will probably implement a workaround and switch off all Aux ports when the pendant takes over control.

[Avatario34]

Hi Terje, I've looked at the plugin development, it seems doable, also for a Noob like me. Is there a list of all on_* events I can subscribe to within a plugin? And which event could I grab to track changes of the AUX lines? An alternative approach would be to check the processed G-Codes and look for something like M64P? and M65P?, which event can I use for this? Thanks for a quick hint.

[Avatario34]

Would the following code changes be acceptable to you to implement the trapping of the IO operations:

In grbl\core_handlers.h, line 115: 114 typedef sys_commands_t *(*on_get_commands_ptr)(void); 115 typedef void (*on_digital_out_ptr)(uint8_t port, bool on); // new

In grbl\core_handlers.h, line 161: 160 enqueue_realtime_command_ptr enqueue_realtime_command; 161 on_digital_out_ptr on_digital_out; // new

In grbl\ioports.c, lines 149/150: 148 DIGITAL_OUT((*(aux_out[port].port)), ((settings.ioport.invert_out.mask >> port) & 0x01) ? !on : on); 149 if (grbl.on_digital_out) // new 150 grbl.on_digital_out(port, on); // new

Is the parameter 'port' already the logical index for the AUX ports AUX0 - AUX7?

[terjeio]

Is there a list of all on_* events I can subscribe to within a plugin?

Core events are found here. In addition you can trap all HAL functions found here - note that some of the prototypes (typedefs) are defined in other files. Some plugins are also using function pointers that can be trapped - the keypad plugin is one,

Would the following code changes be acceptable to you to implement the trapping of the IO operations:

No, it is not neccesary. You should copy the hal.port.digital_out pointer to a variable and set it to your function. Save the port states in that and then call the original function that you saved in the variable..

Is the parameter 'port' already the logical index for the AUX ports AUX0 - AUX7?

Normally yes - however, plugins can "claim" ioports, they cannot be used by M62-M66. This means the port numbers defined in the map files do not neccesarily match the port number used by the M commands. Use the $pins command to check the actual allocation.

[Avatario34]

Thanks, that should be easy to do. Will complete my plugin and test. What's the procedure to submit a new plugin for acceptance test?

[terjeio]

What's the procedure to submit a new plugin for acceptance test?

See here.

I should come up with a way to pull in user plugins from the Web Builder...

[Avatario34]

Great, thanks.

Have completed and tested the plugin. Works well for me. Please see here: https://github.com/Avatario34/auxp

It would be nice if the additional realtime report element |Aux: only showed up if and when an Aux port changes its state (as you do this with |MPG:1) or if a comprehensive report is requested. But I haven't found a solution for this (very tiny) issue.

Feel free to copy and change it, and to make it part of your standard plugins (you've almost completely written it yourself with your hints above). Alternatively I would maintain it as a Third Party Plugin, up to you.

Do you want me to create PRs for the changes in my_machine.h and /core/plugins_init.h?

[terjeio]

It would be nice if the additional realtime report element |Aux:

|Aux: should be |Dout: ? There are four types of aux I/O - analog and digital in/out...

It would be nice if the additional realtime report element |Aux: only showed up if and when an Aux port changes its state (as you do this with |MPG:1) or if a comprehensive report is requested. But I haven't found a solution for this (very tiny) issue.

Set a flag (bool) when there are changes and check that or the report.all flag in the report parameter to push the status.

Do you want me to create PRs for the changes in my_machine.h and /core/plugins_init.h?

Wait a bit - I need to figure out how to add 3rd party plugins to the Web Builder. For now rename void auxp_init() to my_plugin_init() - then users can add your plugin by just adding the auxp.c file to the source.

FYI auxp.h is not needed - the code there can be moved to auxp.c, And change the copyright to your name... I'll add a link to your repo here.

[Avatario34]

Done.

[terjeio]

Great, link added.

[Avatario34]

Super, thanks. Closed.

[terjeio]

FYI the Web Builder can now include 3rd party plugins. For that to work you have to add a CMakeLists.txt file to your repo, an example. Change _myplugin.c to auxp.c in your CMakeLists.txt and ping me when done if you want it added. I'll then add it to the Web Builder configuration.