Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: cv580 on March 18, 2018, 10:50:56 PM
-
How do I set up a Auto Zero button in the latest version of Mach4?
I have tried the scripts from previous posts on this forum, but they bring up errors when I try to run them so I assume something is different in the latest version of Mach4 that does not allow auto zero script to work from the older version. Any help on this would be greatly appreciated.
-
Hi,
no, more likely Mach is trying to home axes that have not been assigned or have home switches fitted and assigned.
Can you post a screen shot of the Home/Limits page and Motor Assignment page?
Craig
-
Craig,
There are no issues in the home/limits or motor assignment pages.
The errors I get are in the script editor when running the script and debugging the script. I got the script from a early post that was used on a early version of Mach4. The latest version of Mach won't even run the script
-
This is the script I am trying to make work
local mInst = 0; --Sets current controller instance to 0, if running multiple controller instances, this will need to change
local rc = 0; --Clear rc
local hSig = 0; --Clear hSig
local inst = mc.mcGetInstance(mInst); --Captures current instance of Mach 4
--SETUP OF VARIABLES
local probe = mc.ISIG_PROBE; --Set input here, mc.<INPUT_NAME>; input needs to be mapped in Mach4
local strikePlateThickness = 0.060; --What is the thickness of the strikeplate, or how much do you want to offset 0?
--Function to check to see if probe already grounded
function checkProbe ()
hSig, rc = mc.mcSignalGetHandle(inst, probe); --Load hReg with probe state
state = mc.mcSignalGetState(hSig); --Get Signal State
if (state == 1) then --if hReg true ('if probe is activated then')
return true
else
return false
end
end --checkProbe()
--BEGIN
--Get current Feed rate, G90/G91, G0/G1 states to return to later.
--Mach4 stores these variables as 'Pound Variables'
--See Mach4 Lua Scripting Manual Page 23
local CurrFeedRate = mc.mcCntlGetPoundVar(inst, 2134); --Gets current Feed Rate, #var 2134
local CurrFeedMode = mc.mcCntlGetPoundVar(inst, 4001); --Gets current G0/G1 state, #var 4001
local CurrPositionMode = mc.mcCntlGetPoundVar(inst, 4003); --Gets current G90/G91 state, #var 4003
local zProbeStrikePos = 0; --clear variable
if checkProbe() then --Check probe status
mc.mcCntlSetLastError(inst, "ERROR: Probe is already triggered. Cannot continue.");
do return end --"do return end" stops program. Not sure how this works
end --check if probe is grounded
mc.mcAxisSetPos(inst, 2, 0); --"Zero Z" (0 is x, 1 y, and so on)
mc.mcCntlGcodeExecuteWait(inst, 'G01 G90 G31 Z-4 F4'); --G31. Machine will stop on probe strike or go to Z-4, store in #var 5063
local zProbeStrikePos = mc.mcCntlGetPoundVar(inst, 5063); --Get Z strike position
local zAxisCurrentPos = mc.mcAxisGetPos(inst, 2); --Get Current Z position, sometimes the probe will continue past strike point.
local zAxisDifference = (zProbeStrikePos – ZaxisCurrentPos); --Gets overshoot, returns positive
local zAxisNewOffset = strikePlateThickness – zAxisDifference; --Subracts overshoot from known thickness of strikeplate
mc.mcAxisSetPos(inst, 2, zAxisNewOffset); --Sets DRO to current position
--mc.mcAxisSetMachinePos(inst, 2, zAxisNewOffset); --Sets Machine to offset if anyone finds this necessary
mc.mcCntlGcodeExecuteWait(inst, 'G00 G91 Z1'); --Rapid move to 1 inch above current pos
local isProbeSafe = checkProbe(); --Checks to see if probe is safe
if isProbeSafe == true then
wx.wxMessageBox("Probe is still activated! Check to make sure probe is not damaged or still contacting strike plate.");
else
mc.mcCntlSetLastError(inst, "Z Axis now referenced.");
end --if
-
Hi,
nice work but I don't think its going to work. When the controller detects a probe contact it will report back to Mach but it could take many milliseconds.
Mach then has to decide what to do and then instruct the controller, again with a delay of many milliseconds. The combined delay will mean most probably
that the probe gets crunched and certainly you will have NO accuracy.
How then does Mach probe, and probe accurately? You use a G31 command and the entire thing is handled by the motion controller which is near enough
to instantaneous.
Mach and Windows is not a realtime control system. It will respond to inputs in around 50ms, which is OK for buttons and on/off switches and things like that but anything
absolutely time critical it can't do. If the controller has been programmed to do whatever function is required all good, if not then you have to accept time delays
which usually wreck the function you are trying to perform.
Craig
-
Hi,
please hold up on my previous post, I see that you have used a G31 to get the critical data and so the delays I was talking about will not eventuate.
I apologise, I need to read a little more carefully.
craig
-
What do I need to do to make this work?
-
When you debug this in the editor using F5, then stepping through each line by using successive f11's, what line does it fail on?
-
Not able to use F5 as I get (Error While Running Chunk) right away, then the run session ends.
When trying to debug I get (At Breakpoint Line 1) then (Failed reading from debugger socket)
Also get the (Error While Running Chunk) in the message screen when loading Mach if this file is in the Macro folder
-
replace these two lines (41 and 42) by typing in directly. there appears to be a bad hidden character
local zAxisDifference = zProbeStrikePos -ZaxisCurrentPos
local zAxisNewOffset = strikePlateThickness - zAxisDifferemce
-
Replaced line 41 and 42 as per your post, made no difference, still getting the same errors
-
When you load mach it re-compiles all scripts and macros so if you have checkProbe() defined in any other file that contains an error mach will not compile correctly.
Move any files with the code you are trying to debug to a directory outside of your mach directory. Start mach. If you still get an error like the 'failure while running chunk something else is wrong. If not then:
From Operator->edit/debug scripts select any m???.mcs file. Then when in the editor select file->new. With notepad cut and paste the code into this new file and hit F7. Now you should get where the offending line of code is.
HTH
RT
-
RT
Moved the script file to another directory as you suggested, opened the file with the edit/debug, F7 just gave me a output directory nothing else, tried F5 and managed to crash Lua and ended up with a whole bunch of error screens in the process. Thanks for your time trying to help me out with this.
I don't think I will waste anymore time trying to make this work, I know other people have tried to make a auto zero button in Mach4 but had no success either, appears to be too much flaky script that seems impossible for the non programmer type (like myself) to understand fully to make it work. The machine has been down for almost 4 weeks now trying to get it to do all the same things with Mach4 that it was doing before with Mach3.
-
Hi cv580,
if you don't mind me saying it seems that there is a lot of code in your script with every line a potential fault.
Would you be offended if I cut it down to size and got it to work? I think I could make it much simpler, it may
lose some of its elegance but 'working' beats 'elegant but broken' everytime!
Craig
-
Craig
I would not be offended at all if you cut it down and get it to work! Any help you can provide would be most appreciated.
cv580
-
Just curious, have you tried the touch button in the wx4 or wx6 screen sets? You can use the TouchOff module to auto zero X Y or Z independently using a touch plate or probe. Find circle, square, rectangle centers, X,Y and Z simultaneously using corners, set Z zero to top or bottom of material, angle of material (G68). No programming required.
https://www.youtube.com/watch?v=VA49atQNzmg
-
I have looked at the touch button option, it is not user friendly for a touch screen monitor as the touch/probe page always need to be resized (enlarged) with a mouse to access the Z axis touch button which is hidden until the page is resized.
Is there a way to bring this button or make a button for the z touch to put onto the program run screen?
I have tried to find z touch button with screen editor but no luck.
Or is there a way to have the touch/probe screen permanently full size when using the touch button instead of having to resize it every time when using the touch button feature?
No mouse or keyboard on my machine just touch screen monitor
-
Hi,
you don't want to use the Touch Off module because the buttons aren't big enough? All the hard work has been done but for the lack of a mouse or track ball
you'd ditch it????
Anyway:
local mInst = 0; --Sets current controller instance to 0, if running multiple controller instances, this will need to change
local rc = 0; --Clear rc
local hSig = 0; --Clear hSig
You don't need to reset these, they are created anew each time it runs and they are garbage collected once they go out of scope. Redundant. Lua uses a stack for local
variables not a fixed memory location.
--SETUP OF VARIABLES
local probe = mc.ISIG_PROBE; --Set input here, mc.<INPUT_NAME>; input needs to be mapped in Mach4
local strikePlateThickness = 0.060; --What is the thickness of the strikeplate, or how much do you want to offset 0?
Why bother, you're just getting cute, there is nothing wrong with mc.ISIG_PROBE There might be a case for a strike plate thickness variable. I'm not going to bother,
I want to get this code down short and sweet, if you want to come back later and pretty it up OK but in the first instance get it to go!
function checkProbe ()
hSig, rc = mc.mcSignalGetHandle(inst, probe); --Load hReg with probe state
state = mc.mcSignalGetState(hSig); --Get Signal State
if (state == 1) then --if hReg true ('if probe is activated then')
return true
else
return false
end
end --checkProbe()
Do you really need a separate function to do this...it means a new local stack and context switch overhead and you use it only twice in the whole script.
I can write it in one line so why bother complicating this thing?
return false
This is I suspect will result in a syntax error, 'false' may have meaning in C or C++ but in Lua 0 means false any other number like 1 means true.
local CurrFeedRate = mc.mcCntlGetPoundVar(inst, 2134); --Gets current Feed Rate, #var 2134
local CurrFeedMode = mc.mcCntlGetPoundVar(inst, 4001); --Gets current G0/G1 state, #var 4001
local CurrPositionMode = mc.mcCntlGetPoundVar(inst, 4003); --Gets current G90/G91 state, #var 4003
local zProbeStrikePos = 0; --clear variable
Whats the point of these, you are collecting and storing this info but nowhere later in the script is it being used. Meanwhile you risk syntax/logic errors and for no
gain. Redundant.
local zProbeStrikePos = 0; --clear variable
As per above, this variable is created anew in a stack, no need to clear it.
local zAxisCurrentPos = mc.mcAxisGetPos(inst, 2); --Get Current Z position, sometimes the probe will continue past strike point.
local zAxisDifference = (zProbeStrikePos – ZaxisCurrentPos); --Gets overshoot, returns positive
local zAxisNewOffset = strikePlateThickness – zAxisDifference; --Subracts overshoot from known thickness of strikeplat
I use a solid probe when making circuit boards. If there was any significant overrun at the probe event I would know and yet there is not. Do you have any
evidence that allowing for overrun is actually required? I'm not going to bother because I know from personal experience that its not required. Save the extra
coding and the syntax/logic errors that could creep in and upset what should be simple code.
I have some code written and am testing it out. I can't test it on my machine so it may be a bit ragged. Will post when complete.
Craig
-
Hi,
on my laptop without a probe attached, maybe you can test it
[code]function autozero()
local inst = mc.mcGetInstance()
local probeHand, rc = mc.mcSignalGetHandle(inst,mc.ISIG_PROBE)
local probeState=mc.mcSignalGetState(probeHand)
if probeState==1 then
wx.wxMessageBox('Probe already active...cannot proceed')
return
end
mc.mcCntlGcodeExecuteWait(inst, 'G01 G90 G31 Z-4 F40');
local zProbeStrikePos = mc.mcCntlGetPoundVar(inst, 5063);
mc.mcAxisSetPos(inst, 2, 0.060);
mc.mcCntlGcodeExecuteWait(inst, 'G00 G91 Z1'); --Rapid move to 1 inch above current pos
probeState=mc.mcSignalGetState(probeHand)
if probeState == 1 then
wx.wxMessageBox("Probe is still activated! Check to make sure probe is not damaged or still contacting strike plate.");
else
mc.mcCntlSetLastError(inst, "Z Axis now referenced.");
end
end
if mc.mcInEditor()==1 then
autozero()
end
Couple of things I should point out. You see I have written this as a function and looks very much like a macro. I do this when I'm writing new code so I can put
it in a separate folder within my profile and I can run it with the debugger in the editor. Having it in a separate file means I don't pollute my macro folder with
buggy code. Once I've manually stepped through it and run a few tests then I will put in into its final location.
Here again I follow a somewhat iidiosyncratic policy of putting the function in the screen load script, usually near the top. Then I will put a function call on the button, not
the script itself. It means that when I go to find the script and edit it or have to delete it because its that buggy I can find it easily. If I were to attach the script
direct to the button the script will be buried in the screen script somewhere....I find it so much more convenient to put it at the top of the screen load script.
If it works out really well by all means put it direct on the button. This script is for my purposes only temporary to help you out so when we're done with it I'll delete
it knowing exactly where it will be.
Let us know if it works...
Craig[/code]
-
Hi,
I see an error, when I was testing I upped the probe feed speed to 40, my installation has native units of mm so I had to increase the speed or
be there all night waiting for it to complete.
You'll need to edit it back to F4.
Craig
-
Craig
I am not able to get the code to work, in the debugger I get the following error message:
Compilation error on line number: 1
Lua: Syntax error during pre-compilation
:1: unexpected symbol near '['
cv580
-
Hi,
there was something weird happening when I was posting the code and some extra symbols ended up in the post.
Remove '' from the first line.
Craig
-
Hi,
even typing out the offending symbol screws with the posting.....
On the very first line remove the word 'code' and the square brackets that enclose it. It ended up there because I did something screwy when posting the code.
Craig
-
Craig,
I have the code working in the debugger now, so I put code file into the macros folder in my Mach4 profile and tried linking a button to it but not having any success making that happen (trying the left up and left down thing in screen editor).
What do I have to do to link a button to the code file?
cv580
-
Hi,
no its no good in the macros folder.
To put in the screen script strip off the bottom few lines:
if mc.mcInEditor==1 then
autozero()
end
These lines were just to get the debugger to run properly. As I say strip them off and place the remaining
code in the screen load script...where is your choice I prefer to put functions like this just before the signal
library.
Now as left-up script of your button put autozero(). Thus when you hit the button it will call the function autozero()
which happens to be in your screen load script and therefore available across Machs GUI.
Craig
-
Craig,
I have everything working now, but after the Z axis has retracted from the tool plate I am not able to move any axis to work zero and get a message in Mach saying:
"Cannot use G53 incremental"
I do not see G53 being implemented in the code.
Do I need to add a line to the code to cancel G53 at the end?
cv580
-
cv580,
Somewhere along the line you have used a "G91"
This puts Mach in incremental mode.
You need to be in Absolute Mode ... "G90"
-
I Just looked at Craig's code. The last modal call for Absolute/Increment is Increment. It is the move after the Probe move.
"mc.mcCntlGcodeExecuteWait(inst, 'G00 G91 Z1'); --Rapid move to 1 inch above current pos"
In the code you need to have it change back to absolute mode.
Just put this line after the G91 line.
mc.mcCntlGcodeExecute(inst, "G90")
-
Hi,
kool missed that, I actually just copied and pasted that part from OPs original code.
All I've really done is strip out the extraneous stuff and roll it into a function which can be debugged.
Craig
-
Hi,
point is that you now have some code which works. You can now apply various ideas that may make it better.
I would recommend that any edits be made in the remote function so you can step thru with the debugger.
Only when you are happy with it incorperate those changes or overwrite the code in the screen load script.
The idea being to keep potential buggy code from ending up in the LuaScript.
Craig
-
I agree with Craig,
Keep it out of the screen load until a final revision is made.
I like the stripped down code. I appreciate the thought to put the TLO addition in the Touch Module. But I wish it were on the home screen or in the offsets screen as a stand alone button. I went through and did this same thing with the TLO code. I didn't like having to open up the module and be sure that TLO is selected, then push the probe button.
-
Adding the line of code that Chad recommended does not work properly, it will work once after the first touch off and the next touch offs I will get the "Cannot use G53 incremental" message in Mach and not able to move any axis to work zero
cv580
-
cv580,
What are you doing to move to work zero? The button on the main screen under the Position Dros?
-
cv580,
I had some issues when I first used the TouchOffset Module.
I wonder if something is up with this code as well. Is this code working back to back?
-
Chad,
I am using the Go To Work Zero button under the DRO's on the main screen to move the axis to work zero. I am not sure what you mean by the code working back to back?
What is happening is I do a auto zero touch off and after the Z axis has retracted from the touch plate I use the Go To Work Zero button to bring all axis to work zero which will work once, then I do another auto zero touch off and now I am not able to bring any of the axis back to work zero and get the "Cannot use G53 incremental" message.
I jog the X and Y axis off to one side to do the tool change and auto zero the Z axis thus the need to bring the machine back to work zero after the touch off.
cv580
-
Hi,
can you go to the edit screen and capture and post the code associated with the Go To Work Zero button?
I've encountered a fault like this before and struggling to remember what it was. I seem to recall its in the Go To Work
Zero script.
Craig
-
Craig,
The Go to Work Zero script:
function GoToWorkZero()
--mc.mcCntlMdiExecute(inst, "G00 X0 Y0 A0")--Without Z moves
mc.mcCntlMdiExecute(inst, "G00 G53 Z0\nG00 X0 Y0 A0\nG00 Z0")--With Z moves
end
The Go to Work Zero button:
GoToWorkZero()
--local inst = mc.mcGetInstance()
--mc.mcCntlMdiExecute(inst, "G00 G53 Z0\nG00 X0 Y0 A0\nG00 Z0")
cv580
-
Hi,
they look like the standard issue.
may I suggest putting an mc.mcCntlGcodeExecuteWait(inst,'G90') just prior. It will guard against be in incremental mode when doing Go To Work Zero.
Craig
-
That was going to be my next suggestion.
Craig, you mentioned you had this type of fault before. Was it with the WorkZero Function, or the Probe?
-
Works 100% now!
Many Thanks for your help and patience Craig and Chad
cv580