I think I don't fully understand the features of Chilipeppr.

I think I don’t fully understand the features of Chilipeppr. Recently, my SPJS got disconnected. Upon reconnection, my visualization is updated and my axis values are updated as well.

Feedhold turns off the laser automatically (despite my reading of grbl doing no such thing to spindle upon feedhold).

What other features am I missing out on?

A lot of work has been done to ensure no lost gcode on a disconnect. Each time chilipeppr sends gcode it waits for a receipt. If it does not get that receipt it will buffer the sending until a reconnect. It’s not perfect yet but not bad. If you reconnect you will get updated coordinates as well because on connect coordinates are either asked for or pushed to you.

As for the laser turning off that is odd. No m5 or m3 is automatically sent or queried for. What commands does your laser widget watch for?

I was using the “feed hold” button by Jarett’s grbl widget. Interestingly, it would stop my laser. But then I had some weird issue later on where a supposingly G0 move between shapes to cut turn into a normal G1 move with the laser on. :expressionless: That makes an extra cut between the shape. Good thing it was moving very slowly.

I got to use the awesome feature of the gcode widget to resume cutting by moving to a location on gcode and start the gcode file from there. Very well done. Although, it seems that if I choose the first line of the following block as the new start line, it doesn’t run the first line (and thus doesn’t turn on the laser).

M3
G1 X10 Y10
G1 X0 Y10
G1 X0 Y0
G1 X10 Y0
G1 X10 Y10
M5

Perhaps a bug? Can someone else try to reproduce?

http://www.chilipepper.com/grblLaser is the workspace that I am working on. I was trying to see what feed hold send. When I tried clicking on it, it does stops the machine and turn off the laser.

My first thought was it was a feature that grbl implemented in their firmware. An open bug on github shows otherwise. So I thought @Jarret_Luft did the work. I have been trying to get some confirmation but none so far. This is rather bewildering.

Hmm, that is very strange indeed. Can you try clicking the feed hold button while running a G1 command? A very slow move for example.

Type all these commands
G0 X0 Y0
M3
G1 X0 Y100 F1
M5

While it is moving, click the feed hold button. Is D12/D13 still high? Also which grbl version are you on?

I am on 0.8c. Hmm. Also I notice that on feed hold I cannot change spindle via grbl. I. E. M3 and m5 doesn’t work. Is this the case for you as well.?

There is thus a small problem. Let’s say I want to feed hold and leave for a bit before coming back.

I perform feed hold, then I have no way to turn off the spindle without soft reset (losing current position). If I type M5, wouldn’t that get buffered so when I feed resume, the M5 is at the last of the queue?

Yeah, i’ve had that problem too where I have a job queued up and I want to pause (feedhold) and then send in a motor de-energize command {“md”:""} and this binary pause/unpause is kind of ruining that.

What if we invent a new command of !! and that means only have SPJS pause sending in Gcode, but don’t send feedhold to the CNC controller, rather allow the CNC controller to finish processing whatever is in it’s buffer. (Which is usually only like 4 lines of Gcode).

Then, you can send whatever commands you want into your CNC controller like M3/M5 and it will happily do your bidding.

Then, to get SPJS to start sending its queued up Gcode again you send ~~.

That is a decent solution. I guess feed hold is not a replacement for a real estop button.

! feed hold is interesting. I make sure it gets sent to the front of the queue in SPJS. So it gets there fast and will pause. However, it is definitely not a replacement for an e-stop. Imagine your websocket drops right at the moment you’re trying to send feed hold.

I think from my perspective, with the browser and SPJS model, we’ve got 3 layers we’re dealing with 1) browser sending 2) SPJS queuing 3) the buffer on the controller. ! pauses at layer 3 and thus layer 2 and 1 get paused. I’m trying to figure out a pause at layer 2 without pausing layer 3. Once we have that we can pause a job at layer 2 and still send in interactive commands to layer 3 like a motor de-energize. If you look at my tool change M6 code I pause at layer 1. I think that’s ok for now, but perhaps it would be cooler to pause just layer 2. Let you do your tool change and then unpause layer 2.