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.
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.
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.
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.
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.
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.
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?
