M98 issue

[Alberto FUL]

I need conditional jump in my G-code so I'm using M98 together with some checkboxes.
If checkbox is ON #600=1, else #600=0
In my G-code:
...
M98 P1001 L#100
...
This is not working.

So I'm trying another soultion with macro:

Code: Select all

// M600 JUMP TO SUBPR0GRAM 1001
double var600 = exec.Getvar(600);

if (var600==1)
{
exec.Code("M98 P1001 L1");
}


Only If this macro is called via MDI it jumps to the specified sub-prog otherwise is ignored.

Any suggestion ?

[Alberto FUL]

Thanks for help but still having problems:
I have a check box in my screen so I can decide to jump or not to sub-prog.
The check box works fine, I mean When I check it var #600 goes 1, otherwise is 0.
I see the var changing in the diagnostic plugin.
But when I use soemthing like this:
M98 P1 L#600
the software does not recognize the var has changed; the system udates the vars only when I reload the G-code.
I mean: if my checkbox is TRUE (so #600=1) and reload the G-code then it jumps to sub-prog.
Then I switch the checkbox to FALSE (so #600=0) but not reloaded the G-code, it jumps to sub-prog again.
Once the G-code is reloaded then everything works fine.
Am I missing something ? Maybe something to refresh the value of vars ?

[cncdrive]

I have just checked this and there is really an issue about how this works in the UCCNC now.
If L is 0 then the code is not even interpreted, because there is no M98 call happens then as the number of calls is set to 0.
And when L is not 0 then the code is interpreted and subroutine is called L times.
The problem is that if the L variable changes to 0 then it will still run 1 time now, because 0 time is not allowed in the interpreter.
So, this is a problem in how the UCCNC is now handling this case.
We will fix this in the next release, will change the interpreter to interpret L=0 value also and will move the handling of the L=0 value case to the executer.
So, I'm sorry, but now this will not work unfortunately as you want it to work, but it will in the next release.

[cncdrive]

Hi Terry,

I don't know how the OP is updating the var, but it is not too important now, the important is that the var was updated.
For the tests I made now I wrote a simple macroloop which reads the checkbox and sets the # var to 0 or to 1 depending on if the checkbox was ticked in or not.

The problem now is that when L is 0, is defined with a var e.g. L#1 when #1 == 0 then the interpreter sees that the value of the L is 0 and so it does not even interpret the M98 code which is the problem now.
So, when the #1 and so the L was 0 when the g-code was loaded then the code was not interpreted, so the user changes the #1 var to other than 0 will still not enter the subroutine, because the M98 line was not interpreted on loading.
How I will change this is that the interpreter will interpret also when the L parameter is 0, but when it is 0 it will not enter the sub and this will be handled in runtime in the executer.
So, the overal working will be the same as now after the fix, but the L parameter when it is defined with a #var then it can be set to 0 and from 0 to other value also on the fly which is not working properly now.

[Alberto FUL]

Hello Balasz,
In the meanwhile pls check strange behavior of M98 combined with M1.
If there's an M1 in between the Oxx and M99 the sub-prog is executed twice instead of once, and stack error is generated.
Thanks