Initial support for low-level ATC functions

[andrewmarles]

Didn't see a good way to do this sort of thing in macros, so I made a plugin for some low-level drawbar and sensor support.

https://github.com/Expatria-Technologies/flexihal_atc

[terjeio]

If you add a code guard then I can add it as a 3rd party plugin to the Web Builder:

#include "driver.h"
#if ATC_ENABLE == 2
... your code ...
#endif

BTW flexihal_atc.h is not needed, plugins_init.h already has the prototype for the init function defined.

Note: other implementations than this will have to be assigned a different ATC_ENABLE number if they are to be added as a 3rd party option.

[andrewmarles]

Code guard added and I removed flexihal_atc.h

[terjeio]

Added to the Web Builder - and promptly crashes the controller if the active spindle does not support the get_data() function...

I do not know which core version you are using, if a newer one there are new functionality that simplifies stuff.
Hooking into grbl.on_execute_realtime and grbl.on_execute_delay is no longer needed for code that needs to run periodically with a period >= 1ms. It is better to use the new task scheduler, just add task_add_delayed(atc_poll, NULL, 100); in the init function and in atc_poll() instead. Change the signature to atc_poll(void *data);
The way you add the system commands has been deprecated, a new function call should be used instead: system_register_commands(&atc_commands);
Finally, the probe_fixture() function does not match the prototype, a parameter for position was added when the previous function pointer was renamed.

BTW I forgot to mention that RP2040 builds requires a CMakeLists.txt file present - similar to this one. Name the library plugin_atc if you want to add it.

[andrewmarles]

At the moment have been working with 20241230. I see the updates around aux ports, so I'll update to that and then look at what needs to change in the probe plugin and now ATC plugins.

I'll also swap the polling stuff over to the task scheduler, that looks very nice.

I have a new RPI board in the works based on RP2350, so will definitely be updating for that driver.

Thanks for the pointers, I really appreciate the feedback.

[andrewmarles]

I did try switching the atc polling over to using the task scheduler, and it works pretty well. I do occasionally see an issue with null pointers being referenced by this line here:

core/grbllib.c

Line 463 in c681661

fn(data);

I'm not sure if this is related to over-running the task queue? ATC is juts a 100ms polling loop, and I have the keypad plugin running also at 100 ms.

[terjeio]

Do you have ethernet enabled? Or KEYPAD_ENABLE == 2 and characters arriving at a fast rate? And is it only happening when motion is ongoing?
Immediate tasks are typically added from interrupts so that the foreground process can execute them, so it is likely that one is misbehaving - perhaps in addition to the task code not handling buffer overflows correctly.

[andrewmarles]

Yes, Ethernet is enabled and active (IOSender is connected via websockets). Keypad is 1 (I2C) I am not accessing the SD card.

I've also seen the issue when ethernet is connected but I am connected via USB-UART. Not sure I've seen it happen yet without Ethernet involved.

[terjeio]

Not sure I've seen it happen yet without Ethernet involved.

If it does not happen with the ethernet cable disconnected it could be a clue for the reason behind this crash.

EDIT: too early in the morning to think straight...

[terjeio]

I have committed a new build with irq disable/enable around deletion of tasks. Not sure if this helps, it is hard to debug for issues that I am not able to replicate...

Also, I have changed code around handling of claiming aux ports in plugins - by switching over to float settings that are stored via get/set functions, -1 is then used to configure "do not claim". The get/set functions maps -1 to port number 255.

Another change is that plugins no longer should claim pins by decrementing the hal.port.num_xxx numbers (or reference them at all). If ioport_can_claim_explicit() returns false a plugin should just refuse to install itself instead. This since all current drivers returns true from a ioport_can_claim_explicit() call if they have support for the requested aux ports.

[andrewmarles]

FWIW, I ran a test overnight with the latest core and a debugger attached and I have not seen the null pointer issue thus far, so it seems likely there was some improvement.