Guys Please do not use this version it has a bug. We are trying to work it out.

(;-) TP

DO to another mach3 QUIRK this function cannot be made 100% dependable in all conditions .

Please do not USE.

(;-) TP

> DO to another mach3 QUIRK this function cannot be made 100% dependable in all conditions .
Should that read
Due to another mach3 QUIRK Mach3 cannot be made 100% dependable in all conditions ?
:-)

Cheers

YES please don't do it in that instance either. (;-)

BUT actually we have it running just fine now, it took a while to work around the quirks.

NOW IF we could get the "Write to file" corrected so it did NOT write IF the G31 did not trip by the end of motion(endpoint).

(;-) TP

So this now works?

NOW IF we could get the "Write to file" corrected so it did NOT write IF the G31 did not trip by the end of motion(endpoint).

Um ... not sure about that one. I can think of situations where having the end-of-motion data could be useful as a warning flag. I am sure that won't apply in every case though. Perhaps it needs to be an option?

Cheers
Roger

HIYA Roger. The problem with the "write to file" is that mach3 does NOT issue error codes when that occurs. So to the program that processes the points file it cannot tell the difference between an actual trip or an end of motion value. That leaves the points file corrupted. NO point is much better than a corrupt value as far as the point cloud is concerned.

Yes IF you are doing the write to file VIA CB you can do a compare BUT that really SLOWS the process down. and really all you would do is NOT write the value if it is the same as teh end of motion value.

Hiya GER. I will have to check with Scott to see IF he has redone the Plugin to the FIXED version. Here I use the older Plugin and a macro pump to make it all work. Scott was going to include the macro code into the plugin so it would work with all current version of MACh3.

So far I have NOT been able to fool it and I have really tried(;-).

(;-) TP

The problem with the "write to file" is that mach3 does NOT issue error codes when that occurs. So to the program that processes the points file it cannot tell the difference between an actual trip or an end of motion value. That leaves the points file corrupted. NO point is much better than a corrupt value as far as the point cloud is concerned.

Could be complex, or even 'not possible'.
The ESS (for instance) logs the XYZ values within nanoseconds of the touchprobe signal (which completely ignores the delay introduced by any filter on the line!) and passes the data back to Mach. But I question whether Mach can distinguish between genuine touch-probe data and the end-of-motion values. Yes, to be sure, a design problem. But since V.043.022 manages to get confused between the touch-probe data and the START-probe values, it would seem that the code there may have some very fundamental design faults. Yes. that version of mach can write either value to the data file - and does on my machine.

I find it useful to have the data written to the file whether or not the touch-probe actually touched. I can filter out the end-of-motion data later, and that tells me when I have a problem with the scan path. If you have a multi-megabyte file of points that could be painful, but I don't probe for point clouds at present.

IF you are doing the write to file VIA CB you can do a compare BUT that really SLOWS the process down.

Yes, I am using CB for the file writing, but I hadn't noticed any speed penalty myself. I do probe slowly.

Cheers
Roger

HIYA Roger, With probing routines running close to 1 million hits the CB write adds HOURS to the routine by the time I am done. EVEN with my newest creepy crawler routine it does slow the process down compared to useing the Direct file write of the M40/41. BUT be cause Mach3 does not error it currupts the actual data with end of motion writes. So for now the creepy crawler is limited to the speed of the CB write. The actual probing motion CAN be very fast IF you are brave(;-). The probing actualy runs in straight Gcode (not a macro call) and so far is stone cold dependable. ONLY the file Write is done in CB.

Just a thought, (;-) TP

Hi Terry

With probing routines running close to 1 million hits the CB write adds HOURS to the routine by the time I am done.

Ah - yeah, different application for sure! I use the probing to check the alignment of things on the mill table. Only a dozen or two actual probe movements. Very different.

I did manage to check the alignment of the mill table too. With a couple of layers of aluminium cooking foil inserted in the right place the surface is now square to the Z axis to within about 8 microns across the full width and front-to-back. Jig alignment stops are also square to within 10 microns, possibly less.

It may well be that a later version of Mach will handle probe data writes properly, but I am trying to hold out for Mach4 instead.

The actual probing motion CAN be very fast IF you are brave(;-).

Errr ... welll... not today.
If I bust one of my probes I just have to make another one, but I can imagine someone with a Renishaw might be a bit hesitant!

Cheers
Roger