Messages

4941

General Mach Discussion / Re: Control Panel

« on: March 21, 2018, 07:38:09 PM »

Hi,
if you use an external motion controller like  a UC300, an ESS or a 57CNC they have as many as 30 inputs
to which you can hook up buttons and switches.
The PoKeys 57CNC board also has the ability to accept analogue voltages that might result from a potentiometer say.

Craig

4942

Mach4 General Discussion / Re: How to set an active tool offset.

« on: March 21, 2018, 06:41:39 PM »

Hi,
this pretty much sums up what I know about it:

http://www.machsupport.com/forum/index.php/topic,36855.0.html

Could you use a signal and the testcount increment to determine when to run the script?

Craig

4943

Mach4 General Discussion / Re: How to setup Auto Zero button in latest version of Mach4

« on: March 21, 2018, 05:17:58 PM »

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

4944

Mach4 General Discussion / Re: How to setup Auto Zero button in latest version of Mach4

« on: March 21, 2018, 02:02:02 PM »

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

4945

Mach4 General Discussion / Re: How to setup Auto Zero button in latest version of Mach4

« on: March 21, 2018, 01:57:47 PM »

Hi,
there was something weird happening when I was posting the code and some extra symbols ended up in the post.


Remove '

Code: [Select]

' from the first line.

Craig

4946

Mach4 General Discussion / Re: How to setup Auto Zero button in latest version of Mach4

« on: March 21, 2018, 07:12:36 AM »

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

4947

Mach4 General Discussion / Re: How to setup Auto Zero button in latest version of Mach4

« on: March 21, 2018, 04:08:10 AM »

Hi,
on my laptop without a probe attached, maybe you can test it

Code: [Select]

[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]

4948

General Mach Discussion / Re: Servio motor Delta adas b2 Software and electronic gear ratio

« on: March 21, 2018, 03:57:50 AM »

Hi,
my apologies everyone, this is obviously posted it the wrong thread.

Craig

4949

General Mach Discussion / Re: Servio motor Delta adas b2 Software and electronic gear ratio

« on: March 21, 2018, 03:54:37 AM »

Hi,
I'm on my laptop so don't have a probe hooked up, maybe you can test it out.

Code: [Select]

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

4950

Mach4 General Discussion / Re: How to setup Auto Zero button in latest version of Mach4

« on: March 21, 2018, 03:08:57 AM »

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:

Code: [Select]

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.

Code: [Select]

--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!

Code: [Select]

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?

Code: [Select]

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.

Code: [Select]

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.

Code: [Select]

local zProbeStrikePos = 0;  --clear variable
As per above, this variable is created anew in a stack, no need to clear it.

Code: [Select]

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