Run from line problem

Finally pretty tired of run from line and the disharmony with .ngc files with subroutines. I made this workaround, generating a temporary file containing the "remaining machining". So don't have to manipulate and edit the original file.
In my case there are 3 parts.

1 Toolchange

(Bohrwerkzeug 3.300000000000000)
T3
M61 Q3

2 Offset, S, F, G43 etc...

G0 G17 G21 G40 G49 G55 G80 G90 G94 M48
S12000 M3
G0 G55 G43 X-152.3489 Y-16.0697 F500.

3 Remaining Code

G0 X-190.6511 Y16.0697
Z4.0000
G1 Z1.0000
Z-1.2000 F200.
Z1.0000 F500.
Z-0.2000........

I made a subfolder in NcFiles: "RunFromLine" to keep the tmp file seperated, and the file named "RunTmp.ngc"
The script itself, named rfl.sh must be set executable, and i placed it in NcFiles folder, for easy access. Because it must be edited for each use.

In file1 the name of sourcefile, and the 3 groups of lines of code to be copied to a new file. In my Editor "Geany", the line numbers to be respected can be found easy. E3 is just a large number, to make shure to copy until EOF. After editing, run the script:
At the file location, "open Terminal from here" , type ./rfl.sh then open the generated file for machining and run it. Make shure the selection of the parts to be copied is carefully considered.


#!/bin/bash
#******************************************************
file1=/home/miller/NcFiles/Scara2T.ngc

A1="15"
E1="18"

A2="27"
E2="30"

A3="141"
E3="10000000"
#******************************************************

file2=/home/miller/NcFiles/RunFromLine/RunTmp.ngc
echo " (Run From Line Source: $file1)" > $file2
echo "" >> $file2

echo " (lines $A1 - $E1)" >> $file2
echo " (lines $A2 - $E2)" >> $file2
echo " (lines $A3 - $E3)" >> $file2
echo "" >> $file2

sed -n "$A1,$E1"p $file1 >> $file2
sed -n "$A2,$E2"p $file1 >> $file2
sed -n "$A3,$E3"p $file1 >> $file2
exit 0

I don't want to offend the maker of run from line, but with my configuration it definitely don't work.
Probing is started, or a rapid across the machine, or rapid in Z down to hell...
That is why I work on a workaround for me. The first attempt with the script is a safe way, but not so comfortable.
So now I work with a Filter, easy to stay in the machining environment, but also here its good advice to carefully select
the sections to be used for machining.
The following text is from the rfl.py file.

# If you are working with many subroutines, there likely would happen some problems with run from line
# for safe workflow this filter can be used, you decide which lines in your code will be used for machining.

# ini [FILTER]
# PROGRAM_EXTENSION = .py Python Script
# PROGRAM_EXTENSION = .rfl RunFromLine

# py = python
# rfl = /home/path/to/folder/rfl.py

# sudo chmod 755 /home/path/to/folder/rfl.py and set executable.

# Make a copy of your ngc file, attach ending .rfl to your ngc file to make it recognized by the filter.
# eg AirguideX.ngc.rfl It is tested with AXIS.
# Always 2 lines must have at least the comment (rfl). For better understanding,
# (rfl_s), (rfl_e) etc is accepted. Case sensitive, at least ' rfl ' must be lower case.
# So this lines and the lines between are in the filtered file for machining now.
# The last section until EOF, only need the start mark. If you don't go to EOF, last line with M30 needs (rfl) also.

That was interresting. The machine with Debian Stretch, RT-PREEMPT and 7i76E/7i73. For Testing and preparing Debian Stretch, RT-PREEMPT on my Laptop in a Virtual machine, with definitions of the machine.
Probing is excluded in the sim by ini parameter. Just for testing, i modified the probing subroutine to run in the sim. Without any subroutines, run from line is working, tool offset, coordinate system, spindle speed seems correct.
When there are subroutines before the line to run, some, or all of them are executed first. Probing, offsets logging, and MSG about s,f etc were executed, while a following routine making a G2 circle was skipped. So the subroutines are identified as source of the problem- The behaviour with the machine and sim is similar. At the moment i can use the filter, if necessary, and avoid subroutines if possible.

Did some more testing, only simulation.
I think its queue buster producing this problem. M66 E0 L0
M66 E0 L0 on top of a subroutine - no problem
M66 E0 L0 after some calculations with variables - no problem
M66 E0 L0 after WHILE ENDWHILE - subroutine is executed
after continues from selected line
What mix and order of Gcode and M66 E0 L0 exactly makes this problem needs more testing,
maybe some gcode also works as queue buster. But i am running out of time now.

I had some time in the workshop today, testing on the machine. Testing run from line.
Behaviour is as the simulation, most subroutines as described before are executed before jumping to startline, which is pretty bad. Having a long drill clamped, but the subroutine is supposed to do some engraving...
(DEBUG, RPM: #<_rpm>) is showing a value, M3 is there, but motion.spindle-at-speed is 0, and the machine is moving without rpm. Helpless how to make all that bulletproof, i am going to use my workaround at the moment. Just in case someone can discover spindle misconfiguration in hal. I had to use timedelay for the spindle to speed up. G4 P4 made a mess, hard to escape, if pause button was pressed during dwell.
Thanks for help so far.

did you set the defaulte in DISPLAY section INI file
DEFAULT_SPINDLE_SPEED = 1000 - The default spindle RPM when the spindle is started in manual mode. if this setting is not present, this defaults to 1 RPM for AXIS and 300 RPM for gmoccapy.

ini entry DEFAULT_SPINDLE_SPEED = 6000 is there for the ac spindle.
and hal with lincurve works perfect, any rpm lower than 6000 set to 6000 rpm, if I run program.
This problem beside a few more problems exist only when run from line, otherwise everything is fine.