Autoleveller

Hi All,
have in recent days migrated from Mach3 and parallel port to Mach4 and a SmoothStepper external motion control card
and have had some challenges getting Autoleveller to work with the new combination.

As has been reported on a similar thread on this forum Mach4 uses different # variable numbers. A find-and-replace edit is
required to get the early generations of Autoleveller to work, but work they do.

My own work flow absolutely requires the added functionality that a probe file confers, ie Autoleveller0.8.7, know as AL,
and its immediate forbears, and AutolevllerAE v0.7.8, known as AE.

Mach4 does not have native support for opening and closing probefiles, that functionality is conferred by appropriate macros.
Two examples are shipped with Mach4: M400 and M401 in the ...\Mach4Hobby\Lua Examples folder. With a few keystrokes
editing and renaming they behave in identical fashion to Mach3. I have attached them should you wish, note also that I had to
rename them as text files in order to post them. Change them back to Mxx.mcs and put them in your current ...\profile\macros
folder.

I have encountered two not insurmountable problems in getting useful code from either AL or AE.

The first issue, and I suspect and hope is confined to my machine, is that Mach4 records a random number more data triplets
in the probefile than the number of probe cycles commanded by AE/AL. I have yet to resolve why. Certainly neither AL/AE
will produce any useful results with such nonconforming data. I would strongly recommend that you open your probefile
in either Notepad++ or a spreadsheet and check that there is in fact the right number of data triplets to match AL/AE mesh points.

The second issue concerns how Mach4/controller gathers the data triplets, Mach4 reports the actual X,Y position at the probe
event whereas the PP equipped Mach installations report the programed X,Y position. Inevitably there will be a small error
between the two. Neither AL or AE behave well if the error is significant. AL has a tolerance built in (0.02 units) which allows
probefiles generated by my machine to work. AE on the other hand requires near identical (one digit rounding in the fourth
decimal place) or it will fail to recognise the probefile or give wild Z variations if it does.

If I manually edit the probfile X,Y positions to match the expected and exact mesh points of AE it works well. A tedious rather
than difficult edit. I measured the rms variation of my machine from theoretical best as 0.0225mm.

I indicated to James my intention to author a program or module to facilitate the procedure and have been working at fever
pitch to produce such code. I have made good progress. Working in Lua the Mach4 scripting environment I have working
code. AE conveniently uses G1 codes to command the X,Y preposition moves and makes for a fairly simple 'strip' to produce
the mesh positions from the Gcode file, no navigating file directories required, its part of the M41 close macro. The same macro
also opens the probefile just generated and checks for extra or unintended entries and as they are duplicates, at least on my
machine, and strips the offending duplicates. It then produces a corrected probefile and offering a tolerance warning in case of
larger error than anticipated, 0.02 units, per AL practice. Lua does have some simple string functions that with care an
imagination can be made quite effective. Whether they be computationly efficient is another matter. My practice probefile
is 11kB with 210 probe points and processing near instantaneous. A proficient programmer like James may well shake his head
in askance at my efforts but as he lives on the other side of the world I can probably 'blow raspberries at him' without great offence!

I will spend a few days or even a week trying to polish the code and if possible make it a little more robust, it's quite sensitive
to file/data format. I would also like to test it more by running multiple files thru it. If anyone is desperate for them or is willing
to help with the testing, by all means let me know.

Last word, when AE/AL go cranky they can do so in subtle ways and in restricted locations of the board. Thorough toolpath
checking with a simulator or viewer is mandatory before committing it to your hardware.

Craig

Thanks Craig. An invaluable post for Mach4 users.

Hi All,
I have some working code, pretty amateurish, its my first attempt at LUA coding. The files will have to be renamed to
Mxx.mcs as before and put in your profile/macros folder.

In order for the two macros to communicate I have used the persistent register functionality in Mach4. The registers
will have to be set up prior to use:

1) Ensure the plugin Configure/Mach/Plugins/Regfile is enabled,
2) On the Configure/Plugins/Regfile/Instances window add three new registers
i) "ALcode", no initial value required
ii) "ALdata", no initial value required
iii) "ALtol", initial value 0.02 recommended but your choice,
3) The registers contents can be inspected and edited if need be on Diagnostic/Regfile--expand iRegs0.

There is some error trapping and reporting built in but nothing in the way of recovery yet. Code seems to work well when
called from the AL/AE G-code probe job or the Lua editor but less successfully if called from the MDI line. Hopefully future
versions will add that functionality without compromising its almost invisible footprint when called from G-code job.
Have just started to get my head around the string pattern/capture functionality in LUA and again may in future find stronger
and more readable code. Have not added any code to update/change the tolerance as yet, a manual edit per iii) above
will have to suffice at the moment.

Any problems please let me know. You are my guinea pigs.

joeaveraege wrote:Hi All,
have in recent days migrated from Mach3 and parallel port to Mach4 and a SmoothStepper external motion control card
and have had some challenges getting Autoleveller to work with the new combination.

As has been reported on a similar thread on this forum Mach4 uses different # variable numbers. A find-and-replace edit is
required to get the early generations of Autoleveller to work, but work they do.

Great stuff in this threat. Thanks you. Keep up the good work!

@joeaverage, What is the software license for the code you posted for the M40 and M41 macros?

Can it be freely distributed by others?
Do you want it to be considered public domain? Or you want it's derivatives to remain open source (i.e. GPL)? Or something else?

Thanks.

Hi Sorch,
as you have no doubt gathered my m40 and m41 are much expanded and developed versions of m400 and m401 which ship
with Mach4 as Lua examples. I do not know exactly what licence conditions applied to them, certainly the Mach community
which includes Artsofts developers recommend cutting and pasting code provided as examples.

As for that portion of the code, substantial fractions of m41 in particular, that I coded is open source and has no conditions attached.

Distribute it as you see fit. I had always hoped that if others contributed or modified that they too might post freely to the community
but I have no right or real inclination to insist.

That someone is interested enuf to consider it has come as a surprise...enjoy.

Craig

Hi,
did a little research and while neither m400 or m401 have a licence header other Lua examples that ship with Mach4 do,
and should apparently remain attached to any subsequent publication. They are released under MIT licence so pretty much
anything goes.

Craig

Thanks Craig! I appreciate you looking into this.

I didn't get any automated notification that you replied to my question so I just found your answer today. Believe it or not I was still interested in the answer.

Thanks again,
Scorch

Hi joeaverage (Craig),

Any updates on the usage of implementation of M40.mcs\M41.mcs?

Any other useful discussion links/updates?

I'm just about to try it out having set up Mach4 registers and LUA editor. Using ESS smoothstepper.

Steve

Hi,
I haven't used Autoleveller for a couple of months but everything worked fine the last time I did.
If you've followed this thread I wrote these macros to accommodate the fact that I would end up with
extra entries in the probe file and even the smallest variation between the actual verses the exact location
of the probe point caused a numeric fault.

The last few times I've used Autoleveller I noticed that no extra data points had been recorded. I now believe
there was an unusual fault in the ESS plugin that allowed such errant behavior. There was a very good discussion
about it on the Warp9 forum about three months ago. Andy tracked the problem down and resolved it as of build 216 or
so.

I'd be interested to hear whether your installation records an extra data point or two.

Even if the later builds of the ESS plugin have solved the extra data points issue the macro is still required to ensure
that the actual probe point is numerically identical to the exact probe point as calculated by Autoleveller. To my
knowledge M41 is doing that fine.

Let us know how it goes.

Craig