JipeB
commented
2 years ago Apparently it is a tool length measurement procedure. (TLO) 1st question: Why use a G43.1 Z0 to cancel the TLO when G49 is implemented by GRBL?
2nd question: why repeat it 3 times?
G38.2 Z-50 F50 G1 Z0.5 F20 G38.2 Z-20 F4 G1 Z0.5 F20 G38.2 Z-20 F5
Same remark for the second section, maybe bCNC does not know where it is after 3 consecutive G38.2. Calling function G43.1 Zxxx causes an error because it has no usable value to store.
Furthermore, this function can only be used on a machine whose measurement origins and calibration procedure are operational. Testing bCNC with an inconsistent piece of code is not the best approach.
itchytweed
I am currently running the latest release of grblHAL on a BTT SKR-PRO STM32 control board. grblHAL has managed to start implementing 3.3.2.2 - Parameter Value, 3.3.2.3 - Expressions & Binary Operations, 3.3.2.4 - Unary Operation Value, and 3.3.3 - Parameter Setting from the RS274 NGC Interpreter Ver. 3 standard. This now allows grblHAL to do math onboard the processor card. If I run the sample code below through OpenbuildsControl, it implements properly. If I use bCNC, it chokes on lines 14, 33, and 34 when executing this nc file and spits out an error ( highlighted below in bold ). I believe this may be related to the inline python subsystem. Is there a way to turn off the python and c++ subsystems to pass the code through as written and not modify it?
Thank you in advance.
Sample code: ( THIS WORKS!!! ) (first section) G43.1 Z0 G53 G1 Z-10 F500 G53 G1 X-645 Y-795 F1000 G53 G1 Z-20 F500 G54 G91 G38.2 Z-50 F50 G1 Z0.5 F20 G38.2 Z-20 F4 G1 Z0.5 F20 G38.2 Z-20 F5 #110=[#5063/396] G91 G1 Z10 F200 G90 G53 G1 Z-10 F750 G54 G1 X0 Y0 Z0 F1500 (second section) G53 G1 Z-10 G53 G1 X-645 Y-795 F1000 G53 G1 Z-20 F500 M0 G91 G38.2 Z-50 F50 G4 P5 G1 Z0.5 F20 G38.2 Z-20 F6 G4 P5 G1 Z0.5 F20 G38.2 Z-20 F7 #111=[#5063/396] G43.1 Z[#111-#110] M0 G90 G53 G1 Z-10 F750 G54 G1 X0 Y0 Z10 F1500