Brian - that could be cool!
I'd also like something that can execute the homing from an M-Code / macro outside a button (more easily). 

Since the screen & machine control run concurrently, I wondered if any kind of semaphores have been implemented for cooperation between the two threads - and if these are exposed to the user (coder)? 

For anybody wondering what I'm talking about: https://en.wikipedia.org/wiki/Semaphore_(programming)

We have done this in the past but the issue is your looking at a complex setup with coroutine and a semaphore. The other crude way is to do a spin lock. I say this because your talking about doing this from an Mcode.... this will not do anything to the GUI thread.

One more little known way to make this work is with a button and at the top of the script have the word Private in a comment (must be the first line). If this is found the GUI will launch its own thread for that chunk. Now variables that can be used as semaphores are an issue. They need to be tread safe and we got you covered! The registers are threadsafe for a reason .

Okay you are making me talk geek... this help at all?

Brian - this is a pretty geeky forum!  I think concurrent programming barely counts compared to machining and programming generally!

A low level spin lock is the kind of thing I was hoping for.

If registers are thread safe - and you can make a private button act as the arbiter to prevent deadlocks, I can have the MCode set registers as a signal / handshake, arbitrated by the button to either the PLC or a screen timer to kick off the referencing.  I'll give it a go!

Another (even more geeky) question.  The API reference gives the syntax in both Lua and C++ forms.  Does this mean there is the possibility of scripting in C++ through a different IDE? (he says hopefully!).  While Lua is OK, the lack of explicit type casting kind of makes my skin crawl!

Hi,
not quite sure why anyone would go to all this bother.......I home my machine then leave it.

For instance my machine was last homed a fortnight or so ago, and I've never switched it off since.
If I have reason to believe that the referencing has been broken or compromised, like an Estop or similar,
then I will re-home it but otherwise I leave it alone.

The only time my machine shuts down is if we get a power cut....and that hasn't happened for several months.

At one time I had code that prevented the use of either the <CycleStart> or <MDICycleStart> buttons from being active
UNLESS the machine is referenced. I had a separate <CycleStart>button that I could navigate to and execute that was not
disabled by the machine not being referenced, should I ever need it. I managed to lose the code when I updated Mach over a year ago
and just can't be bothered to redo it.

Some days my machine will be running Gcode for four hours out of an eight hour workday, and really frilly little controls aren't going to change that.

Craig

Craig, I agree with your observation.  It there are times when the material is what your “homing” against. This happens in custom machines from time to time. There are other ways to make this work like setting fixture offsets on the fly. The other reason for homing is to check the machine to make sure it is on position. I think this is a G27 or something like that. I didn’t make this up, early fanuc’s had this.

So this all brings up a very good point, what problem are we solving ? Is this just a hard stop homing procedure?

I guess I've just got used to my Fanuc controller insisting on referencing the axis at startup and on a toolchange.  I also leave the machine (or at least the controller) running all the time - but something like this just saves the machine from my sometimes less than perfect memory!

Such a small addition to the code seems worthwhile compared to the cost of a tool-crash.

Another (even more geeky) question.  The API reference gives the syntax in both Lua and C++ forms.  Does this mean there is the possibility of scripting in C++ through a different IDE? (he says hopefully!).  While Lua is OK, the lack of explicit type casting kind of makes my skin crawl!

Yes we have a C++ API interface that you can use but you need to have a DeveloperID to get it to compile. Send me a message and we can give you the NDA for that. It is not a big deal, it is more that you will support anything you put out. But I agree, LUA has a face only a mother could love

Hi Brian,
this maybe slightly off-topic but it is an issue that I encounter from time to time which is damned inconvenient.

The majority use my mini-mill gets is isolation routing PCB's. To do this I use Autoleveller which is a software utility
which probes the PCB blank prior to isolation routing and then modifies the Z axis heights of the Gcode to accommodate variation
is Z height of the blank.

To do this it opens a Probe Data File, hence the first use of your m401 Lua example.

Every once and a while the probe routine fails, the last instance the damned clip fell of the circuit blank so I hit <Feedhold> followed
by <Stop>. When I attempt to re-run the probing routine I run into a problem, namely that the original Probe Data file is still open
and I cannot therefore re-run the job. Not even a Disable/Enable cycle will do it, I have to shut Mach down and start again.

At this time I already have a blank, possibly one side already routed, in the machine so re-referencing so that the existing work lines up with subsequent
ops is a PITA.

What I really want is a means of forcing closure of an open Probe Data file in those few circumstances when I need to force it closed.
Do you have any suggestions?

Craig

I don't have an idea at the moment but I will think on this. I have not looked at the probe to file code in a LONG LONG time

A thought is if you can vacuum the part down and it is the same all the time could you use the surface map plugin? This would do what your other software is doing.

Hi,
the surface map plugin is optimized to probe the bed of the mill and thereafter make subtle adjustments to the Z axis, but probed once,
the data set installed once, and then left alone.

For making PCB's the blank needs to be probed on every occasion. I can almost hear you say that if you vacummed it down
to a flat surface variation in Z would not happen....BS. All PCB blanks have small warps, twists and bows, they may only be 0.1-0.2mm
but enough to totally screw isolation routing. Additionally what happens to your vacumm holding when you drill through the board?

No, I use double sided tape to hold the board down with the addition of two 1.5mm alignment pins, and I probe the board on every
occasion. I have been using Autoleveller successfully for six years, it allows me to make a nominal 0.05mm depth cut (copper layer =0.035mm)
and get perfect isolation every time despite the PCB/spoilboard having Z height variance across the board of up to 0.4mm, depending on the size
of the board.

The only issue is when I have a glitch with the probing routine. As I posted earlier it happen about a fortnight ago, and I had to power cycle
Mach and rehome. In the intervening fortnight I've made 40 or so boards without issue and therefor no need to re-home. I can go for months
without a glitch, but they do happen. I would be nice to have a means to force close the Probe Data file without having to shut Mach down.

Craig