Ok, possibly not in the right forum for this and it's not a Mach gripe for certain but...

On my plasma, I have the Z axis homed to the plate surface at every start, Z axis is controlled by the THC as normal (CandCNC MP3000-DTHC2) during the cut and the last line of the code is G0 Z15 which should park the torch at my safety height.

What it does though is park it at Z15 +/- and difference in the THC readout, so if the cut ended with the torch at 1mm lower than it started, it parks at Z14 not Z15.

Is there an easy to explain reason this could be??

Its like the THC is updating a work offset or something during the cut rather than just issuing up & down commands.

Is it in Incremental mode (G91)?

Hi

No, G90 absolute

Dave I did not remember off hand are you using the ESS as the controller??  I do not ever recall that happening from the LPT version. It could be a bug in the ESS plugin if you are using it.

(;-) TP

Sorry but no I'm still on the Parallel Port system

HUM I will look into that one.  Is it that the DRO is correct and the machine is not in correct position or the DRO as well is not at position.  Wht version are you in. With CandCNC stuff you should be in Version .067.

(;-) TP

I will check the actual physical position today but it is running V.067, always has been.

Ok, tricky one to assess but it stopped with a DRO of 14.80, I moved to the same point as it took that reading from and used a pair of callipers to get a reading of 15.00mm then dropped it using G0 Z1.00 and using a set of feeler gauges got a reading of 1.2mm so something is off here.

It definitely does not seem to be updating correctly at the end of a cut - whatever the THC 'moves' DRO shows at the end of the run is the error in the work DRO after being told to go to Z15 so it never really reaches Z15 - baffling, any ideas?

I am guessing here but it looks like that Mach3 got caught half way in last THC update. It did teh actual move but failed to update the dro. For the most part errelevent. As teh THC is constanly interupting teh Zheight from Gcode.  I would figure like as Mach3 treats a partial step value it would catch up on the very next cycled move and work out the differiental value back to be accurate. 

Just a thought, (;-) TP