Possible to add $ettings from plugin without modifying the core?

[andrewmarles]

I am currently working to add some more VFDs to the spindle plugin and also make it so that the VFD can be selected at runtime. For now I have added a couple of settings to drive this:

Adding these seems to require modifying settings.h in the grbl repo just to add the two entries

    Setting_VFD_TYPE = 395, // Select from available VFD types
    Setting_VFD_RPM_HZ = 396, // Set RPM/Hz (not used by all VFD types)

Is this the correct approach? Is there a way to contain the settings within the plugin itself?

Current WIP is pushed up here:
https://github.com/Expatria-Technologies/Plugins_spindle/tree/vfd_support

Durapulse is tested and working (making parts on my machine) and am just adding YL and H100 before making a PR.

[terjeio]

Is this the correct approach?

Yes.

Is there a way to contain the settings within the plugin itself?

You mean the setting numbers? These should be added to the core for settings that are public (shared code). Handling of the settings should be in the relevant plugin - many does that already.
IMO a generic spindle type selection plugin should be added (or the current M-code addition enhanced), or perhaps even core code, where spindle plugins register themselves and where generic settings are handled - maybe only the spindle type? Also, the spindle type setting should be added under the Spindle group, not the ModBus group as other communication protocols might be added later?

[andrewmarles]

Yes, I do agree with making Modbus it's own plugin separate from spindle. I think I only need to make a couple of small edits and then the new VFD selection code is basically independent of the modbus code - currently just the modbus_settings array is modified when VFD_ENABLE is defined.

[andrewmarles]

Following up on this since I am here, I think this would be the correct approach for spindle selection (adopt the LinuxCNC convention). I think some other projects have used M6 to change spindle types, and I do not think that is really ideal since ATC spindles are becoming much more common and the industry convention is to use M6 for toolchanges.

[terjeio]

FYI I have started adding spindle registration/selection/configuration to the core, hopefully I'll be able to come up with something useful in the next few days.

[terjeio]

Here is a preview of the changes:

GRBL Driver STM32F401.zip
#define DUAL_SPINDLE in my_machine.h is replaced with #define N_SPINDLE <n> in grbl/config.h, N_SPINDLE defaults to 1 and can be set to max 8. When set > 1 dual spindle support is enabled if more than one spindle is registered in the core.

Spindle capabilities flags in the hal.driver_cap variable has been moved to a new hal.spindle.cap variable to simplify registration and spindle switching. Spindle registration is done by the spindle driver code setting up a spindle_ptrs_t struct and calling spindle_register() with a pointer to the struct and the name of the spindle, here is how it is done in the Huanyang driver code:

void vfd_init (void)
{
#if VFD_ENABLE == 1 || VFD_ENABLE == -1
    static const spindle_ptrs_t v1_spindle = {
        .cap.variable = On,
        .cap.at_speed = On,
        .cap.direction = On,
        .config = v1_spindle_config,
        .set_state = v1_spindleSetState,
        .get_state = v1_spindleGetState,
        .update_rpm = v1_spindleUpdateRPM
    };
#endif
#if VFD_ENABLE == 2 || VFD_ENABLE == -1
    static const spindle_ptrs_t v2_spindle = {
        .cap.variable = On,
        .cap.at_speed = On,
        .cap.direction = On,
        .config = v2_spindle_config,
        .set_state = v2_spindleSetState,
        .get_state = v2_spindleGetState,
        .update_rpm = v2_spindleUpdateRPM
    };
#endif

    if(modbus_enabled()) {

#if VFD_ENABLE == 1 || VFD_ENABLE == -1
        v1_spindle_id = spindle_register(&v1_spindle, "Huanyang v1");
#endif
#if VFD_ENABLE == 2 || VFD_ENABLE == -1
        v2_spindle_id = spindle_register(&v2_spindle, "Huanyang P2A");
#endif
        if(v1_spindle_id != -1 || v2_spindle_id != -1) {

            on_spindle_select = grbl.on_spindle_select;
            grbl.on_spindle_select = huanyang_spindle_select;

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

            driver_reset = hal.driver_reset;
            hal.driver_reset = huanyang_reset;
        }
    }
}

Note: the .config function is optional and will be called when the spindle is selected.

If N_SPINDLE is set to 1 the first spindle registered will "block" the standard PWM spindle and become the only one available. If N_SPINDLE is set > 1 the first N_SPINDLE - 1 spindles registered will become available and can be selected by setting $395 to a spindle id allocated by the registration call. Spindle id 0 is always allocated to the basic PWM spindle provided by driver.c.

The VFD_ENABLE enable symbol (in my_machine.h) can still be used to enable/register a specific VFD spindle, however VFD driver code can opt to also register itself when VFD_ENABLE is set to -1 allowing it to be selected by the $395 setting depending on N_SPINDLE beeing set > 1 and high enough to allow its registration.

The $32 (laser mode) setting can no longer be used to switch between the standard PWM spindle and a VFD spindle, either use $395 or M104P0 (to select the PWM spindle) or M104P1 to select the configured VFD spindle. $32 laser mode will be ignored if the spindle selected is not flagged as laser capable.

Currently only one spindle can be active at a time, later I plan to add support for multiple active spindles that can be controlled by the $ word in gcode in the same way as LinuxCNC does.

[terjeio]

The previous comment was saved by accident before it was finished, sorry about that.

Does the change make sense?

[andrewmarles]

This looks very nice. I will work on pulling it into my VFD_Support branch and making a PR.

[terjeio]

I have now commited the changes, hopefully I have not broken anything...
Support for enabling multiple spindles selectable with $<n> in gcode will have to wait - I do not want to make too many fundamental changes at the same time.

FYI I have renamed the .init function pointer to .config and added RPM limits to the spindle struct. RPM limits defaults to the core settings values and can be overridden if a capabilities flag is set. I have also removed the SPINDLE_RPM_CONTROLLED and SPINDLE_PWM_DIRECT symbols - they are no longer used to guard code.

[andrewmarles]

Ok, I will let you know if I find any issues. Thanks very much for this, it will really help with our PrintNC standardization project to get everyone on a unified binary.