Thanks for the suggestions Terry - I have probably got most earlier versions so this is something else for me to try.
I started out using the Z axis direction pin but that has the delay of the small amount of 'would be' z travel, so I then moved on to the M11/M10 combination. It was in an old thread that Brian mentioned the E1P0/P1 and that has been quite good if it worked all the time (but of course it doesn't  ).

Going back to the Z dir pin if I could move the 'Z minus' instructions to the start of the next G1 X or Y axis movement then the laser would be triggered at the time of movement but this would not help with switching it off at the end of the movement and modifying existing GCode would possibly start to become complicated. I am really trying to keep this simple by using the same GCode that would be used for engraving and just replacing the Z codes but perhaps this is not going to be possible.

As said before I do appreciate your time.

Tweakie.

HUM I would have though that being the pulses would be loaded into the output buffer that the pulses would be pretty much instantanious.  AND with CV on there would be no possible delay.
Guess not???

Were you using a 1 step size move with the Z axis to control DIR?

Were you using a 1 step size move with the Z axis to control DIR?

It was a while and I will have to look up some earlier code examples for this but from memory I think it was more than just one microstep.

Tweakie.

Hi Guys,

I think Terry's suggestion has solved my problem.

By revisiting the use of the Z axis direction pin method of control I have found that previously I had been using a Z movement of +/- 10 microsteps. Changing this to a distance of 2 microsteps total movement (+/- 1 microstep) has made dramatic improvements in the work quality. (not sure if it will work at +/- 1/2 microstep or 1 microstep total but I will give this a try).
It needs a bit more testing but so far the results are absolutely brilliant, there is no sign of overburn at the start or ending of long or short lines and the cut depth in acrylic is pretty constant at the start and ends. It is a shame I don't have a close up lens for my camera because the difference is just so great it really deserves a picture.

Thank you all for your assistance and time spent on this - I think I can now safely ditch the E1P1/P0 and M11/M10 etc. etc.

Tweakie.

Tweakie - can you post a copy of your latest gcode using the dir pin method and a copy of the M10/11 version. Obviously it's good you have a solution that's working for you but it's still a kludge. I'm thinking this problem has to do with CV and I'd like to scope your latest solution just for fun to see if I can home in on exactly why it's better than M10/11.

Thanks

Ian

Thanks Ian,

Due to location of my equipment I am unable to measure the pulse timing at present but I would be most interested to know what it is.

M10 and Z control files attached.
(I am changing the Z dir pin, in ports and pins/motor outputs, to my laser trigger pin16).

Tweakie.

Tweakie I don't think  1/2  step will work as mach will HOLD the move until the next move. You will need a minimium of a 1 step for mach to apply the move.

Ian I think the problem does lies with VB or at least the VB/GCODE interface. Mach used to behave MUCH better than it does now. I think the attempt to fix the VB sync problem has caused delays. ALSO you used to NOT have to use HOLDS to make the VB/GCODE work correctly, it just did . NOW it takes a ton of wait states to make it work AND it is different with every other computer as to how to make it work sometimes.

There has to be a better way(;-) I would not be apposed to ditching the VB for VB/GCODE and goto conditional Gcode and ONLY use the VB for user macros for I/O and internal functions such dros,led,button controll. BUT the brains do a far better job in most of these areas.

(;-) I think we have LOST sight of mach as a machine controller and have converted it to a DOALL piece of motion software. AND we "LOST" machine function in the process

The Dir pin pulse is included in the pulses sent to the buffer so there will be no delay from the last pulse of the Axis move to the stop laser pulse.

Ian I think the problem does lies with VB or at least the VB/GCODE interface.

Terry - I agree that there are BIG problems with VB and it's interface to Mach - BUT - the E?P? code that Tweakie posted in his first post doesn't use VB AT ALL - so how can the issues he raises be anything to do with VB?

Ian

Ian we don't know HOW ART made it work (;-) It could very well be VB based code ??  OR it may use the VB interface to the Gcode side  .

We do know it suffers that same type of random delay problem as VB does now.

Hey Guys,

Just as a by the way thing....... If the command E1P0 is changed to E1P0M5 then the code runs perfectly every time on the few examples I have tested - But the turn off delay is increased again almost up to the levels of the M10P1.
Don't suppose this helps but thought I would mention it.

Tweakie.