Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: dbt3000files on January 05, 2018, 05:44:14 PM
-
I'm having trouble creating a macro that will reliably do the same thing as the "Reference All Axes" button. The following works every time in the Lua editor:
function reference_all()
inst = mc.mcGetInstance()
mc.mcAxisHomeAll(inst)
end
reference_all()
However, if I create following macro it works great in the Lua editor, but when I run it as an m code, nothing happens.
function m91048()
reference_all()
end
I figure that it has something to do with the "Reference All Axes" button using a coroutine, but I am not sure how to get a macro coroutine to communicate with the plc. (or if that is even the right approach) Just looking for the simplest way to get the m code to work the same way as it does running it from the Lua editor.
Thanks for any help!
p.s.
I will add a little more background information in case it helps. I am trying to create a homing routine for Clearpath motors that have hardstop homing. (meaning that you run the axis into a wall and the motor senses the resistance and stops itself) So I am hardstopping the axes, backing off a preset amount and then need to zero all the axes. With Mach4 set to "home in place" G28.1 causes strange and erratic behavior, either crashing Mach4 or wildly jerking the motors, so I need a good alternative.
-
Did you ever figure this out? I'm trying to add a physical button to ref all axis on my lathe screen.
Is there a function code already in the Mach 4 API? So I can just add a simple code to the script?
-
Didn't figure out my problem, however you should be able to copy the script of the ref all home button in the wx4 screen. If you also copy the Ref All Home section of the wx4 screen load script and transfer it to the screen you want to you use, it should work.
I think that there is some issue about putting a homing command in a macro in mach4. I'm still trying to figure out what that's all about.
-
OK thanks.
-
Hi,
I think that there is some issue about putting a homing command in a macro in mach4. I'm still trying to figure out what that's all about.
The problem with putting a homing command in a macro is that a macro is run by the interpreter whereas the homing command is initiated by the GUI.
There are two Lua chunks that make up Mach. One chunk is contains the Gcode interpreter. If you run a Gcode job it is this chunk of Lua code that does the business
which includes running macros. The common macros in Gcode files are M01, M02,M03,M06 etc. If you write your own macro it might be M120 say, and the Gcode interpreter
would open and run that macro.
The GUI is the other chunk and it is responsible for the screen and all its functions like Homing buttons. Homing functions are initiated from the GUI and passed to the motion
controller. The controller reports back to the calling function in the GUI.
These two chunks of Lua code cannot run at the same time.
When Mach is running control passes back and forth between these two chunks. The mechanisms for doing it are vital to Mach and determine a lot of its 'character'.
A good deal of Mach programming involves having both Lua chunks running their own bits of code and they have to combine to do the job that you want and constitutes
perhaps the biggest challenge in successfully programming complex behavior in Mach.
The simple expedient is 'Have the GUI do GUI things and have the Gcode Interpreter do Gcode Interpreter things', trying to combine them or worse have then swap
roles is likely to be very difficult if not impossible.
Craig
-
Thanks Craig for the explanation! That seems to make sense. If I'm hearing you correctly it seems like trying to automate homing operations with Mach4 is maybe not a good idea in the first place.
Maybe you or someone out there would have some advice for me. I am using hardstop homing (no limit switches) and I written a routine that homes the machine and then checks to make sure all of the axes have been referenced. I would like for anyone running the machine to be able to home it without manually hitting the ref all home button. (This way no-one can accidentally hit the button when the machine has not actually been homed.) Maybe this is just not in the cards for Mach4, but I'd really appreciate any ideas anyone has.
Sorry if I'm beating a dead horse, but it sure would be nice to have something like a g28.1 work for Mach4.
David
-
Hi,
the last crash I had, and a goody, was because I forgot to reference the machine before I hit <cycle start>.
The particular work I was doing required repeated re-referencing and I got complacent after 4 hours or so...and whammo!
As a result I re-did the code behind the cycle start button which prevents me from hitting <cycle start>
UNTIL the machine has been referenced. Not hard to do.
Craig
-
Hi,
My three axis machine homes automatically without trouble. I've got into the habit of before hitting <RefAll>
reaching over to the machine and flicking the roller plunger microswitches (my home switches) while watching
the Machine Diagnostics page and confirm that Mach is 'seeing' the home switches.
Once it starts homing I have the pendant in hand with finger on the Estop. Because I have my home switches
set up to operate near the end of travel if a switch is for any reason ignored then the time to get to the Estop is
very limited. I often think that I should shift the home switches so that they operate with a couple of inches travel to spare.
They have not however led me to crash so they are still where I put them. There is no more permanent thing
than a temporary measure!
Craig
-
As a result I re-did the code behind the cycle start button which prevents me from hitting <cycle start>
UNTIL the machine has been referenced. Not hard to do.
Just in case any of you hadn't figured out how (it isn't hard - so long as coding is your thing!), Here's my code. Replace what's in the cycle start button, Left Up Script in the screen editor with the below:
local inst = mc.mcGetInstance()
local hXHome = mc.mcSignalGetHandle(inst, mc.OSIG_HOMED_X)
local hYHome = mc.mcSignalGetHandle(inst, mc.OSIG_HOMED_Y)
local hZHome = mc.mcSignalGetHandle(inst, mc.OSIG_HOMED_Z)
local XHomed = mc.mcSignalGetState(hXHome)
local XHomed = mc.mcSignalGetState(hYHome)
local ZHomed = mc.mcSignalGetState(hZHome)
if ((XHomed~=0) and (YHomed~=0) and (ZHomed~=0)) then
CycleStart()
else
wx.wxMessageBox("Please Reference All first!")
end
Obviously, if you have more or less Axis, you'll have to add or remove lines to reflect what you have.
I suspect this has saved me from some expensive mistakes!
-
You guys want a simple function added to the code that will reply if the machine is homed or not? mcCntlIsMachineHommed() or something like that ? that should be a nice simple one and we can look at the homing settings to see if all axis that can home have done so.
-
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
-
Steve and I made the surface map so you put them in and out on easy run :) Also I have not done it myself but Mach Motion has done kinematics in the filters (that is what we call the plugins that modify the path).
I get your issue. Let me see if I can find a way to kill the open file. The issue is I don think we have the Handle to it anymore. We may be able to save it to a register so we can find it if there is a glitch.
-
Hi Brian,
that's an interesting condundrum.
I'm guessing that a 'handle' as you refer to it is different to a file path. The file path is generated when the m401 is called
and would therefore present no problem to save the file path text in a register/registers.....but what about a handle?
The only handles I've seen are those that occur when I call mc.SignalGetHandle(...) or similar. The return, presumably the handle itself,
is just a number, and I've always assumed it relates to the location in memory that the data is stored.
I've never thought about an open file having a handle, that is some location in memory that the code related to the data stream to and from
the file. If my understanding is correct: how would you go about saving or otherwise recording that handle?. Is it even possible with the programming
tools within Mach to get the handle? I suppose the last question is the handle constant?. That is to say lets assume the probing routine (which is the program
that called into existance the file handle), does the handle survive the failure of the calling routine or does it get garbage collected imediately?
Craig
-
Yeah, I need to look at it from the Lua perspective. I work in C most of the time so trying to do the Lua thing is difficult !
You bring up a great point , we could save the position data into the string in the register! The register is really a WXString (when it holds text) it is and can hold a book worth of text. I need to start making a list !