V1.17 Ignores G4 dwell time when starting from line xxx

When using start from line #" gSender ignores the dwell time for the spindle to get up to speed. Instead it moves to the start position and jams the slowly turning bit into the work piece.

Test code below: Starting at line 35 (S18000 M3) in the (Drill1 2) section it starts the spindle but does not wait for the dwell time of 18 seconds.

(1 2 tool test)
(Machine)
( vendor: CNC4Newbie)
( model: HSNC)
( description: Generic 3-axis)
(T16 D=4 CR=0 TAPER=118deg - ZMIN=-3 - drill)
(T15 D=3.18 CR=0 TAPER=90deg - ZMIN=-3 - spot drill)
G90 G94
G17
G21
G28 G91 Z0
G90

(Drill1)
T16
S18000 M3
G4 P18
G54
G0 X10.794 Y37.738
Z15
Z5
Z2
G1 Z-3 F1000
G0 Z5
Z15
G28 G91 Z0
G90
G28 G91 X0 Y0
G90

(Drill1 2)
M5
M6
T15
S15000 M3
G4 P18
G54
G0 X38.263 Y16.278
Z15
Z5
Z2
G1 Z-3 F333.3
G0 Z5
Z15
G28 G91 Z0
G90
G28 G91 X0 Y0
G90
M5
M30

Evening

I’m not entirely sure that a dwell command is available for use in Gnea/Grbl 1.1h.
It exists in Linux CNC and others though

Yes Grbl 1.1 supports it and it normally works fine. The code I included is run from the beginning the dwell works fine. It just doesn’t work when Starting from Line # is used.

Does it show anything in the console?
Are you getting an ok response or is it just not being sent?

I did a test, first running through the whole program ( 2 different tools), then again starting from line 35. Running through the whole thing the dwell works OK. When started from line 35 the console capture shows G4 P1 instead of G4 P18, so it only waited 1 second. It also added the word “feeder” at the beginning of some lines. I don’t know why it’s doing this, but it sure ruined a bit and the work piece first time! I have attached the two text files with the captures.

console capture workingOK.txt (285 Bytes)
console capture bug.txt (418 Bytes)

What happens if your start at line 32?

Starting from line 32:
I moves down to Z25
Moves to X38.263 Y16.278
Down to Z15
Then starts the spindle and waits the 18 seconds for the spindle to ramp up.
Then moves down & starts the cut.

This is OK. Doesn’t destroy the mill and work piece!
Still questions though:
Why did it not do the dwell when started from line 35?
Why does it now move over and down before starting the spindle? It is still not doing the instructions in order.
Why did it move down to Z25 before doing the XY move?

My guess, without looking at the code, is that you and gSender have a different way of determining the line number.

Moving to a safe height probably. Not checking to see if it’s moving up or down.

They’re doing their best to start a program in the middle without the crashes and loss of position that can happen when you just cut out headers and ignore previous states.

Neil
I pasted the code from the original .nc file in the original post. Is this the right place for reporting bugs?

1 Like

I meant I haven’t looked at the gSender programming to see how they count lines. You have a couple of blank lines in your gcode. I think it’s possible that those aren’t counted by gSender.
I think you might be better posting on GitHub if you believe it’s a bug. That said, I’ve posted here for things.

Hey,

So this isn’t really a bug but a behaviour in how start from line works. We parse out modals and movement position up until the requested line, send that as a preamble, and then start the file from the requested line. We don’t currently parse out dwells since we’re more concerned with moving to the correct spot and making sure the modals up to that point are correct.

We’re still thinking of the best way to handle this and are leaning towards having start from line run the start event gcode - so if you want a dwell for your spindle to speed up, you could add it there and it would be injected before the rest of the generated gcode. So, as an example, you could add your 18 second dwell as the start event gcode - start from line would run that, then the generated preamble, then the file starting at the requested line.

The other alternative is to start parsing dwells in start-from-line which might be problematic (how to handle multiple? Do we take longest? Do people without spindles care? etc.)

If you think either of those would work better for your use case, let us know.

We remove blank lines and they aren’t counted wrt line numbers.

Kevin

1 Like

I think this could be avoided if their was a way to see the line numbers as seen by gSender.
I can see where issues could arise of one opens a gcode file in a text editor to get the line number. Empty lines are still numbered in most editors.

Yes, that’s what I did. Opened in Notepad++ to get the line number. I agree it would be good if you could view the code within gSender as gSender actually sees it. And would being able to do a quick edit be too much to ask for? :slightly_smiling_face:

Maybe a g-code editor should be incorporated into gSender, with line numbers and what ever else a good editor could provide.

1 Like