Absolutely nothing wrong with your Gcode.
Here, the m113 executes before the X axis starts to move and the m115 executes after the Y axis has returned to zero.

Could be that the problem lies within your NVUM controller software plugin but I have no way of testing or confirming this.

Tweakie.

Ah yes I forgot to dig into the NVUM controllers. Many thanks for checking on your end, I know now the issue does not come from my g-code or Mach3 setting. Just for my curiosity, does the command lines go faster than the coordinates move, or they are synchronized on you side?

For now I carry on work with the manual controlled spindle, it is still fine. Will post any further news if I have.

Here the next command line is not executed until the axis movement from the previous command line is complete.

Tweakie.

Could it be the Lookahead 20 or more lines in config | general Config?

Could be, but the Gcode itself is only 10 lines long.

Tweakie.

Could be, but the Gcode itself is only 10 lines long.

Tweakie.

What I meant was the default lookahead in Mach3 is 20 lines.
What if we change that setting to just 1 (0 is not allowed).
Will Mach3 then execute command line one line at a time SLOWLY?

Quote from: Tweakie.CNC on May 12, 2019, 07:52:00 AM

Could be, but the Gcode itself is only 10 lines long.

Tweakie.

What I meant was the default lookahead in Mach3 is 20 lines.
What if we change that setting to just 1 (0 is not allowed).
Will Mach3 then execute command line one line at a time SLOWLY?

Should have mentioned this earlier, I have also tried this before, setting the look ahead lines to 1. Unfortunately there is no visible difference in the way it goes.

Today tried to change the NVUM driver but there isn't too much alternative available. I've got 2 DLL's and both of them give the same result. Novusun.dll and Nvum_release.dll.

Also tried to run the g-code with parallel driver loaded. Of course it's not possible to drive the machine, but when g-code running it can be seen the driven coordinate is "vibrating" and sequence seem to be normal. I.e. when the driven coordinate stops "vibrating" then the next command line starts to be loaded and ran.

So far I'd agree with Tweakie, the trouble comes from the NVUM driver. But seems there isn't better way to prove or solve it...

Hi
I notice that you are using custom M codes M113 and M115

In macros written in Visual Basic you can use

while ismoving()
wend

So if your m115
has
Code "G1 Z0"
while ismoving()
wend
...
(your codes)

You perhaps may delay the turning off of laser output.

Another possible Workaround is to use a long bent micro-switch to turn on the laser when z axis is lowered towards the material surface. Microswitch would turn off the laser when z axis is raised.
(some have done it that way and made videos on YOUTUBE)

Hi
I notice that you are using custom M codes M113 and M115

In macros written in Visual Basic you can use

while ismoving()
wend

So if your m115
has
Code "G1 Z0"
while ismoving()
wend
...
(your codes)

You perhaps may delay the turning off of laser output.

Another possible Workaround is to use a long bent micro-switch to turn on the laser when z axis is lowered towards the material surface. Microswitch would turn off the laser when z axis is raised.
(some have done it that way and made videos on YOUTUBE)

Hi Reuelt,

Both are very practical workarounds. I just got the chanve to try the code one, and was sure it will work although some delay. But to my surprise it did not change the outcome, apparently for Mach3 the move is already at it's end, while it's loading the command line. I guess in my Mach3 the command lines and the coordinates are separated from each other for some reason.

Don't have chance to test the limit switch option yet, but I am sure it will work. 

The attached image shows what I keep getting.

Only for this one I reduced the size from 100mm to 20mm.

Kebelcar in Feb2019
posted using a microswitch for his laser
https://www.youtube.com/watch?v=3wBpa7--aBM&feature=youtu.be

AFTER he could not get a solution at this forum