Change in macro behavior in 1.2031?

[ger21]

I wrote most of my probing macros a few version back, and they've been working fine.
While doing some testing in 1.2031, I noticed that the feedrate commands were being ignored. Here's how I had it written:

Code: Select all

YStart = AS3.Getfielddouble(227); // Current Y axis Work Coordinate
ProbeL = YStart + Dmax; // Probe Length

exec.Code("F" + Frate1); // Set First Probe Feedrate

exec.AddStatusmessage(" ");
exec.AddStatusmessage("Probing for Y+ Position...");
   
exec.Code("G31 Y" + ProbeL); // Do First Probe move
while(exec.IsMoving()){}
   
Yhit = exec.Getvar(5062); // Read the touch point
Y1 = Yhit + ProbeD/2 + PlateOff; // Tool Center Position at Y=0
   
if (Frate2 != 0)
   {
   exec.Code("G0 Y" + (Yhit - Retract)); // Back away from edge
   while(exec.IsMoving()){}
   
   exec.AddStatusmessage("Slow Probing for Y+ Position...");
   
   exec.Code("F" + Frate2); // Set Slow Probe Feedrate
   
   exec.Code("G31 Y" + ProbeL); // Do Slow Probe move
   while(exec.IsMoving()){}
   
   Yhit = exec.Getvar(5062); // Read the touch point
   Y1 = Yhit + ProbeD/2 + PlateOff; // Tool Center Position at Y=0
      
   } // End Slow Probing

I couldn't go back to an older version to test, because my screen no longer works in the older versions. ( I suspect it's due to the blinking LEDS?)
So, I added the feedrate to the probe move for a quick fix.

Code: Select all

exec.Code("G31 Y" + ProbeL + " F" + Frate2); // Do Slow Probe move
while(exec.IsMoving()){}

Did something change?

And, on a related note, when do we need to use while(exec.IsMoving()){} or exec.wait(200)?

At the end of my macros, this block of code ran fine:

Code: Select all

exec.Code("F" + CurrentFeed); // Set Feedrate back to previous

if (originaldistancemode == 91)
   {
   exec.Code("G91");
   }
   
if (originalmodalmode == 1)
   {
   exec.Code("G1");
   }

I also found that adding exec.wait to the original code also got it working:

Code: Select all

exec.Code("F" + Frate2); // Set Slow Probe Feedrate
exec.Wait(200);

[cncdrive]

Hi Gerry,

I've just checked this out and there is a logic anomaly problem which I just explored when checking the issue you wrote down here.
The logic anomaly came from the new exec.Codelist function which required the macro executer to be seriously rewritten which I mentioned to you guys that I will have to do that if we want CV calculated motion from macros. So, now there is an issue with the feedrate readback in the Exec.Code, and I will have to think how to resolve this without making other issues, the solution will probably take some time, I mean I have to figure out how to resolve this...
The issue happens if a feedrate is set in an exec.Code and if there is no Wait after that and then there is another exec.Code, then the feedrate does not update, will be overwritten with the old value.

[A_Camera]

I also found that adding exec.wait to the original code also got it working:

Code: Select all

exec.Code("F" + Frate2); // Set Slow Probe Feedrate
exec.Wait(200);

A very simple workaround. Btw, I don't think you need to have so long delay. A simple exec.Wait(1); should be enough.

[ger21]

I think I tried a shorter value first and it didn't work, but It was late, so I'm not positive.

[A_Camera]

200ms sound like very long time.

[ger21]

I didn't have much time to do testing.
I think I tried a small value, and it didn't work, then tried the 200, and it worked.

At that point I just changed all of my code to move the F word to the G31 lines, and didn't test any more.

[cncdrive]

I have checked everything once again and talked to collegues and it seems we found the solution for this issue.
The problem is that the macro executer now has the Codeline function and for that everything has to work without any waits to be able to use the CV planner for this function.
Also the macros are now recompilable and so they can startup very fast.
The issue why the F does not set between the 2 exec.Codes movements is because the feedrate set command is basicly a zero size movement with the new feedrate,
but however it has zero size it still needs time to execute.
So, one problem is that the second exec.Code can execute faster than the F sets and updates on the first exec.Code, because an exec.Code is a new loop which will query the feedrate again this issue can happen.
This could be resolved placing a while Ismoving check after the feedrate set code, that will wait while the feedrate is set to the new value in the API, while the null size movement is executed.

The other problem is that the set feedrate is checked in a loop and because now the macro can start so fast it is possible that this loop does not update the new feedrate before the next exec.Code cycle starts.
Earlier this was not a problem, because the macro compiling required a longer time than how the mentioned loop updates.
I resolved this now with querying the feedrate not from the loop, but directly from the API in the macro executer and also from the cycle executer.

Summarising what can be done to resolve this issue:

1.) In the macros a while Ismoving is required after the exec.Code if it is a movement even if it is just an Feedrate setting code.
2.) The first point will not solve the issue in the current version, but will solve it in the next release, because I've made changes about how the setfeedrate information is gathered in the macro executer.

[ger21]

So, in the next versions, this line:

exec.Code("G91");

Will require the While...IsMoving, correct?

[cncdrive]

Hi Gerry,

The G91 is not a movement, so it does not require a While ismoving.
If you want the next line after an exec.Code or exec.Codelist to be in syncron and work correctly after a movement code is when the while ismoving will be required.
And in addition to the codes which is clear that are movements the F feedrate set code will also require this, because it is also a movement in the UCCNC, a null size movement.

[ger21]

Which codes are "movement" codes?
G0, G1, G2, G3, F..... Is there anything else? S?