Button macro: all python code execute before gcode!

[BernardG]

I am trying to probe a part to find its middle position. It looks like both my python code and my Gcode are fine. The only problem is that %wait seems to do nothing. I can see on the terminal my %print(s), even while Gcode has not yet probed the 1st position. So, obviously, my python variables cannot receive the proper values.

I understand that python execute locally, while Gcode is sent to GRBL. So I guess, my question is two fold: (1) Would there be a way to make it all python code? (2) Or, is there something to do to make %wait works, OR, any way to force python to wait an OK from GRBL before executing? (I guess that's what %wait is made for anyway...)

Here is my code so far:

%_long = app.entry("Entrez la longueur de la pièce: ");
%_larg = app.entry("Entrez la largeur de la pièce: ");
%_flong = float(_long);
%_flarg = float(_larg);
%_posXM = float();
%_posXP = float();
%_posXmi = float();
%_posYM = float();
%_posYP = float();
%_posYmi = float();
%_distmvt = float();
%_diffPos = float();
%msg Debut de Sondage
(==================X=================)
(on assume que Z0 à été fait auparavant)
G91 G0 Z3
%_distmvt = float(0.5 * _flong + 10.00);
%print("distance mouvement = " + str(_distmvt));
G91 G0 X-[str(_distmvt)] (On recule de la longueur /2 + 10 mm)
G91 G0 Z-8 (On descend rapidement de 6 mm)
G38.2 X[str(_flong)] F100 (On avance en X de la longueur (au maximum))
G38.4 X-1 F20 (Après avoir touché, on s'écarte de 1 mm lentement)
%wait;
G4 P5
G10 L20 P2 X0
%_posXM = float(wx);
%print("PosXM = " + str(_posXM));
G91 G0 Z8 (remonte Z là où il était, puisqu'on est en coordonnées relatives)
%_distmvt = float(_flong + 10);
%print("distance mouvement 2 = " + str(_distmvt));
G91 G0 X[str(_distmvt)] (avance de la longueur indiquée + 10 mm)
G91 G0 Z-8 (On descend rapidement de 6 mm)
G38.2 X-[str(_flong)] F100 (On recule en X de la longueur (au maximum))
G38.4 X1 F20 (Après avoir touché, on s'écarte de 1 mm lentement)
%wait;
G4 P5
G10 L20 P2 X0
%_posXP = float(wx);
%print("PosXP = " + str(_posXP));
%print("Longueur trouvée = " + str(abs(_posXM) + abs(_posXP)));
%_diffPos = _posXM - _posXP
%_posXmi = float(_diffPos/ 2); (trouve le milieu pour X)
%print("Position milieu = " + str(_posXmi));
G10 L20 P1 X[str(_posXmi)]
G91 G0 Z8 (remonte Z avant de se déplacer)
G90 G0 X0
%wait;

[MARIOBASZ]

I am going to read your code, it will help me to continue learning: I am confused that you could write that way in the macro button: my knowledge is minimal. (I don't know if it will do anything, in the cnc file, in tool change it makes use of Wait, but surely you know it)

[BernardG]

I am going to read your code, it will help me to continue learning: I am confused that you could write that way in the macro button: my knowledge is minimal. (I don't know if it will do anything, in the cnc file, in tool change it makes use of Wait, but surely you know it)

Thanks for your answer. I forgot about that, I will check it to see what I could do to make it work from the button. Maybe I need to import something...

[rgodin974]

Hello, did you find a solution with %wait ? I would want like to do this macro too. Thanks

[swarfer]

I am finding that %wait is not working. Instead I am using G4 P0.1 to force bCNC and GRBL to sync at that point. V0.9.14-dev

[rasciodc]

I am finding that %wait is not working. Instead I am using G4 P0.1 to force bCNC and GRBL to sync at that point. V0.9.14-dev

So, this works as a 'replace' to 'wait' command? How did you incorporate that into your code do substitute 'wait'?

[rasciodc]

I am finding that %wait is not working. Instead I am using G4 P0.1 to force bCNC and GRBL to sync at that point. V0.9.14-dev

What you said makes sense since line 1946 from ProbePage.py uses the same trick. Wich is very odd because line 1947 uses %wait.

https://github.com/vlachoudis/bCNC/blob/5a2577f967d01cc040f431ae0afe6bbada34b870/bCNC/ProbePage.py#L1946

I'll make a test using G4 Px and see what happens since it does not look like this fix is coming out any time soon,

[Harvie]

it does not look like this fix is coming out any time soon

Pull requests are welcome.

[rasciodc]

it does not look like this fix is coming out any time soon

Pull requests are welcome.

I am sure of that. Unfortunatelly I am not proficient in python and after the python 3 stuff happened it got even more complicated for me.

I'm sorry I pushed your buttons there, was not my intention. Just trying to point out as a user what could be improved do keep bcnc a reliable option in an environment where more and more softwares are surfacing as great options to use with similar capabilities like cnc3d, rabbit and ultimate cnc.

Personally I'm still with bcnc but I reckon in this forum users that have gone elsewhere because of simple bugs like this that make things little bit frustrating even more knowing that the feature we need is implemented but simple bugs keep it from being used.

[3404gerber]

Hi everyone,

I started to try to code some macros in bCNC as I received my new touch probe. I quickly found this post after my first test. I have, or had, the same problem with the %wait command. Even though I have no coding skills, I spend some hours reading the code and trying to find out what was going wrong. I found out that, surprisingly, the macros are sent to the controller over a pendant function. This is at least what I understand from this code in Utils.py:

def execute(self): 
    cmd = self.command()
    if not cmd:
	self.edit()
	return
    for line in cmd.splitlines():
        self.cnc.pendant.put(line)

I decided to try to execute the code the same way it's done in the Probe.py file, so my new function now is:

def execute(self): 
    cmd = self.command()
    lines=[]
    if not cmd:
	self.edit()
	return
    for line in cmd.splitlines():
	lines.append(line)
    self.cnc.run(lines=lines)

It seems to work so far. I took the code example above, and made some correction to make it work (removed semicolons, and moved a comment). It also seems to work:

(Test sondage)
%_long = app.entry("Entrez la longueur de la pièce: ")
%_larg = app.entry("Entrez la largeur de la pièce: ")
%_flong = float(_long)
%_flarg = float(_larg)
%_posXM = float()
%_posXP = float()
%_posXmi = float()
%_posYM = float()
%_posYP = float()
%_posYmi = float()
%_distmvt = float()
%_diffPos = float()
%msg Debut de Sondage
(==================X=================)
(on assume que Z0 à été fait auparavant)
G91 G0 Z3
%_distmvt = float(0.5 * _flong + 10.00)
%print("distance mouvement = " + str(_distmvt))
G91 G0 X-[str(_distmvt)] (On recule de la longueur /2 + 10 mm)
G91 G0 Z-8 (On descend rapidement de 6 mm)
G38.2 X[str(_flong)] F100 (On avance en X de la longueur (au maximum))
G38.4 X-1 F20 (Après avoir touché, on s'écarte de 1 mm lentement)
%wait
(G4 P5)
G10 L20 P2 X0
%_posXM = float(wx)
%print("PosXM = " + str(_posXM))
G91 G0 Z8 (remonte Z là où il était, puisqu'on est en coordonnées relatives)
%_distmvt = float(_flong + 10)
%print("distance mouvement 2 = " + str(_distmvt))
G91 G0 X[str(_distmvt)] (avance de la longueur indiquée + 10 mm)
G91 G0 Z-8 (On descend rapidement de 6 mm)
G38.2 X-[str(_flong)] F100 (On recule en X de la longueur (au maximum))
G38.4 X1 F20 (Après avoir touché, on s'écarte de 1 mm lentement)
%wait
(G4 P5)
G10 L20 P2 X0
%_posXP = float(wx)
%print("PosXP = " + str(_posXP))
%print("Longueur trouvée = " + str(abs(_posXM) + abs(_posXP)))
%_diffPos = _posXM - _posXP
(trouve le milieu pour X)
%_posXmi = float(_diffPos/ 2)
%print("Position milieu = " + str(_posXmi))
G10 L20 P1 X[str(_posXmi)]
G91 G0 Z8 (remonte Z avant de se déplacer)
G90 G0 X0
%wait

Beside this problem, there is also the fact that I had to double the percent sign in the code. Found out that it was related to the configparser. The problem is that, after reopening the macro window, they were back to single %, so if you open the macro to modify something, you have to replace again all the % with %%. To solve the issue, I changed the line

config.set("Buttons", "command.%d"%(n), self.command.get("1.0",END).strip())

with

config.set("Buttons", "command.%d"%(n), self.command.get("1.0",END).strip().replace('%','%%'))

in the Utils.py file, so the replacement is done automatically when you close the macro window. This also works now. My last problem is that my dialog windows generated with the app.entry() function freeze every second time I start it from a macro or a g-code. Have no idea so far what the problem can be, as the terminal doesn't give me any information.

Maybe this can help someone to save a saturday afternoon... :)

Edit:

I found myself having a lot less frozen input dialog boxes by adding a "master.update()" function in the bmain.py file, just before the "v = d.show()" of the "entry" function. In the same function, I think there's also a mistake with the "input" variable and that the line

        d = tkDialogs.InputDialog(
            self, title, message, input, type_, from_, to_)

should be

        d = tkDialogs.InputDialog(
            self, title, message, input_, type_, from_, to_)

I noticed that if the indicated Status is changing while your entry box is opening, or open, the macro also have unpredictable behaviors. Adding a "G4 P1" command before a "%wait" function seems to do the trick. The following example works fine for me:

%_xTarget=app.entry('Enter X target')
G1 F100 X[_xTarget]
G4 P1
%wait
%_yTarget=app.entry('Enter Y target')
G1 F100 Y[_yTarget]
G4 P1
%wait
%msg Done!

Notice that if I start it a second time immediately after it ended, the status bar will change from "Done!" to "Idle" and the script will not react on my input and just stop. :/

[v-evets]

Maybe this can help someone to save a saturday afternoon... :)

You sir are a gentleman and a scholar. It didn't exactly save my Saturday, as that was already long gone wrestling with this completely borked timing and seemingly random misbehavior of user buttons, but it did save writing bcnc off as a bad joke and looking for something else.

Not sure what needs to happen to get this into master (which is still affected as of this writing, though % interpolation is fixed), but given the multiple reports duplicating or relating to it and the extreme frustration it can cause, not to mention scripting being a pretty killer feature to begin with, IMHO it should be bumped to the head of the queue.

Pretty sure I owe you several beers at this point.