Dear experts,

I lost almost all week reading different posts from pervious threads but I couldn't find solution for my problem. I have CNC router, CSMIO IP-M controller, Leadshine closed loop stepper etc, machine works without any problem. Most of the time it is used for stone engraving using V bits and due to unleveled stone surface some letters are too deep and others are not engraved at all. I saw autoleveller as great tool, I use that tool previously with mach3 and LPT cards without issues. But this setup (Mach4 and CSMIO) drives me crazy. I found custom M40 and M41 macros (tnx to joeaverage) and put registry values (ALdata, etc) . Routine look ok, in beginning it makes two measuring moves, ask to create triplet file, continue to make measures and finish procedure. Then problems starts to emerge. First is Mach4 notifications ( Data mismatch value X, value Y) and number of windows is equal to number of measuring points. After that file is created but Z value is "shifted". For example, in point B values of X and Y is from point B, but Z axis is from point A. That makes totally wrong surface plane.
Do you have and advice? Thank you in advance.
Samir   

Just to add result from generated file and error ( total 6 pount to measure ):
X2.6810 Y4.4490 Z0.1834 (initial measure)
X146.9640 Y4.4490 Z-2.0986 (second point but Z axis is from first point)
X291.2470 Y4.4490 Z-1.7330 (third point but Z axis is from second pount)
X291.2470 Y187.8600 Z-1.0205
X146.9640 Y187.8600 Z-3.6611
X2.6810 Y187.8600 Z-4.3580
6 point measure missing completely

Screenshot of error message is in attachment.

Hi,
I use AutolevllerAE and have done for years.

The message you are getting is from the m41 script which I wrote.

In Mach3 there were two macros M40 and M41 that open a probe data file and M41 closed it. Mach4 does not natively have those two macros.
It does ship with two examples, m400 and m401 which essentially replicate the Mach3 M40 and M41. I took those examples and in the case
of m41 modified it extensively to qualify the data. The message you are getting is because the macro recognises non-compliant data in the probe data file.

There is a subtle difference between the way Mach3 and Mach4 records the data. In the case of Mach3 it records the X and Y coords
direct from Autoleveller and the Z coord from the measurement performed by the G31 move. Mach4 on the other hand records the actual
X and Y coords plus the Z measurement from the motion controller. In an ideal world the X and Y coords would be identical wit the X and Y
probe point supplied by Autoleveller. In reality the machine X and Y may differ very slightly, with my machine at that time, I measured a difference
of 0.02mm on average. The problem arises when Autoleveler goes to calculate the Z axis corrections. If the measured and ideal X,Y coords differ
by as much a 1 at the fourth decimal place then Autoleveller screws up royally and calculates wild variations in Z, which if undetected will
result in your machine crashing BIGTIME.

The second thing that M41 does is check that there are the right number of data triplets in the probe data file  as there is probe points in Autoleveller PGF file.
At that time there was a quirk of my ESS controller that would sometimes record an occasional extra data triplet or two. Thus if Autoleveler decides to probe the
PCB 110 times but the data file could have 112 data triplets, then Autoleveller would screw up. My macro counted the data points and compared to what
Autoleveller  PGF file demanded.

The ESS quirk that caused that issue was fixed six years ago so this fault only now happens if the probe routine screws up somehow....I've had it happen
twice in over a year. I doubt therefore that is what is causing your issue.

So getting back to the message, if the macro detects that the X,Y coords reported by the motion controller differ by more than 0.02, or whatever
you set the parameter Atol to, then it would generate an error with message. I suspect that your raw data is being compared to what Autoleveller specified
and there is a large difference between them. You could ignore the message and have Autoleveller calculate the Z axis corrections but I would expect
it to be BIG TROUBLE.

Print both the ProbeDataFile  AND the Autoleveller generated PGF file and compare the two closely. Can you identify each requested probe position with each data
triplet? That is in effect what my macro does and has been doing for me hundreds upon hundreds of times over the last six years.

Craig

I'm using CSMIO/IP-A controller and I got the same trouble with "data mismatch" warning when implementing Autoleveller with Mach 4 using your M40 and M41 scripts. So maybe it is a CS-LABS related issue?

I added delays in the probing script to figure out what caused this and in the end I found the reason this mismatch is happening is because every time I run the probing command G31.1 it will write the coordinates from the previous probing cycle, so the last probing point was never recorded. My workaround is to probe twice at the last probing point. That way I get the last probing point into the file.
This also means that the first data point that is being recorded is data from the probe cycle happening prior to M40. Because it has approximately the same values as the second point, one of these are deleted as they are considered duplicates.

I tried to figure out how the registers actually is updated after M40 is activated to see if I could figure out a better way to solve it, but I wasn't able to understand how the registers actually are being updated. Do you see a better way to solve this?

Hi,
I wrote those scripts seven-eight years ago and have used them thousands if not tens of thousands times since. I do not recall ever having the problem you describe.
In particular your description of when a data triplet is committed (to append to the open file) does not make sense to me. If your installation is doing that, then why is mine not?
I suppose its not impossible that the CSMIO plugin and the ESS plugin differ in in such a manner as to cause the data to 'hang up'.

Either way you have the source code, you may just have to modify it to suit your installation. You might think about 'flushing' data to the file at each g31 read. A bit clunky
but it would solve the issue.

Craig