Advanced Search

Regarding the error “Unknown M code used: M130”:

I followed the official LinuxCNC documentation/tutorial for configuring user M-codes.
The INI file was configured according to the manual, including the correct use of [RS274NGC] USER_M_PATH, and the M130 file is executable.

Despite this, LinuxCNC still reports:

file .INI
[EMC]
MACHINE = eng-eth
DEBUG = 0
VERSION = 1.1

[DISPLAY]
DISPLAY = axis
EDITOR = geany
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
ARCDIVISION = 64
GRIDS = 10mm 20mm 50mm 100mm 1in 2in 5in 10in
MAX_FEED_OVERRIDE = 1.2
MIN_SPINDLE_OVERRIDE = 0.5
MAX_SPINDLE_OVERRIDE = 1

DEFAULT_LINEAR_VELOCITY = 10.0
MIN_LINEAR_VELOCITY = 0
MAX_LINEAR_VELOCITY = 42.0

DEFAULT_ANGULAR_VELOCITY = 15.00
MIN_ANGULAR_VELOCITY = 0
VELOCIDADE_ANGULAR_MÁXIMA = 100.0

PREFIXO_DO_PROGRAMA = /home/cnc/Área de trabalho/
GRÁFICO_DE_INTRODUÇÃO = linuxcnc.gif
TEMPO_DE_INTRODUÇÃO = 5
INCREMENTOS = .1mm .05mm
PYVCP = Probe_panel.xml

[KINS]
JUNTAS = 3
CINEMÁTICA = trivkins coordenadas=XYZ


[FILTRO]
EXTENSÃO_DO_PROGRAMA = .txt,.png,.gif,.jpg Imagem de Profundidade em Tons de Cinza
EXTENSÃO_DO_PROGRAMA = .py Script Python
png = imagem-para-gcode
gif = imagem-para-gcode
jpg = imagem-para-gcode
py = python

[TAREFA]
TAREFA = milltask
TEMPO_DE_CICLO = 0.010

[RS274NGC]
#REMAP=M6 grupo_modal=6 ngc=sonda # (ATIVAR SONDA)
ARQUIVO_DE_PARÂMETROS = linuxcnc.var
FEATURES = 12
SUBROUTINE_PATH = macros
ON_ABORT_COMMAND = O <on_abort> call
FEATURES = 12
RETAIN_G43 = 0
INI_VARS = 1
HAL_PIN_VARS = 1


[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010
BASE_PERIOD = 0
SERVO_PERIOD = 600000



[HAL]
HALFILE = eng-eth.hal
HALUI = halui
TWOPASS = on
HALFILE = Probe_preload.hal
POSTGUI_HALFILE = Probe_postgui.hal

[HALUI]
MDI_COMMAND = G54
MDI_COMMAND = G55
MDI_COMMAND = G56
MDI_COMMAND = G57
MDI_COMMAND = G58
MDI_COMMAND = G59
MDI_COMMAND = G59.1
MDI_COMMAND = G59.2
MDI_COMMAND = G59.3

MDI_COMMAND = O <probe_toolchange> CALL [1]
MDI_COMMAND = O <probe_toolchange> CALL [2]
MDI_COMMAND = O <probe_toolchange> CALL [3]

MDI_COMMAND = O <probe_x_plus> CALL
MDI_COMMAND = O <probe_x_minus> CALL
MDI_COMMAND = O <probe_y_plus> CALL
MDI_COMMAND = O <probe_y_minus> CALL
MDI_COMMAND = O <probe_z_minus> CALL
MDI_COMMAND = O <probe_pocket> CALL
MDI_COMMAND = O <probe_operations> CALL [1]
MDI_COMMAND = O <probe_operations> CALL [2]
MDI_COMMAND = O <probe_operations> CALL [3]

MDI_COMMAND = O <probe_manual_set> CALL [0]
MDI_COMMAND = O <probe_manual_set> CALL [1]
MDI_COMMAND = O <probe_manual_set> CALL [2]
MDI_COMMAND = O <probe_manual_set> CALL [3]
MDI_COMMAND = O <probe_escape> CALL

MDI_COMMAND = O <probe_calibration> CALL

[TRAJ]
COORDINATES = XYZ
LINEAR_UNITS = mm
ANGULAR_UNITS = degree
CYCLE_TIME = 0.010
DEFAULT_LINEAR_VELOCITY = 42.0
VELOCIDADE_LINEAR_MÁXIMA = 42,0

[EMCIO]
EMCIO = io
TEMPO_DE_CICLO = 0,100
TABELA_DE_FERRAMENTAS = tool.tbl

#*** EIXO_X *******************************
[EIXO_X]
LIMITE_MÍNIMO = -5000
LIMITE_MÁXIMO = 5000

VELOCIDADE_MÁXIMA = 42,0
ACELERAÇÃO_MÁXIMA = 350,0


[JUNTA_0]
TIPO = LINEAR
HOME = 0

VELOCIDADE_MÁXIMA = 42
ACELERAÇÃO_MÁXIMA = 350,0
ACELERAÇÃO_MÁXIMA_MÁXIMA = 5000

LIMITE_MÍNIMO = -5000
LIMITE_MÁXIMO = 5000
ESCALA = 400
ERRO_FERROR = 1,0
ERRO_FERROR_MÍNIMO = 0,25
DESLOCAMENTO_HOME = 0,0

VELOCIDADE_DE_BUSCA_HOME = 0
VELOCIDADE_DE_TRAVA_HOME = 0
HOME_SEQUENCE = 1

DEADBAND = 0.002
P = 220
I = 0
D = 0
FF0 = 0
FF1 = 1
FF2 = 0
BIAS = 0
PGAIN = 220
PID_MAXOUTPUT = 250

#*** EIXO Y *******************************
[AXIS_Y]
MIN_LIMIT = -5000
MAX_LIMIT = 5000

MAX_VELOCITY = 42.0
MAX_ACCELERATION = 350.0


[JOINT_1]
TYPE = LINEAR
HOME = 0.0

MAX_VELOCITY = 42
MAX_ACCELERATION = 350.0
MAX_MAXACCEL = 5000

MIN_LIMIT = -5000
MAX_LIMIT = 5000
SCALE = 400
FERROR = 1.0
MIN_FERROR = 0.25
HOME_OFFSET = 0.0


HOME_SEARCH_VEL = 0
HOME_LATCH_VEL = 0
HOME_SEQUENCE = 2


DEADBAND = 0.002
P = 220
I = 0
D = 0
FF0 = 0
FF1 = 1
FF2 = 0
BIAS = 0
PGAIN = 220
PID_MAXOUTPUT = 250


#*** EIXO Z *******************************
[AXIS_Z]
MIN_LIMIT = -5000
MAX_LIMIT = 5000

MAX_VELOCITY = 15
MAX_ACCELERATION = 150.0

[JOINT_2]
TYPE = LINEAR
HOME = 0.0


MAX_VELOCITY = 15
ACELERAÇÃO_MÁXIMA = 150,0
ACELERAÇÃO_MÁXIMA_MÁXIMA = 5000

LIMITE_MÍNIMO = -5000
LIMITE_MÁXIMO = 5000 ESCALA
=
820,512
ERRO_FERROR = 1,0 ERRO_FERROR_MÍNIMO
= 0,25
DESLOCAMENTO_HOME
= 0,0 VELOCIDADE_DE_BUSCA_HOME = 0 VELOCIDADE_DE_TRAVAMENTO_HOME = 0 SEQUÊNCIA_HOME
= 0
BANDA MORTA = 0,002
P = 220
I = 0
D = 0
FF0 = 0
FF1 = 1
FF2 = 0
BIAS = 0
PGAIN = 220
PID_SAÍDA_MÁXIMA = 250
[SONDA]
# Defina até três números de ferramentas de sondas diferentes em sua tabela de ferramentas. Defina os números não utilizados como zero.
TOOL_NUMBER_1 = 99
TOOL_NUMBER_2 = 0
TOOL_NUMBER_3 = 0
# Curso máximo de segurança da sua sonda nas direções X/Y. O valor é fornecido pelo fabricante. Em caso de dúvida, defina para ~3 mm.
MAX_XY_DISTANCE = 3
# Distância que a sonda percorrerá após uma sondagem rápida. Valores recomendados entre 0,5 e 2 mm.
XY_CLEARANCE = 0,5
# Curso máximo de segurança da sua sonda na direção Z. O valor é fornecido pelo fabricante. Em caso de dúvida, defina para ~2 mm.
MAX_Z_DISTANCE = 2
# Distância que a sonda percorrerá após uma sondagem rápida. Valores recomendados entre 0,5 e 2 mm.
Z_CLEARANCE = 0,5
# Velocidade da sondagem rápida. Valores recomendados entre 50 e 500 mm por minuto.
# Observação: Todos os valores de velocidade definidos serão verificados. Os valores considerados são: ACELERAÇÃO_MÁXIMA (x, y e z), TEMPO_DE_DEBOUNCE e DISTÂNCIA_MÁXIMA_XY/Z.
VEL_RÁPIDA = 200
# Velocidade lenta da sonda. Este valor é importante para a precisão geral. Valores recomendados entre 10 e 50 mm por minuto.
VEL_LENTA = 20
# Velocidade rápida de avanço entre os movimentos da sonda de bolso sem sondagem real.
VEL_RÁPIDA = 2000
# Acionamentos adicionais da sonda levarão a uma melhor calibração. Valores entre 0 e 3 são recomendados.
ADICIONAR_ACIONAMENTOS_DA_SONDA = 2
# Atraso de tempo em ms para o debounce do interruptor da sonda. Tente manter o valor o mais baixo possível. Valores recomendados entre 2 e 20 ms.
TEMPO_DE_DEBOUNCE = 10
# Configure o interruptor da sua ferramenta de sonda. 0 = NA (normalmente aberto), 1 = NF (normalmente fechado)
# Observação: O LED de sinal da sonda deve mudar de verde para vermelho quando você tocar a ponta da sonda.
INTERRUPTOR_DA_SONDA = 0

Had the same issue, double check your wiring of the orange block. If it's wrong it won't power up and you'll get the issue your are seeing.

Gentelmen, I am not an expert of C hard code for this big performance irons... I have coding just embedded stuff (day of 8bits stuff) and from this I am little bit bended to optimsing everything over readable coding ... because of lack everything 

therefore it was just my opinion ... I am open to learn new stuff and let my habits behind 

Luca do you think about the look ahead position control? PositionCommand(t+1) as I said before please? For run the ethernet and ethercat servo packs in CSP control? This will change the lagging and cycle ferror during movement...

I have coded my own component which is solving it by it is not accurate during the accellerations change ... 

Sorry, just for info: the encoder is a separately mounted encoder just for thread cutting, so it has not really to do with the spindle control itsself, though would be nice if positioning the spindle would be possible later on...

rodw wrote:

I don't think it makes sense to manually optimise for execution speed in this day and age. Instead use GCC compiler options -03 or -0fast and possibly native optimisations march=native and possibly mtune=native. This may increase code size and possibly memory usage but I don't see that current hardware has constraints in this area. Gone are the days of massaging code to save every byte to fit in a 64k terminal! I did find using the C ternary operator was more efficient than if-else during that exercise.
 

I disagree. Compilers can do great things, but writing code with performance in mind can make a HUGE difference. I haven't looked at this code to know if there's low-hanging fruit here or not. As an illustrative example, I recently got the PeanutGB emulator running on an nRF54L microcontroller. Various low-hanging-fruit optimizations (pulling branches out of loops, handling 16-bit numbers natively instead of as 2x 8 bit integers, etc.) brought that from running at not even full speed to running at 130~150% speed.

There's certainly an argument for writing readable code over the most optimized- the above changes varied from neutral in readability to highly detrimental to readability.

Any loops are a good place to start looking at optimization- pulling out any branches, unrolling them, and/or reducing calculations that are done in the loop. Basically Amdahl's Law- look at optimizing the parts of the code that take the most execution time.

first of testing was 3dchips.ngc and second the 1001.ngc When I removed the base thread ... most of spiking was gone but last spiking ( less then 300us peaks - core duo, less then 200us peaks - i5 C6930-0060, 80us peaks - i7 ) are present during the in the clouds ... but it is more then perfect and extremly usable for everybodyit amazing job for sure !!!

All the answers to your questions are in the manual:
linuxcnc.org/docs/2.9/html/config/ini-co...sub:ini:sec:rs274ngc

SUBROUTINE_PATH = ncsubroutines:/tmp/testsubs:lathesubs:millsubs - Specifies a colon ( separated list of up to 10 directories to be searched when single-file subroutines are specified in G-code. These directories are searched after searching [DISPLAY]PROGRAM_PREFIX (if it is specified) and before searching [WIZARD]WIZARD_ROOT (if specified). The paths are searched in the order that they are listed. The first matching subroutine file found in the search is used. Directories are specified relative to the current directory for the INI file or as absolute paths. The list must contain no intervening whitespace.

USER_M_PATH = myfuncs:/tmp/mcodes:experimentalmcodes - Specifies a list of colon ( separated directories for user defined functions. Directories are specified relative to the current directory for the INI file or as absolute paths. The list must contain no intervening whitespace.

A search is made for each possible user defined function, typically (M100-M199). The search order is:

1) [DISPLAY]PROGRAM_PREFIX (if specified)

2) If [DISPLAY]PROGRAM_PREFIX is not specified, search the default location: nc_files

3) Then search each directory in the list [RS274NGC]USER_M_PATH.

The first executable M1xx found in the search is used for each M1xx.

I looked at some optimization routes today, nothing sticks, as rodw said modern compiler do already an excellent job. /2 or *.5 does not matter, the compiler does not actually call the division in assembly, /2 stays for code readability. please first give me a code that I can run, that spikes with our scurve, and does not spike with trapez acc. And then we could seriously look at what operations that we introduced might be spiking the servo-thread, and see if optimization is viable/necessary.

I hope someone can provide help for me. I try to go step by step slowly and still are trying to get my spindle encoder to work. I can see it counting in HAL-show, but it does not really work together with my spindle. I assume I missed some linking in my HAL.I attached current HAL and INI attached and a file TXT file called HAL with DOKU where I documented the physical connections to the MESA cards, probably this helps...

Would be great if someone could help me to integrate this encoder.
Thanks
Sigi

Thank you Rod.. I think it will help everybody with low latency and ethercat jitter...

What i can tell from my observation... If anybody using CSP driver over ethercat.. position is sending but there is everytime single cycle lag because of no feed forward observer FF1 like during compensation in the PID overc command velocity ...
There will be best if the planner will have allready positionCommand(t) and positionCommand(t+1) for direct position control setup .. this will directly avoid lagging just for this purpose .. do you think about it?

In axis the preview is always there. But axis doesn't update the preview, once gcode is loaded. Typical example in axis, probing or shifting offsets during runtime. This leads to a misplaced trace compared to the originally loaded preview, which persists.
Flexgui does update the plot, if i shift offsets, G10... updates the view.
What i tested, G38, M66 and even my toolchange routine, block the preview until none of the mentioned before is in the further gcode, and then preview comes back.
 

“I couldn’t find a solution to this issue, and I haven’t received any feedback so far, so I’ve decided to move on from LinuxCNC.”

Do you get the same results using Axis? I ask that because Flex GUI uses the same plotter as Axis.

JT

I don't think it makes sense to manually optimise for execution speed in this day and age. Instead use GCC compiler options -03 or -0fast and possibly native optimisations march=native and possibly mtune=native. This may increase code size and possibly memory usage but I don't see that current hardware has constraints in this area. Gone are the days of massaging code to save every byte to fit in a 64k terminal! I did find using the C ternary operator was more efficient than if-else during that exercise.

I had a brief look at the code and it seemed to be well written and efficient.

In some benchmarking I did some time ago on an i5 with bookworm, the 1ms (1000 ns) servo thread executed in about 200 ns and slept for 800 ns so I don't think you will have issues if the s curve code increases execution time.

Of course it goes without saying the PREMPT_RT kernel needs tuning and that's been hard to articulate even after hours of study. My best effort covered in my recent video which has got jitter down to 6 ns according to one viewer. 


@endian, there is a recent PR from grandixximo on the Ethercat hal driver to sync the servo thread to the Ethercat loop which may help you if committed. github.com/linuxcnc-ethercat/linuxcnc-ethercat/pull/465
 
 

Thanks for the suggestions it gave me an idea! It took all replies to formulate it.

 If I create a base for my tool setter that has a riser. The riser can be any size as long as its lower than the trip point of the setter. This will allow me to remove both known points in space to resurface. Then when I re-install it the 2 known points in space are still referenced to each other.

 Then I calculate the offset from the tool setter trip to the riser top. Now that the offset is known I can adjust the tool change script to detect tool 99, change the X/Y location of the touch point and adjust the offset by the riser/setter offset. This should put the tool length offset routines at the same point as the 3D touch probe creating a calculated common known point in space for both.

 Now job start is similar to before. Manual load tool 99 (3D Touch) or tool 98 (6mm pin). If I load tool 98 setup is as its always been before the 3D touch. If I load tool 99 I get the added features of the 3D touch. Job start should pickup a tool change, use the tool setter and operate normally with either tool 99 or 98 start.

 Whooa! On the Amazon website the probe looked so easy!