Laser power set-point not restored following feed-hold with "Disable Laser during hold" set to False

[engigeer]

I encountered a potential bug where if the first bit of Feed hold actions $63 (i.e., Disable laser during hold) is false, the power set-point is not restored on resume and therefore the laser does not continue firing.

I have tested and the issue appears to be resolved by adding:

sys.step_control.update_spindle_rpm = On;

following line 694 in state_machine.c

core/state_machine.c

Lines 676 to 700 in b9a05f1

	default:
	if (!settings.flags.restore_after_feed_hold) {
	if (!restore_condition.spindle[restore_condition.spindle_num].hal->get_state(restore_condition.spindle[restore_condition.spindle_num].hal).on)
	gc_spindle_off();
	sys.override.spindle_stop.value = 0; // Clear spindle stop override states
	} else {
	if (restore_condition.spindle[restore_condition.spindle_num].state.on != restore_condition.spindle[restore_condition.spindle_num].hal->get_state(restore_condition.spindle[restore_condition.spindle_num].hal).on) {
	grbl.report.feedback_message(Message_SpindleRestore);
	state_spindle_restore(&restore_condition.spindle[restore_condition.spindle_num], settings.spindle.on_delay);
	}
	if (restore_condition.coolant.value != hal.coolant.get_state().value) {
	// NOTE: Laser mode will honor this delay. An exhaust system is often controlled by coolant signals.
	coolant_restore(restore_condition.coolant, settings.coolant.on_delay);
	gc_coolant(restore_condition.coolant);
	}
	sys.override.spindle_stop.value = 0; // Clear spindle stop override states
	grbl.report.feedback_message(Message_None);
	}
	break;
	}

[terjeio]

Issue is that the laser is disabled in the first place, it should not be (for M3). Will fix in the next commit.

[engigeer]

Issue is that the laser is disabled in the first place, it should not be (for M3). Will fix in the next commit.

Hmm. The current behaviour (temporarily setting power to zero) on feed-hold is actually quite useful for interfacing with my laser - albeit only if it restores the previous power on resume.

Setting $63=1 causes issues for me since there is an expected delay between enabling the laser source and actually emitting power. This actually also occurs when setting the power, but I have a workaround for this to handle the transitions between G0 and G01, so it is somewhat preferable to use this same solution for feed-hold.

If you intend to “fix” the behaviour with $63=1, I wonder if you would be open to retaining the option for setting power to zero on feed-hold. Maybe with an additional setting flag?

[engigeer]

For context on the above, I will add that my workaround for turning the laser on / off smoothly with G0 to G01 transitions happens in the laser interface board (picoHAL), which grblhal just treats as a Modbus spindle.

The laser I’m using requires 3 signals to fire: (1) enable, (2) power setting > 0, and (3) modulation high. The first two signals are not suitable for turning the laser on/off in sync with movement. To resolve this, I have programmed the modulation so that when the laser is enabled, non-zero power commands set the signal high, and zero power commands set it low. If the power set point is non-zero and different from current, this change is passed along to the laser but otherwise the power and enable signal remain active while in M3.

The one challenge I have with this (which perhaps you have some thoughts on), is the initial setting of the power. Currently, in laser mode, the power cannot be set via M5 SXXX, the S value is recorded but not passed to the spindle until turned ON via M3. Ideally, I would like to be able to set the power while the spindle is OFF like this. Is this something you would be open to considering for a PR?

[terjeio]

Is this something you would be open to considering for a PR?

A plugin can hook into spindle->set_state and get the RPM from spindle->param, you may have to use the raw RPM and add any override for spindle off. Could that work?

[engigeer]

Is this something you would be open to considering for a PR?

A plugin can hook into spindle->set_state and get the RPM from spindle->param, you may have to use the raw RPM and add any override for spindle off. Could that work?

I think I understand how I could use this to set the speed as desired while the spindle is off, but I wonder how would be best to trigger a call to spindle->set_state? It seems if the spindle is already off issuing an M5 will not clear this check:

core/gcode.c

Line 4054 in 44aa58f

if((spindle_ok = sspindle->state.value != gc_block.spindle_modal.state.value)) {

I guess maybe I could send a sequence like:

M5 S0  (ensure power is zero so that laser won't fire - maybe not necessary)
M3     (temporarily enable laser so next M5 is recognized)
M5 S#  (set laser power)
G0     (ensure rapid mode so laser won't fire)
M3     (enable laser for next G01 move)

and if I set my hooks properly the power command could be passed through on M5 even if rapid mode

This is a bit more of a 'hack' than I was hoping for, but perhaps I am making it more complicated than it needs to be . . . I could also just implement a user M-code to set the power in my spindle driver, but I thought it could be worth addressing in the core if it might help others who are working with lasers.

[terjeio]

I do no think I will change the line 4054 check since it may introduce unwanted overhead.
One solution could be to add a compile time option for a new event fired prior to gcode execution (STEP 4) that passes a pointer to the gc_block and possibly gc_state and sspindle. Would that be useful?

[Deltaplc]

I encountered a potential bug where if the first bit of Feed hold actions $63 (i.e., Disable laser during hold) is false, the power set-point is not restored on resume and therefore the laser does not continue firing.

Hi,
Sorry to butt in...
@engigeer ,
Does the problem you're experiencing occur when you pause the machining process via the software or when using a dedicated button?
I also use grblHAL to control a laser and have set $63 = 3; I don't have any issues when pausing the job—when I resume, the laser fires correctly!

The laser I’m using requires 3 signals to fire: (1) enable, (2) power setting > 0, and (3) modulation high.

With this type of input, I think you are controlling a CO2 laser...

The first two signals are not suitable for turning the laser on/off in sync with movement.

Why do you say that these inputs are not suitable for controlling the laser?What problems are you experiencing?

[engigeer]

Hi, Sorry to butt in... @engigeer , Does the problem you're experiencing occur when you pause the machining process via the software or when using a dedicated button? I also use grblHAL to control a laser and have set $63 = 3; I don't have any issues when pausing the job—when I resume, the laser fires correctly!

I believe the issue has been addressed in the latest commit but also only occurred if the first bit of $63 was false, which would not be the case for $63=3.

With this type of input, I think you are controlling a CO2 laser...

The laser I'm controlling is a bit higher power than most hobby machines (industrial fiber laser source), and the most convenient way to set power via HTTP POST requests. Latency from this communication protocol is part (or even most) of the issue, which is why I have hardwired the modulation signal and am using that to control the on-off timing when transitioning from G01 to G0.

The first two signals are not suitable for turning the laser on/off in sync with movement.

Why do you say that these inputs are not suitable for controlling the laser?What problems are you experiencing?

It's possible I could use the enable signal, but the laser manufacturer documentation is somewhat unclear on how whether the latency would be sufficient and this would cause some issues with my safety indicators (which are only lit when laser is enabled so would flash on and off at the transitions from G01 to G0) so I prefer to use the modulation.

Power set point would only work if controlled via analog signal, which is an option, but less convenient than using HTTP since I need to add a calibration curve for the power settings rather than just commanding the value directly.

[engigeer]

I do no think I will change the line 4054 check since it may introduce unwanted overhead. One solution could be to add a compile time option for a new event fired prior to gcode execution (STEP 4) that passes a pointer to the gc_block and possibly gc_state and sspindle. Would that be useful?

That makes sense. I think this could indeed be useful since if I understand correctly, I could then read/write these structs in plugin code? I will do some testing / thinking to see how I could best use this functionality.

[engigeer]

If you intend to “fix” the behaviour with $63=1, I wonder if you would be open to retaining the option for setting power to zero on feed-hold. Maybe with an additional setting flag?

@terjeio, any thoughts on the above? I could draft a PR if this is something you would be open to.

[terjeio]

If you intend to “fix” the behaviour with $63=1, I wonder if you would be open to retaining the option for setting power to zero on feed-hold. Maybe with an additional setting flag?

@terjeio, any thoughts on the above? I could draft a PR if this is something you would be open to.

$63=0 is not what you want? Or do you want a new flag for $9 overriding $63=1?

The new event allows you to modify the structs, which is kind of dangerous - that is why I will make it a compile time option. BTW I'll add the event in the next commit since it is needed for G70-G72 lathe cycles.

[engigeer]

If you intend to “fix” the behaviour with $63=1, I wonder if you would be open to retaining the option for setting power to zero on feed-hold. Maybe with an additional setting flag?

@terjeio, any thoughts on the above? I could draft a PR if this is something you would be open to.

$63=0 is not what you want? Or do you want a new flag for $9 overriding $63=1?

Since the way that transitions from G01 to G0 disable the laser is by setting S0, I have configured my laser to treat an S0 command while the laser is enabled as a signal to temporarily toggle the modulation off. This gives me the low latency performance I need. I would also like to toggle this modulation off during feed-hold, so ideally I would like to be able to set S0 on feed-hold but leave the laser enabled.

Currently with $63=1 I get S0 but also laser enabled, and with $63=0 I get neither.

I don't believe a $9 setting would work for me here since I am not using the driver PWM spindle/laser, but rather a modbus spindle/laser via the picoHAL plugin. But perhaps I am misunderstanding.

The new event allows you to modify the structs, which is kind of dangerous - that is why I will make it a compile time option. BTW I'll add the event in the next commit since it is needed for G70-G72 lathe cycles.

Sounds good, and I will proceed with caution in my testing once these changes are committed.

[terjeio]

Committed now, currently I only enable the event for UVW lathe mode - a new guard symbol has to be added for your use case.

Could hooking into this event be used to solve your $63 issue?

[engigeer]

Could hooking into this event be used to solve your $63 issue?

I'm not sure that this would work for feed-holds, since it seems that this event would only be called when the g-code is read into the buffer.