Advice to start developing a plugin

[mfp20]

Hi,

I'd like to develop a "composite driver" (a "plugin" in grbl jargon, "composite" because it enables multiple sensors and actuators) in order to re-use my MKS GENL boards. Those are 328p 3d printer boards I'd like to use for controlling everything except motors using a custom companion firmware and hooking the board via SPI to the grbl core on the main mcu (rpi pico).

HW wise is all good: level shifters and the picos can fit nicely on top and easily connected. First tests indicate they can work together.

The protocol might be 2 simple packetized binary streams, 1 per direction, to get sensors and set heaters/fans. Each packet the full set of sensors (in one direction) and actuators (in the other direction), 1 bit per sensor/actuator.
Given the relatively slow speed of the heating/cooling/endstops, it should work nicely.

As I've just started to look at the new grbl code in this repo, I'd be grateful to get some tips to help me getting started, as well as pointing me to similar projects if they already exist.

Thanks

[terjeio]

If you want it to be flexible you may encapsulate the data transfers as auxillary I/O and write a plugin on top of that. There are several plugins that claims auxillary I/O ports and provide a set of M-codes to control them: fans, OpenPNP and laser coolant are among them.

Auxillary I/O is supported by many drivers, typically the code is found in a file named ioports.c, there is also a template available.

Of course you may put everything in the same file and not bother to write auxillary I/O support code, but if you do you get both a standard API and M-codes to handle the extra I/O without any additional coding effort.

[mfp20]

Nice, thanks. That's exactly the kind of help I was searching for.

Is there any document describing the overall architecture? I can't figure out how grblHAL works in general. I mean, the loop, if there is a state machine or ...

[terjeio]

Here is an article about Grbl, grblHAL is mostly the same except all direct hardware access has been abstracted out (of the core). It is also possible for user code to subscribe to a number of core events. Both uses function pointers to facilitate dynamic linking, code can then be swapped in/out as needed at runtime.

The main loop is in protocol.c and the main state machine is in state_machine.c The original state machine was rather unreadable so grblHAL has it in a separate file and it uses a function pointer instead of a ton of nested if then else constructs to handle states.

[mfp20]

Good stuff, thank you.