Selecting different machine profiles.

[phil-barrett]

So a number of people are putting lasers on their machines next to their spindles. With significantly more powerful diode lasers (40W actual power available now), it is looking like a pretty desirable thing to do. (I'm not going to worry about the safety of this, people are doing it anyway.)

The problem is switching between using a spindle and a laser is clunky. You need to make sure the right one is on and the wrong one is off. You also have to change $32. I've worked out a couple of ways to ensure that only one tool is active at a time but switching $32 seems easy to forget. I do not think there is a way to have an output that says whether grblHAL is in normal or laser mode so the only way is to look at the setting. I don't even know if a plug-in could be written to do that. You can put $32=1 in a macro but not GCode.

So, any ideas or thoughts? My ideal would be a switch on the machine that you could flip to Laser or Spindle and everything would just work.

[terjeio]

There are several options available.
All drivers supports a PWM spindle with on/off and direction signalling, although not all boards maps the direction signal to a pin. PWM type spindles are the only spindles that can support laser mode. The spindle plugin adds a number of different Modbus controlled VFDs and, recently, a stepper driven spindle. If the controller is configured with both the PWM spindle and a Modbus controlled VFD spindle available selection can be done by three different metods: M104, tool number (T) or by adding $<n> to spindle commands where <n> is the spindle id. E.g. M3$1S200 will turn on spindle 1 at 200 RPM. Note that the latter only has limited support for now.

What is currently not available is the option to have additional PWM spindles or the option to route the default PWM spindle output to two different spindles. This can more or less easily be "fixed" by plugin code, possibly also by the extending the spindle plugin.
Additional PWM spindles can be added by a plugin by:

1. providing the complete code needed. This would be MCU specific and requires a PWM capable timer output.
2. code it on top of the analog I/O interface by claiming an analog PWM port. This would be available for all driver/board combos that provide such an output.

Routing the current PWM spindle output(s) to two or more spindles can be done by adding a switch (relay?) that is controlled by a pin.

I do not think there is a way to have an output that says whether grblHAL is in normal or laser mode so the only way is to look at the setting.

Plugin code can subscripe to the grbl.spindle_selected event and thus get access to all spindle parameters, including the flag that tells the core that the spindle is capable of handling laser mode. The capability is controlled by the $32 setting and can be overridden by plugin code.

My ideal would be a switch on the machine that you could flip to Laser or Spindle and everything would just work.

A plugin can claim an interrupt capable aux input and call spindle_select() on a state change to select the spindle.

The next major commit will change how additional spindles are included in a build, up to four specific spindles can be enabled in my_machine.h (or by drop-downs in the Web Builder):

// Up to four specific spindle drivers can be instantiated at a time
// depending on N_SPINDLE and N_SYS_SPINDLE definitions in grbl/config.h.
// If none are specified the default PWM spindle is instantiated.
// Spindle definitions can be found in grbl/spindle_control.h.
// More here https://github.com/grblHAL/Plugins_spindle
//#define SPINDLE0_ENABLE      SPINDLE_STEPPER
//#define SPINDLE1_ENABLE      SPINDLE_PWM0
//#define SPINDLE2_ENABLE      SPINDLE_NONE
//#define SPINDLE3_ENABLE      SPINDLE_NONE
// **********************

To conclude: the core has the needed functionality to handle multiple spindles and switching between them. Driver and/or plugin code is needed to make them available.

[phil-barrett]

That is fine. I appreciate your efforts.

[andrewmarles]

While implementing a dual pwn design I ran into this as well. In addition to adding settings for separate pwm settings we also found it useful to extend the $spindles report so that the sender could read the spindle capabilities and currently active spindle.

https://github.com/Sienci-Labs/grblhal_core/blob/97cac0bb062838acecda2c5f7908fcaa93d624cf/report.c#L2204C1-L2204C1

Is it at all possible to get a look at how you want to extend the settings so that we can make sure things line up properly?

[terjeio]

... extend the $spindles report so that the sender could read the spindle capabilities

IMO the *spindles report should then be extended to output either machine or human readable format. Similar to how $ES and $ESH is implemented.

Is it at all possible to get a look at how you want to extend the settings so that we can make sure things line up properly?

New setting id's:

    Setting_RpmMax1 = 730,
    Setting_RpmMin1 = 731,
    Setting_Mode1 = 732,
    Setting_PWMFreq1 = 733,
    Setting_PWMOffValue1 = 734,
    Setting_PWMMinValue1 = 735,
    Setting_PWMMaxValue1 = 736,
// Optional driver implemented settings for piecewise linear spindle PWM algorithm
    Setting_LinearSpindle1Piece1 = 737,
    Setting_LinearSpindle1Piece2 = 738,
    Setting_LinearSpindle1Piece3 = 739,
    Setting_LinearSpindle1Piece4 = 740

Note that a spindle driver may not implement all. Setting_Mode1 is one that might not even be needed.
I have code ready (for testing) that implements a PWM spindle on top of the ioports API, for now somewhat limited in capabilities. In addition I plan to add an optional driver based PWM spindle (code in driver.c or in board specific code) to the most used drivers. Currently my idea is to make these mutually exclusive and thus use the same setting id's above.

[terjeio]

New machine readable spindle report, $SPINDLESH, example:

[SPINDLE:0,0,0,DLIRV,PWM]
[SPINDLE:1,-,0,IV,Cloned PWM spindle]
[SPINDLE:2,1,2,SDVE,Yalang YS620]
ok

This example is from when N_SYS_SPINDLE is set > 1 to allow more than one active spindle.
When N_SYS_SPINDLE == 1 the current spindle has * at the start of the capabilities string.
The E capability is added when the spindle has an encoder associated with it.

Code:

static void report_spindle (spindle_info_t *spindle, void *data)
{
    if(data) {
        char *caps = buf;
        hal.stream.write("[SPINDLE:");
        hal.stream.write(uitoa(spindle->id));
        hal.stream.write(",");
        hal.stream.write(spindle->enabled ? uitoa(spindle->num) : "-");
        hal.stream.write(",");
        hal.stream.write(uitoa(spindle->hal->type));
        *caps++ = ',';
#if N_SYS_SPINDLE == 1
        if(spindle->is_current)
            *caps++ = '*';
#endif
        if(spindle->hal->cap.at_speed)
            *caps++ = 'S';
        if(spindle->hal->cap.direction)
            *caps++ = 'D';
        if(spindle->hal->cap.laser)
            *caps++ = 'L';
        if(spindle->hal->cap.pid)
            *caps++ = 'P';
        if(spindle->hal->cap.pwm_invert)
            *caps++ = 'I';
        if(spindle->hal->cap.pwm_linearization)
            *caps++ = 'N';
        if(spindle->hal->cap.rpm_range_locked)
            *caps++ = 'R';
        if(spindle->hal->cap.variable)
            *caps++ = 'V';
        if(spindle->hal->get_data)
            *caps++ = 'E';
        *caps++ = ',';
        *caps = '\0';
        hal.stream.write(buf);
        hal.stream.write(spindle->name);
        hal.stream.write("]" ASCII_EOL);
    } else {
        hal.stream.write(uitoa(spindle->id));
        hal.stream.write(" - ");
        hal.stream.write(spindle->name);
        if(spindle->enabled) {
#if N_SPINDLE > 1
            hal.stream.write(", enabled as spindle ");
            hal.stream.write(uitoa(spindle->num));
 #if N_SYS_SPINDLE == 1
            if(spindle->is_current)
                hal.stream.write(", active");
 #endif
#endif
        }
        hal.stream.write(ASCII_EOL);
    }
}

[terjeio]

$SPINDLESH has now been added, with a slightly different syntax than shown above to keep it in line with other enumerations.

[distebia]

Seguo con interesse, aspetto la nuova build. Attualmente gestisco un co2+405nm mediante 1 uscita pwm che arriva ad un interruttore e devio il segnale dove mi serve, naturalmente a macchina spenta. Si potrebbe anche implementare un sistema per segnalare alla macchina l'esatto offset fra i 2 utensili. Altra cosa, non meno inportante, dovrebbe essere di mantenere il pin di uscita (al momento non utilizzato) in uno stato di 0v o qualcosa vicino. Questo in quanto se stacco il filo del pwm, o sbaglio a commutare, il co2 (o il diodo) si accende al 100% e questo è pericoloso