What is the block diagram of connecting a new plug-in? about core HOT 13 CLOSED

Is there was a way via the serial console to see what plugins are loaded and their version (I copied the version reporting from fan.c). I'm fairly certain the plugin is not being triggered, but I am unable to determine why.

$I will list all the loaded plugins. You would put your plugin name & version information in onReportOptions()

from core.

Hmm I thought that was the case with $I. Not only is my plugin not appearing but I haven't see the odomoeter one appear yet either. Will be looking at it again shortly with fresh eyes.

from core.

In the header file I call the init function.

Depending on where you include the header file it may never get called. It should be called at the end of the driver_init() function in driver.c. If the plugin is for your private use you can name the init function my_plugin_init(), it will then be called automatically - there is no need to modify any downloaded files at all.

Not only is my plugin not appearing but I haven't see the odomoeter one appear yet either.

Which driver are you developing for? SAM3X8E (Arduino Due)?
Note that the Odometer plugin will refuse to install itself if flash is used for settings storage, EEPROM or FRAM is required.

Development can sometimes be a bit tricky if a debugger is not used. And if debug (or startup) messages are written to an USB stream they may be lost as it may be impossible to connect to it before the messages are written. Some drivers may buffer them until a connection is made, others not. I prefer to use a UART stream when debugging using messages as this can be connected at all times.

from core.

Depending on where you include the header file it may never get called. It should be called at the end of the driver_init() function in driver.c. If the plugin is for your private use you can name the init function my_plugin_init(), it will then be called automatically - there is no need to modify any downloaded files at all.

I will rename it and try this to get it going.

Which driver are you developing for? SAM3X8E (Arduino Due)?

This is the new Teensy 4.1 based GrblHAL2000 board.

I prefer to use a UART stream when debugging using messages as this can be connected at all times.

Exellent points. I'll get a Pi set up on the UART so I can see debug messages that way.

from core.

Is there a graphical relationship between the various files available anywhere?

It would be good to understand the relationships visually.

I'm loooking for the driver_init() function, as I see multiple places that talk about enabling plugins but have not found a reference to my_plugin_init() yet.

I know a tremendous amount of thinking and work on the structure has gone in to all of this, and the potential seems tremendous - so thank you for all your work on it. I'll do what I can to try and document the process of wiring up a plugin for someone new who comes after me.

from core.

I believe I understand the chain now:

drivers.c (in the board top level directory) contains the function driver_init() which in turn includes grbl/plugins_init.h.

The call to my_plugin_init() is contained in grbl/plugins_init.h

The default template, in order to avoid the example being called, has an "x" in front of the example init structure which is to be removed to enable it.

So presumably the appropriate path is to develop a plugin as a private plugin using this structure, and when it is all working discuss how and where it will wire in once committed?

Going to try it now.

from core.

On build I am seeing this:

src\my_plugin.c:225:8: warning: return type defaults to 'int' [-Wimplicit-int]
static my_plugin_init ()
^
src\my_plugin.c:225:8: warning: conflicting types for 'my_plugin_init'
src\my_plugin.c:225:8: error: static declaration of 'my_plugin_init' follows non-static declaration
In file included from src\grbl/settings.h:29:0,
from src\grbl/core_handlers.h:30,
from src\grbl/hal.h:30,
from src\grbl/driver_opts.h:30,
from src\driver.h:37,
from src\my_plugin.c:12:
src\grbl/plugins.h:188:13: note: previous declaration of 'my_plugin_init' was here
extern void my_plugin_init (void) attribute((weak));
^
src\my_plugin.c:196:13: warning: 'output_warning' defined but not used [-Wunused-function]
static void output_warning (uint_fast16_t state)
^
src\my_plugin.c:202:13: warning: 'output_port' defined but not used [-Wunused-function]
static void output_port (uint_fast16_t state)
^
src\my_plugin.c:225:8: warning: 'my_plugin_init' defined but not used [-Wunused-function]
static my_plugin_init ()

from core.

My init function looks like this:

static my_plugin_init ()
{
    if(hal.port.num_digital_out >= 3) {

        hal.port.num_digital_out -= 3;
        base_port = hal.port.num_digital_out;

        if(hal.port.set_pin_description) {
            uint32_t idx = 0;
            do {
                hal.port.set_pin_description(true, true, base_port + idx, rgb[idx]);
                if (idx == 0) { red_port = idx; } else
                if (idx == 1) { blue_port = idx; } else
                if (idx == 3) { green_port = idx; }
                idx++;                
            } while(idx <= 2);
        }

        // memcpy(&user_mcode, &hal.user_mcode, sizeof(user_mcode_ptrs_t));  // Commeneted as may be used to allow mcodes in future

        // hal.user_mcode.check = userMCodeCheck;
        // hal.user_mcode.validate = userMCodeValidate;
        // hal.user_mcode.execute = userMCodeExecute;

        driver_reset = hal.driver_reset;
        hal.driver_reset = driverReset;

        on_report_options = grbl.on_report_options;
        grbl.on_report_options = onReportOptions;

        on_state_change = grbl.on_state_change;         // Subscribe to the state changed event by saving away the original
        grbl.on_state_change = onStateChanged;          // function pointer and adding ours to the chain.

        //on_program_completed = grbl.on_program_completed;
        //grbl.on_program_completed = onProgramCompleted;

    } else
        protocol_enqueue_rt_command(warning_msg);
}

from core.

Where in the directory tree is my_plugin.c meant to live?

I see there is a placeholder under grbl/my_plugin.c . Are you meant to replace that with the template code you build on that is in the root of the board directory above it?

from core.

I moved my code out of the way and renamed my init function.

I took the iMXRT1062/grblHAL_Teensy4/src/my_plugin.c and removed the x from the front of the my_plugin_unit function, built and flashed the image. $I does not report that the plugin is loaded.

As there is an additional file named my_plugin.c located at core/my_plugin.c I tried moving the file from the driver directory to the core directory, building and flashing. That also did not yield the expected report message when using $I.

What is the correct way to activate/hook the unmodified my_plugin.c code as a starting point?

from core.

OK, I finally have my plugin reporting as loaded. I think I ran myelf in circle trying to chase this down.

It seems like the warnings about line 188 of plugins_init.h conflicting can be safely ignored?

If I replace the my_plugin.c file in grbl/my_plugin.c with the template / my code and confirm that the init function in my_plugin.c is named my_plugin_init() (so remove the "x" that was prepended to the example) I can compile with warnings and run the code.

from core.

Where in the directory tree is my_plugin.c meant to live?

Wherever you want, but best practice would be to add your code in a subdirectory in the same place where the other plugins live.

As there is an additional file named my_plugin.c located at core/my_plugin.c I tried moving the file from the driver directory to the core directory, building and flashing.

Don't do that, it has a weak definition and will be overridden by your implementation.

It seems like the warnings about line 188 of plugins_init.h conflicting can be safely ignored?

Yes, but it is easy to fix. C functions with no declared return type defaults to int, set it to void and the warnings go away.

from core.

Yes, but it is easy to fix. C functions with no declared return type defaults to int, set it to void and the warnings go away.

Will do, thank you. Closing issue as it is fully resolved.

from core.