Tentative rewrite for significantly lower MCU load etc...

[terjeio]

This version will take advantage of RGB device(s) available via the latest version of the grblHAL driver API, and is heavily refactored for speed. E.g. blinking is only updated every 1ms and spindle and coolant status is no longer polled but fetched via intercepting driver calls.
Since this version is so heavily changed, and not tested extensively, I am not sure if a PR is appropriate. Please advise me on how to proceed if this version is of interest.

rgb.zip

NOTE: this version requires a yet to be released version of the grblHAL core, I plan to make it available in the next few days.

[5ocworkshop]

Terje, sorry for the delay. I've move house from North America to Europe and I'm currently between machines. I'm hoping to buy a house in the next few months and get my workshop back up. I do have a PicoHAL board from Expatria here for debug work and I am intending to dive back in to things shortly. I'll take a look at your zip and come back to you.

[5ocworkshop]

This looks really good. Exciting to see it re-factored like this and I like the more structured way you considered things like the homing errors, you followed my original intended ideal of cascading through vairous layers - something that I hadn't fully realized. So yellow means the homing domain and then the sub-levels indicate increasing detail about what specifically is wrong. As always with your work it is really well considered and executed. Right now Drew has been sort of handling the repo for me while I moved and get my workshop sorted out so I'll ask him to take a look and consider how to evolve things from a repo perspective.

[terjeio]

Welcome to Europe!

Thanks for taking a look at the code. I have made a few small changes to the code, should I create a PR to make it easier to review?

FYI I am considering creating a new repo for assorted plugins under the grblHAL umbrella - open for contributors to manage themselves. Is something like this you are thinking about when considering how to evolve things from a repo perspective?

[5ocworkshop]

Thank you for the warm welcome, really enjoying being here. Sorry for the delayed responses, I had to travel for a few days.

I'm pretty new to github so probably not a good person to be managing a repo at all, if I'm being honest. I feel guilty putting any additional work on your plate for Andrew's but I suspect I would be more of a barrier than an positive contributor on that front until I have more time to get up to speed on the workflow.

[5ocworkshop]

Terje,

Andrew Marles has developed a board he is calling the PicoHAL that has an RS485 interface and a Pi Pico MCU as well as support for RGBW and Neopixel lights, in an Arduino compatible form factor. The idea being to offload more complex I/O functions, things like lights, ATC control etc. and provide a platform that makes this more accessible via uPython and the related development/debug environment. This was features can be added by end users without having work directly in the grblHAL core.

Looking at the structure of your rewrite of the RGB plug-in, I was thinking it would be relatively easy to extend it to support remote lights via the PicoHAL, so instead of running the commands locally, just sending the relevant events in each section over RS485 to the PicoHAL as an option. This way a user could use the RGB module locally or as a structure to send the details remotely.

In this same vein, thank you for adding support for reporting the axis that the homing/endstop is triggered on. At the Neopixel level I am hoping to add some animation to the alarm lights, and things like a little visual indication to "point" to the axis to make it even more obvious which one is triggered beyond just the axis colour indication.

I also have a few ideas in my head about using the MPOS coordinates to potentially do some fancier things when a NeoPixel strip is used, so I'm hoping we can pass the MPOS coordinates along to the RGB plugin with the alarm event.

[5ocworkshop]

Conversely, the RS485 module could be more generic and it's own module completely and we can just recreate the RGB/Neopixel functionality in uMicropython completely downstream. There are arguments for doing it that way, as it is much more extensible of course. The RGB module is kind of a one-way example as it is always responding to events and doesn't have any application I can think of where it needs to feed back to the HAL core. But an example like ATC is potentially more interactive with the core? I'm not sure all the steps involved there, just trying to consider various scenarios.

Given your vision for the event handling and how to separate different layers of functionality, how would you prefer things to unfold?

[terjeio]

You may have seen that the plugin uses the new core RGB API calls if available. This means that it can be used with any driver that implements it. I have already added driver level Neopixel support via this API to ESP32 (uses the RMT peripheral), RP2040 (uses a PIO state machine), iMXRT1062 (Teensy 4.x, uses a UART channel) and STM32F4xx (uses a SPI channel). Your plugin works with all.

Driver code, or a plugin for that matter, can implement the RGB API in any way it wants - Modbus over RS485, I2C, SPI, CAN, MQTT, ... - your plugin will work regardless. So your plugin has its place as-is, it bridges core events with light output.
You may also have noted that I have encapsulated your code in a #if STATUS_LIGHT_ENABLE == 1 ... #endif block. The 1 used to add it to the compilation is for your implementation, any other implementation will get a higher number assigned.

Given your vision for the event handling and how to separate different layers of functionality, how would you prefer things to unfold?

I prefer to keep code layered, adding HAL APIs where it makes sense. Combined with (core) events it opens up grblHAL for plugin development that can go in many directions. grblHAL is becoming (or rather already is) a specialized OS?

FYI I have added a template plugin that implements the Marlin M150 command, this can be enabled alongside your plugin. E.g. the P parameter it supports can be used to control LED intensity (brightness), even for LEDs used by your plugin. It also has a $-setting for Neopixel strip length - later I will move this to the core.

Note that there is one tricky part to implementing the RGB API, it should not block the main thread for long - especially so during motion. The ones that I have added uses DMA (I am not 100% sure about the ESP32 one) to avoid that. Sending commands to a downstream device via a non-blocking protocol might thus be a good solution, this since the pins available for some of the DMA implementations are severely limited.