Traverse around bounding box option about bcnc

[HomineLudens]

This could be merged with issue #28. To have some customizable user buttons with free gcode or mdi/ commands. This could be edit in settings file to avoid overhead in developing the gui.

[1bigpig]

@effer @vlachoudis
If you are thinking of adding a macro button, I would like to add some type of logic/scripting to the macro buttons.

With the above example, the macro would need to know Xmax, Ymax, and Xmin Ymin and probably Zsafe as well.

I would also like to add an auto centering macro. If you have ever used Mach3, it is one of its coolest features (to me anyways). I use a 25mm diameter copper ring (cut off water pipe) that is attached to a plate that is connected to one side of the probe input. The tool bit them moves in the X+ until it touches the copper ring and records that position. The tool then moves in the negative X axis direction -25mm until it touches the other side of the copper ring. Now, the script subtracts XposTouch from XminusTouch ((Xmax-Xmin/2) +Xmin) and then moves to the middle. Then it does this for the Y axis. When finished, the tool is in the middle of the copper ring. On my plate, I have cross hairs engraved in and 3 locating pins to line it up with a corner. I find it pretty useful when setting up expensive materials and when you have to locate a part that has been taken off the machine, but requires more machining/cutting.

The script would look something like this:

ring = 25
G91
G38.2 X+[ring] F25
Xmax = [probe return value for X]
G38.2 X-[ring] F25
Xmin = [probe return value for X]
Xcen = (Xmax-Xmin) /2
G0 X[Xcen]
G38.2 Y+[ring] F25
Ymax = [probe return value for Y]
G38.2 Y-[ring] F25
Ymin = [probe return value for Y]
Ycen = (Ymax-Ymin) /2
G0 Y[Ycen]
G0 Zsafe
G90
G20 L10 X0.0 Y0.0

Bruce

[vlachoudis]

@1bigpig that's a nice idea. I could possibly add function evaluation in the gcode, and a variable scope containing user defined and system variables. In python is pretty easy it needs some parsing. I saw that linuxcnc had some function evaluation I don't know if their format is a gcode standard which in this case would be nice to follow.

[HomineLudens]

That's interesting @1bigpig. One clear limit of grbl it's the low memory that doesn't allow parameterized programming and variables inside part program.
Linuxcnc can evaluate formula and store value in variables (different producer use their own dialect), but grbl will not.
If I well understand the @vlachoudis idea, the bottleneck of maintain this data in bCNC side, will be the fact that streaming will be blocked at reaching of every line containing a variable till fully flush. It will not be safe send more lines contains data that could be modified. This will not allow to grbl to plan a good acceleration management. It will work start and stop continuously.
That's the bad side of the medal in my point of view.
From the other side it will improve the flexibility and customization of way of work of the users.
In my little experience there are not so many gCode guru out there, most of the people prefer to let the dirty work to a CAM software.
Lack of good free CAM solution could help anyway.

[chamnit]

@vlachoudis : This is something I could help with. The g-code standard has a programming language they call Macro B, originally by Fanuc. It's parameterized language with variables that can calculate adjustment or alter g-code programs based on these calculations. For example, you can automate tool changes, canned cycles, auto-leveling probing cycles, find the center of a workpiece, engraving set letters, facing stock, etc,etc. It's relatively simple, yet powerful, and accepted by industry. If we install this, this could be way for bCNC to internally write and manage all of these custom processes, and allow users to add or change them as needed.

Since I've already spent a ton of time writing and re-writing Grbl g-code parser, I've got a pretty intimate knowledge of the canon. I've already got a start with grbl parser written in Python (PreGrbl but not touched for 3 years). I can update PreGrbl to the current Grbl parser and start to add a Macro B API for bCNC to use. I imagine this would spit out g-code that it compatible with Grbl. bCNC would have to manage the stream and order of operations.

[chamnit]

@vlachoudis : After some thought last night, I don't think I have time to get something like this done at the moment, but there is previous g-code canon project by @csdexter, written in C. It's pretty complete, as far the canon goes, but will likely need some work to make it an API for bCNC to use. It does have expressions (similar to Fanuc MacroB) so it'd be possible to create custom tool paths or machine control functions with these.

[1bigpig]

@vlachoudis @chamnit I think everybody may be over thinking this. I don't think we need a whole macro/subroutine feature in addition to grbl streamer. I was thinking just as a macro feature. Not 100% sure of this, but programs like Mach3 only allow scripting in macro "buttons" on the interface. I could be wrong, as it has been a long time since I did a custom Mach3 screen, but I am pretty sure the scripts were part of the custom screen and were not executed by the general G-code interpreter.

I would have suggested Mach3's scripting language as basis, but they were using a form of Basic (maybe Visual Basic?). I know that EMC/LinuxCNC was usually a few iterations behind Mach3, for the simple face that Mr. Fenerty was being paid to program Mach3.

I would also offer that the macro language does not have to be as complicated. grbl only has 8 inputs MAXIMUM. 3 of those are limits, 1 is a probe, 1 E-stop, 1 door/run-hold line and 2 misc inputs that are currently not defined. Mach3 had practically unlimited input/output lines but I think he limited it to 1000 lines of I/O. With that many lines, you can do some pretty crazy stuff such as automatic tool changes completely under control of Mach3.

While you have more I/O options for Raspberry PI boards (and the like) you start limiting bCNC to which computers it can run on. I don't think @vlachoudis even has a Rasberry PI.

So, what I am sorta proposing is this:

• Limit scripting to Macros--if that is possible
  If that is not possible, embed the logic in some type of G-code comment--I recommend the ;< variable = X>
• All variables that are in actual G-code lines require [] to be recognized.
• Any variable that has not been predefined would cause an undefined G-code error.

So the above centering code would look like this:

;< ring = 25>
;< Xmax = 0>
;< Xcen = 0>
;< Xmin = 0>
;< Ymax = 0>
;< Ycen = 0>
;< Ymin = 0>
G91
G38.2 X+[ring] F25
;< Xmax = [probe return value for X]> <---There would have to be some machine constants
G38.2 X-[ring] F25
;< Xmin = [probe return value for X]>
;< Xcen = (Xmax-Xmin) /2>
G0 X[Xcen]
G38.2 Y+[ring] F25
;< Ymax = [probe return value for Y]>
G38.2 Y-[ring] F25
;< Ymin = [probe return value for Y]>
;< Ycen = (Ymax-Ymin) /2>
G0 Y[Ycen]
G0 Z[Zsafe] <--- Zsafe would be another machine constant
G90
G20 L10 X0.0 Y0.0

Bruce

[1bigpig]

opps. Looks like Github also implements the "greater than" sign in their comments, so I had to add a space between the greater than sign and the variable. This space would not be in the code.

I think that all machine states reported by $G should include machine constants. I would also like to include toolpath min/max for all 3 axis. The probe return values should also be included. I will try to work up a list tonight.

Bruce

[chamnit]

@1bigpig : What you are describing is Macro B, aka expressions, aka variables, etc. Mach3 has their own macro language, if I remember right. But most are based off MacroB. Since it's industry standard, professionals can apply their techniques easily into a GUI that support it.

[1bigpig]

@chamnit Guess I better read up on Macro B.

[vlachoudis]

@effer normally almost all of the code has to be evaluated before sending. So I believe I have to flush all the evaluated lines, and stop&wait once I have a probe line. Maybe @chamnit can highlight us which other commands could return something that might needs to alter the following gcode.

[chamnit]

@vlachoudis : With macros/subprograms, I believe just about everything can be returned and used to calculate the next part of the subprogram. But, @effer is right about the starting and stopping problem. In a subprogram, you may need to wait on the particular data that you need before continuing, like the probe command. However, this will be the same problem regardless if Grbl has to do it internally or bCNC, as GUI, has to do it externally. Off the top of my head, there isn't much other than probing that requires a wait until completed. Subprograms were originally created to handle automated probing tasks, tool offset cycles, and canned cycles. The latter is usually generated with prescribed inputs, rather than during a cycle like probing.

If a GUI needs to ensure Grbl's buffers are empty, it can simply send a G4 P0.001 dwell. It'll queue into Grbl and force it to empty its buffers before executing the dwell. When it returns an 'ok', the GUI can immediately resume the stream. The delay will be on the order of the serial communication and GUI processing lag. Pretty short.

[vlachoudis]

@chamnit I gave a look on the Macro B. It has even simple scripting logic IF GOTO WHILE... and some functions like BCD. As a first step I will introduce the function evaluation and leave the scripting logic for the moment. Does anyone really use them?
Also is there some standard variables to hold the probing result. I didn't find out.

[chamnit]

@vlachoudis : I'm reviewing a couple of books a machinist friend gave me this weekend on Macro B and other variants. Mach3 and LinuxCNC has their own variants that they call subprograms. I'm also looking into that g-code canon project I mentioned earlier and reviewing what type of macro variant they use. AFAIK, it has all of the scripting logic and parameter setting there.

And yes, people use them. Mostly professionals or people who are more experienced machinists. These are often used to automate custom probing cycles like scanning a 3d surface to generate an STL model or custom tool changes for a particular machine. The latter is the most important part of it IMO.

I think there are usually a set of parameters that stores the probing result that you can access from machine memory. On LinuxCNC, these are parameters 5061-5069.

[chamnit]

@vlachoudis : I was also debating whether or not using the LinuxCNC macros (called subprograms) over the industry standard Fanuc Macro B. Since Grbl uses LinuxCNC's g-code definitions, it might be a good idea to keep it consistent. During my review, I'll be investigating the differences between them and determining if there is a good reason to choose one over the other.

[HomineLudens]

I've used LinuxCNC macro for some test, and for generate some parametric program. So, little experience but I found it a bit rusty.
I was ponder if using python as scripting language could be possible? Clearly not a standard but a more modern choice and maybe a more easy implementation?

[chamnit]

@vlachoudis : So I have done an initial review of different macro dialects. Macro B is great and powerful, but there aren't too many free tools that utilize it. It's mostly in the professional domain. If I were to choose, I'd probably stick with LinuxCNC's expressions, parameters, and subroutines (their version of macros). This keeps things consistent with Grbl. It's also just about as powerful as Macro B and can plug-in to existing LinuxCNC tools.

For example, there is an interesting project that creates a higher-level abstraction, called gcmc, which seems really useful as a way to write a human-readable script. Gcmc won't completely replace macros, because it only generates g-code and can't handle probing appropriately. You'd still have to use macros for that.

[vlachoudis]

Thanks @chamnit for the info. I would start as a first step the function evaluation/substitution to perform simple tasks as @1bigpig mentioned. The macros, functions, logic I will leave it for later. Personally I am more in favour of what @effer was proposing, when ever I want to do something parametric I prefer to use python or rexx.

[chamnit]

@vlachoudis Understood. I've been looking at how much effort it would take to program something like this. Turns out to be quite a bit. It's also tricky when dealing with the communications with Grbl. Perhaps it would be best to do your own thing with Python, while keeping in mind the general workings of macros. In the near future, I'm hoping to get a complete gcode API. It'll be quite an effort but hopefully useful as things become more powerful

[1bigpig]

@vlachoudis @chamnit Sorry I am late returning to this thread. Work has been crazy.

Anyways, I took a quick look at MacroB but it reminded me of too much "old school" CNC. While I appreciate the desire to be compatible with other systems, I feel that in this case, that might "limit" the future potential of bCNC. Who knows what cool feature or macro someone might come up with? I personally would not have though of the circle center finder, but I would like to thank whoever wrote that in Mach3!

Also, I feel that bCNC should not be another "me too" project". I think @vlachoudis has some unique and cool features that a lot of other programs don't. I feel that a macro language in Python might be another feature that no other grbl interface program has and would put bCNC on top of the grbl "heap"!

Just my two cents.
Bruce

PS I promised a list of constants for the macro language. Will work on that today/tonight.

[chamnit]

@1bigpig : I think this is the same conclusion we came upon. I'll be adding macros to the next version of Grbl. But, I think it'll be a good idea to base some of the machine programming concepts of macros to bCNC's subprograms, since its a complete methodology to do so.

[vlachoudis]

@chamnit @1bigpig I've made a very simple function evaluation (outside bCNC) using square brackets [] as well # prefixed variables and normal ones. It functions well and its quite fast. However what is binding my hands is the use of parenthesis for comments. It destroys any possibility to have something compatible with g-code and get the flexibility of a high level language. I need a clever solution for that.

For the moment I see the following possibility:
Stick with the g-code standard using the square brackets [], # prefixed variables, and custom free identifiers for function evaluation only. Probably implementing the bare minimum that the majority of users/programs will use and some additional parameters. This can be easily integrated I only need to flush the evaluated lines till the G38 probe and wait grbl to return to continue flushing.
While having a higher layer like gcmc to generate more sophisticated gcode.

I wonder how many users/programs do write parametric gcode or it is better to create a parametric CAD converted to gcode?

If the use of having parametric gcode generator is to make macros like the @1bigpig center finding ring, maybe I could introduce a macro mechanism outside the gcode standard for user defined actions.

[chamnit]

I'm not quite following what exactly is the issue with the comments, but there is also the ; semi-colon comment style that comments everything after it. However, it's not universally supported. Grbl and LinuxCNC do though.

The use of parametric gcode depends on the type of user. If you're talking about the hobbyist CNC user that is common to Grbl, probably a very small percentage because they are not aware of it. If they are LinuxCNC/Mach3 users or professionals, I would say a good portion of them will know how to use them and implement them for repetitive tasks. If something like this is available, I think more people will learn to use it, especially if users are trying to make a little side income with their machines, because it saves time at the machine. Macros are most useful generating gcode programs realtime.

For example, when milling metal, one of the first things you do is square up the stock material and you often don't know exactly how much to face until the material is in the machine. The facing operation usually involves some simple fly cutter sweeps or a set of end mill serpentine passes. This can be all automated with a parametric program while you are at the machine. Input the variables for general dimensions, step over, and depth, and you have a gcode program automatically. It's much much faster than going back to your main computer, updating it in CAM, and then loading up the program into the GUI to run.

By converting a program to CAD and then use CAM to generate the gcode, you have much less control of the gcode program itself. The results can vary from CAM to CAM program and you have that added step of importing it and generating the gcode. At this point, you pretty much lose the advantages of what macros give you: realtime g-code generation for repetitive tasks at the machine.

[1bigpig]

@vlachoudis I proposed that we limit the scripting to macros only.

I think that 99.9% of the user will use CAD/CAM to generate their G-code. The macros would be for things like the two functions I mentioned above.

You could also do things like bolt circle calculators and a few other functions they call "conversational" programming, but those things could also be done in straight Python which then generates G-code.

Make it easy on yourself. I am sure that as things progress, I will definitely suggest improvements and fixes... ;-)

Bruce

[chamnit]

@vlachoudis : I agree with @1bigpig. Don't over-complicate it and write a simple implementation in Python that will get most of the job done. Python is high-level enough to re-write later, when I can get macros installed. Can't say when, but it's on the todo list.

[csdexter]

Adding one more datapoint to the discussion: LinuxCNC has a collection of Python scripts that use Tcl/Tk to display a GUI and allow the user to make choices and then output the generated G-Code. Knowing that LinuxCNC is extendable in software at many levels, I'm speculating that most if not all those scripts can be plugged directly into Axis (LinuxCNC's GUI) so that you can access the desired functionality without ever leaving the main CNC screen. Maybe this example will help.

They are here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-Code_Generators

[HomineLudens]

I'd like to see bCNC supporting also a powerful macro/script language in a future, but I believe that an aspect that will be more widely appreciated will be the Tools.
This feature is already sketched, for example with the Cut or Profile command that allow to generate GCode like in a simple CAM software.
@chamnit highlights nobody wants to move from CAM to machine and viceversa, but in bCNC you already have both at your hand.
What @1bigpig showed us at begining of the post, it's a usefull routine but maybe is faster to add that special script as tools, than implementing a full macro language.
If Tools will have a common interface will be easy to see more and more usefull feature added to bCNC by contributors (pocketing, gears generator, and more).
Also @csdexter points at a collection of small python scripts that make easier the life of cnc operators, and all already written in python, so relatively easy to import.
That's my thought and I'm curios to see how @vlachoudis will evolve this great piece of software.

[vlachoudis]

I was thinking exactly the same thing with @effer. Apart from the function evaluation to provide a plug-in mechanism for the "Tools" section so anybody could write his own plugin to create or alter the gcode.

[1bigpig]

I went ahead and posted the list of reserved words for the macro language as a new issue. Please feel free to add to the list and make suggestions.
#60

Better late than never.
Bruce

[onekk]

Having using bCNC for some time with my new CNC and being a novice, a scripting language wold be very useful, a method to write a script and load into bCNC and then GRBL execute the moves like.

I have found this piece of code and i used it for drilling the slots for the screw in the spoilboard of my machine.
It is in a rough state but it is in python and have only one file cnc.py to import.
just my two cents.

Regards

Carlo D.

[vlachoudis]

@1bigpig @effer I've made a branch called "eval" with the first version of function evaluation.
It accepts
variable = expression ; any python expression, () and [], triggered by the equal
feed=10_25.4_sin(1.0)
matrix=[1,2,3,4]
xpos=matrix[1]
#12 = 25.4 ; #nnn while be stored as _nnn variable internally

%python-statement ; any python statement starting with % but in one line
%for i in range(10): xpos += i

On normal commands the [] triggers the evaluation of the expression (to a float only)
g1 x[xpos+1] y[#12](z2.0 this is a comment)

There is a variable stdexpr = False in the CNC.py controlling whether it would convert the [] to ()
sin[1] -> sin(1) or keep them literaly as [] for list/matrix operations

For the moment the commands are pushed in the stack of execution and it will not wait the return of a probe. I have to create a special command e.g. flush, wait, to wait until the buffer is empty and get the return string like after the probe

Only the plotting and execution are supported for the moment. All other operations, move, rotate, mirror, profile,.... are treated the old way.

Evaluation can be used also in the command line
echo [xmin]
msg [xmin+ymin]
cut [zmin]

For example the traverse around a bound, you can configure one user button as
zsafe = 3.0 ; for the moment is not stored in the dictionary it will be in a while
g0 z[zsafe]
g0 x[xmin] y[ymin]
g0 x[xmax]
g0 y[ymax]
g0 x[xmin]
g0 y[ymin]

To make my life easier I used only the variable names as they were inside the code, but this is temporary.

Please check and report any problems.
V.

[HomineLudens]

First of all, it's amazing!
Then:

• IMO the square brackets are unclear when using matrix, it took me a while to get the meaning.
  points=[0,10,20,30]
  G1 X[points[2]]
  What about using some other markdown for variable inside Gcode, for example:
  G1 X_points[2]_
  (or other symbols like '$' ,'<' ,'>', )
• Could %python-statement contains gCode reference? i.e.:
  %for i in range(4): G1 X[points[i]]
  and will be possible to write more lines, maybe all preceded by %?
• It's seems like the lines after a %python-statement doesn't report a correct highlight in the main canvas when selected.

This is a really huge improvement in the code and I'm impressed on how fast @vlachoudis implements it.

[vlachoudis]

@effer I used the brackets [] and the hash # just to be a bit compatible with the linuxcnc. Even though I saw that linuxcnc accepts variables as #nnn, # or #<_name-global>. However I didn't like the use of brackets in the place of parenthesis as linuxcnc e.g. X[sin[10]]
You can enable it with the stdexpr flag in the CNC.py

The idea is what in whatever gcode line the [expr] pattern is replaced by the result of the expr. Internally the brackets behave as in python. I don't like adding extra symbols it will become confusing.

I didn't like also to use the %-prefix letting the code to decide from the content, but it didn't work out nicely.

For the moment you cannot have gcode inside the python-line and neither multiple lines as a single statement. I would like to do it but I don't have a clear solution for the first. The problem is that I have to stop the python execution and queue the generated gcode lines. Moreover it would require a complete parser, which creates the python code.

Thinking while writing, one option would be a specialized python function g(code) which accepts a code-string and breaks the execution with the yield statement (maybe is not possible from the eval()), or simply append all gcodes in a list and return the list to be executed one by one...

The highlight I have to check once I am back at home.

[HomineLudens]

@vlachoudis I don't like the use of brackets in the place of parenthesis too. But the confusion come when in your expr come the need to use an array and maybe also a function or even worst a complex function with more parenthesis. I believe this could become a hell to understand. For that reason I suggested other symbols. It will be more easy to choose when other characteristics will be more clear.

I had a fast look to the code and now is a bit more clear the "gcode inside the python-line" issue. Neither a print command is routed to the stack. May be a special function could work.
But in general the need is to manipulate the coordinates (and feeds) with macro. So could be a solution also a special grbl object where python can manipulate the coordinates and use it to print a gcode line.
something like:

for x in range(10):
   grbl.z+=10
   for y in range(10):
      grbl.x=x
      grbl.y=y
      grbl.line(100) #G1 X0 Y0 Z10 F100
      grbl.circle(1,1) #G2 I1 J1

Just a sketch, I need to think it better.

[1bigpig]

@vlachoudis Awesome job!!!

I have not had a lot of time to evalute--that comes soon, I hope--but so far, so good!!!

I did have to make a few changes to the variable assignment--probably my fault for lack of knowledge of Python... ie "zsafe = 3.0" needed a "%" sign but the echo command did not.

I was able to make my traverse the bounding box macro work. So here is the first button...

name.1 = Traverse Bounding Box
icon.1 =
tooltip.1 = Traverse bounding box
command.1 = %zsafe = 3.0
echo [zsafe]
g0 z[zsafe]
g0 x[xmin] y[ymin]
g0 x[xmax]
g0 y[ymax]
g0 x[xmin]
g0 y[ymin]

AWESOME and THANKS!!!
Bruce

[vlachoudis]

@effer I was thinking something similar with the gxxx functions, appending the commands in a list and at the end queue the list for execution. To have multiple lines purposely I need a starting and ending markers. Could be empty℅ lines marking both the start and the end.

@1bigpig the variable setting should work inside the G code file, but due to a bug is not working from the command line and from the user buttons. I will fix it.

[chamnit]

@vlachoudis : I've been out of town for work this week, but wow. Thanks Vasilis! This is a game changer for Grbl and everyone. I'm so happy to see bCNC progressing at light speed.

[HomineLudens]

@vlachoudis the scripting functionality is really a killer feature.
Python choice fits perfectly in bCNC and RPi.
For example while running in in raspberry pi it could be possibile insert some user script in the GCode to use the additional GPIO for manage Tool Change (as request somewhere else). So in some manner it should be implemented also the possibility to recall custom scripts (maybe saved on some special folder inside user directory).

On some aspect your implementation remind me of similar approach used in industrial automation where Part Program need to interact with automation logic (PLC or PC). Often in this situation it is used to implements a shared RAM to exchange information between the motion controller (grbl) and the plc (bCNC script in this case) in a bidirectional way. Here the shared RAM should be the gxxx function/object allowing gCode to use PC variables inside part program or viceversa script motions and synchronize them with GPIO. The possibilities are truly fascinating.

IMO the compatibility with LinuxCNC or Macro B language is a secondary addiction. If script will grow well, all other "function evaluation" could be removed without losing any capabilities. And python is far more readable then any Gcode script.

[vlachoudis]

@effer indeed, combined as well with user plugins (Tools) in python, it will make it a very powerful solution.

I found some time yesterday and I've implemented the "waiting" functionality after a probe command. You can issue it with a %wait line, which stops the streaming until the grbl buffer is emptied. (Maybe a %flush name would be more appropriate).

With this addition I could do the x-y probing as @1bigpig was suggesting, with the following code

diameter=40.0
feed=100
g91 g38.2 x[-diameter] f[feed]
%wait
low=prbx
g91 g38.2 x[diameter]
%wait
g53 g0 x[0.5*(low+prbx)]
g91 g38.2 y[-diameter]
%wait
low=prby
g91 g38.2 y[diameter]
%wait
g53 g0 y[0.5*(low+prby)]
g90

Right now, it can only be execute as a gcode program with the Run button. For the moment is not possible to have it as user configured button, due to the different queue that the commands are send from the buttons.

The User buttons sends the commands to the command/mdi line, while all the gcode commands are submitted to the streamer thread running in parallel, as a result all the operations are not in sync with the streamer thread.

I have to find a way to synchronize the two threads, however leaving as well the user interface free. I think I have a solution but it needs some work.

[onekk]

@vlachoudis well done, when it will be usable in bCNC, There some explanation about the use of the Tools (user plugins) in bCNC?

Even if i haven't figured out well how to use the G38.2 and the G43.1 command in grbl, if i'm not in error i could do like in the example:

height = 30
feed =10
g91 g38.2 z[-height] f[feed]
%wait
ref = prbz

here i have to put a "done" button that stop bCNC to send command and so i can change the tool in the spindle, when done the "script" continue with

g91 g38.2 z[-height] f[feed]
ntl = prbz

Here i have to calculate the offset (maybe wiith some ìf then like if ref > prbz: off = ref -prbz G43.1 off and so on)

but BCNC has to stop at a M6 command and let me issue the commands and then resume.

I know that it is better to have multiple gcode one for each tool and run them in the appropriate sequence, maybe if the "script" language permit to:

1. Load a gcode file
2. when done let the user:
   2a) execute the change tool
   2b) set the correct G43.1
3. load the "next" gcode file

repeat 2a) 2b) and 3) for every tool change

It could be a good susbstitute of the M6 command.

Thanks, for the patience and best regards.
Carlo D:

[vlachoudis]

@onekk Once I solve the sync problem, I will push it in the master branch.
The "Tools" section is lacking a bit in documentation :) (None for the moment).
I've just added a tutorial, how I made my MDF clamps and it explains a bit the Tools.

What you wrote is correct. The only thing is that if you put it in a user button, the last command ref=prbz will be executed before the g38.2. If you load it as a gcode program and run it it will execute correctly.
This is what I want to solve before push it in the master branch.

Next I want to have gcode commands pushed from the python code directly.

[onekk]

Sorry @vlachoudis i have not finished the code, i just hit the return button, i finish the code, I had a look at the wiki page about the clamps, very well done, but the images cut most of the screen, and pe in the 3rd and 4th image is not easy to figure out the right item selected in the combobox.
It's a very well done page, and make some light on some other aspects of BCNC.
Many thanks for bCNC again.

[vlachoudis]

I've pushed the function evaluation in the master branch.