Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: aaronky on May 24, 2019, 05:48:30 PM
-
im trying to write a macro that offsets my tools based on the offset of my work to my toolsetter. I can do this manually by setting the offset of the tool setter in the drogageblockt. using the tool setter essentially like a gage block. I see where the button writes to a register. when I try and read that register in the macro it always returns a 0 no matter what number is in that field. I'm sure im reading the register wrong. or that may not even be the correct way to do it.
if I try and just read the dro it returns a string value and throws a compile error.
-
Hi,
what is the register?
How are you trying to read the DRO?
Craig
-
i started out trying to get the register. by looking in the manual and came up with this
local hreg = mc.mcRegGetHandle(inst, string.format("droGageBlockT"))
i belive this is the point is was giving me errors about it returning a string instead of a value so i tried somthing else.
scr.GetProperty("droGageBlockT", "Value") is how i finally was able to get a value. but this line will cause my code to not execute. As well as the math line below. i commented it out as well. if i leave those 2 lines out the code runs fine. but if i uncomment them, all the values come back correctly in the script editor but if i try and do a m6 toolchange it wont do anything at all.
function m6()
local inst = mc.mcGetInstance()
local posmode = mc.mcCntlGetPoundVar(inst, mc.SV_MOD_GROUP_3) --get the current mode so we can return to it when macro ends
local selectedtool = mc.mcToolGetSelected(inst)
local currenttool = mc.mcToolGetCurrent(inst)
local xstart = mc.mcAxisGetPos(inst, 0) --X Axis--
local ystart = mc.mcAxisGetPos(inst, 1) --Y Axis--
*local tsoffset = scr.GetProperty("droGageBlockT", "Value") --Get Value of tool setting gage block--height offset of tool setter and material top--
if selectedtool == currenttool then
mc.mcCntlSetLastError(inst, "No Tool Changed Required")
else
mc.mcCntlGcodeExecuteWait(inst, "G53 G0 Z-0.2\nG53 G0 X10.0 Y-46.0857")--Move the Z to Home.Then to the X, Y Coords for our tool change.
mc.mcCntlSetLastError(inst, "Current tool == " .. tostring(selectedtool) .. " Previous Tool == " .. tostring(currenttool)) --Specify which tools changed--
wx.wxMessageBox("Remove Dust Boot and Change Tool \nThen Press Ok")
mc.mcCntlGcodeExecuteWait(inst, "G53 G0 X0.6831 ") --Move to Tool Setter position--
local MyChoice = wx.wxMessageBox("Click Ok to Begin Probing the New Tool","Click OK to continue")
mc.mcToolSetCurrent(inst, selectedtool) --change selected tool to current
mc.mcCntlSetLastError(inst, "Probing in Progress!")
mc.mcCntlGcodeExecuteWait(inst, " G91 G31 Z-5. F10.")--probe the new tool
local probedz = mc.mcCntlGetPoundVar(inst, mc.SV_PROBE_POS_Z) -- Z Probe position in Machine coords
mc.mcCntlGcodeExecute(inst, string.format('G ' .. posmode))--return to pre macro mode G90, or G91
mc.mcCntlGcodeExecuteWait(inst, "G00 G53 Z-0.2")--Retract
local NewOffset = probedz --math.abs(probedz - tsoffset)--
mc.mcToolSetData(inst, mc.MTOOL_MILL_HEIGHT, selectedtool, NewOffset)
mc.mcCntlSetLastError(inst, string.format("Auto tool setting complete, Offset = %.4f", NewOffset))
mc.mcCntlGcodeExecuteWait(inst,"G53 G0 X10")
wx.wxMessageBox("Toolchange Complete.\nReplace dust boot")
mc.mcCntlGcodeExecuteWait(inst, "G90 G0 X"..xstart.."Y"..ystart)
end
end
if (mc.mcInEditor() == 1) then
m6()
end
-
this is what i get when i try to do a t2 m6 with those 2 lines enabled. but the machine does no movement at all. if im in the scipt editor it runs fine....
2016-06-18 23:11:52.814 - Logging Enabled.
2016-06-18 23:11:57.714 - API: mcCntlMdiExecute(inst = 0, commands = 't2 m6') (Mach4GUI)
2016-06-18 23:11:57.817 - Attempt transition from "Idle" on event "MDI Start" controller.cpp:2187
2016-06-18 23:11:57.817 - S_IDLE_on_exit
2016-06-18 23:11:57.817 - ACTION_start_mdi
2016-06-18 23:11:57.818 - S_MDI_RUNNING_on_entry
2016-06-18 23:11:57.818 - S_MDI_RUNNING2_on_entry
2016-06-18 23:11:57.821 - Signal id 1114, (Gcode Running), changed from LOW to HIGH.
2016-06-18 23:11:57.851 - Signal id 1121, (Tool Change), changed from LOW to HIGH.
2016-06-18 23:11:57.859 - >>>>> ESS received a Tool Change Required notification.
2016-06-18 23:11:57.863 - Signal id 1121, (Tool Change), changed from HIGH to LOW.
2016-06-18 23:11:57.884 - >>>>> ESS received a Tool Change Done notification.
2016-06-18 23:11:57.884 - >>>>> ESS received a Tool Change Done notification.
2016-06-18 23:11:57.984 - Attempt transition from "MDI Running" on event "Stop" gcodeexec.cpp:1232
2016-06-18 23:11:57.984 - S_MDI_RUNNING2_on_exit
2016-06-18 23:11:57.984 - Signal id 1114, (Gcode Running), changed from HIGH to LOW.
2016-06-18 23:11:57.985 - S_MDI_RUNNING_on_exit
2016-06-18 23:11:57.985 - ACTION_stop
2016-06-18 23:11:58.111 - S_IDLE_on_entry
-
Hi,
you have a few things going on there.
First lets deal with:
local hreg = mc.mcRegGetHandle(inst, string.format("droGageBlockT"))
I don't know where you got this from but its wrong.
To get the handle of a register you must supply a string that has the path to the register. Even if there is a register
called 'droGageBlockT', and if there is I cant find it but its certainly not a correct path to it.
I have in my installation a register called:
workZMax
and it is in the instance register tree and this is how I would get the register handle for it:
local RegHandle=mc.mcRegGetHandle(inst,"iReg0/workZMax")
So to access a register you must specify both its name and path EXACTLY or the API will fail. The path to a register is
reminiscent of the path to a file on a Windows PC and 'droGageBlockT' is not such an example.
'core/ droGageBlockT' or 'ESS/'droGageBlockT' or 'iRegs0/ droGageBlockT' at least have the right format for the path string.
As I say....I could not find any mention of a register called 'droGageBlockT' anywhere in the Regfile Diagnostics tree and
am not surprised that you cant fing a handle for it.
Craig
-
Thank you for clarifying the way registers work. I've read the scripting manual over a few times this week. I'm still a novice but ive gained a much better understanding of how this all works. I'm going to give that a go and see how it works. Was that the only thing you saw wrong with the script? does everything else seem to be ok to you?
-
Hi,
there is second issue going on.
Mach4 has two chunks of code, the GUI chunk and the Gcode interpreter chunk. Only one chunk can run at a time.
The data and code of one chunk is not available to the other. In the parlance......a variable in the GUI chunk
is 'out of scope' to the Gcode interpreter chunk and vice versa.
The variable 'droGageBlockT' is variable that is defined in the GUI chunk. When you run your macro from the Gcode editor
which is in the GUI chunk the variable 'droGageBlockT' is in scope. However when you run the macro the Gcode interpreter
is active and the GUI chunk and all its variables are out of scope.
That is the explanation as to why it will run from within the script editor but not when running as a macro.
Learning how and when each chunk runs in Mach is one of the steep learning curves of Mach.
In this case because you are using a .scr call it is by no means plain to me that .scr calls have return codes as do the .mc
API calls.
I would advocate that you should use a return code test to determine success or otherwise of an API call, it will in particular
catch those situations where you have inadvertently called a variable or function that is out of scope. Given that I'm not sure
that .scr calls even have return codes I cant recommend that technique.
What you/I/we need to do is find the register (if there is one) or more likely the pound variable that contains the current DRO
value and use that instead. Registers are the only means of transferring data from one chunk to another. Registers and
pound variables are truly global whereas 'droGageBlockT' is 'global' ONLY within the GUI chunk.
Craig
-
thank you very much for that. That explains a lot. When I used mach3 for several years I never dug this deep into anything with it. I used to setup off a piece of paper and ran with it. now im trying to limit setup and run time by automating what I can. its proven to be a challenge that's for sure. Would it be easier if I setup a custom DRO, say in the offsets screen. That's where I would input the offset of the tool setter and the top of the work surface. Create a register for it, and reference that? would that be a better solution?
The reason I was searching for the register that I never found for the drogageblockt, is because of the button code. that's also where I got the scr line that I put into the macro.
local inst = mc.mcGetInstance()
local val = scr.GetProperty("droGageBlockT", "Value")
mc.mcProfileWriteString(inst, "PersistentDROs", "droGageBlockT", string.format (val)) --Create a register and write to it
-
Hi,
I have gone and looked again through all the named registers in the Regfile Diagnostic tree and there is no such
'droGageBlockT'.
It must therefore be a pound variable.
I have posted some lists of known pound variables and Enums and other uselful lists here:
https://www.machsupport.com/forum/index.php?topic=40051.0 (https://www.machsupport.com/forum/index.php?topic=40051.0)
But nowhere in the pound variable lists is there a listing for the GageHeightDRO.
There are two ways to proceed, one is to ask smurph or Daz or Chaticone or someone who may know.
The other is to do some detective work and maybe like Holmes deduce the answer. Are you up for a challenge?
My suggestion is to deliberately write some unusual number into the DRO like 1.414213562, being the square root of 2,
(obviously!!!LOL) and then running a script to search through all the thousands of pound variables until we find one that
has that number stored in it. I am assuming that the number is unique....so there is the possibility of getting it wrong.
On the other hand if we do find a pound variable with this number in it then there is a good chance that we have deduced
which pound variable its is.
Does this sound feasible?
Craig
-
Hi,
well I tried my search scheme and it didn't work.
This is the macro I wrote:
function m190()
local inst=mc.mcGetInstance()
for i=1,10000,1 do
local data=mc.mcCntlGetPoundVar(inst,i)
local match=math.abs(data-1.4142)
if (match<0.001)then
local poundVariable=tostring(i)
wx.wxMessageBox("PoundVariable is"..poundVariable)
end
end
end
if (mc.mcInEditor()==1)then
m190()
end
I entered 1.4142 into the GageBlock DRO but got no match. Just to test that my search macro was working I entered the same
number into the Z and Y DROs and the match was signaled.
I can only guess that the GageBlock DRO is not stored as a pound variable.
I think it high time I listened to wiser heads like smurph, Daz et al.
Craig
-
absolutely, im up for any solution you have. although in the meantime I have gone and created a new instance register.I can change it to global if that's better. I was just kind of messing around here trying different thing. ive done this all on a pc with a demo running so I don't screw the one running the machine up anymore than I have already lol. I also changed the code of the drogageblockt code to the script im posting below. running the register diagnostic, the register changes then I input a number in the drogageblockt DRO.
could I now reference that register in my macro(I hadn't made it this far yet) and use it this way? or will it give me the same trouble I had before.
local inst = mc.mcGetInstance()
local val = scr.GetProperty("droGageBlockT", "Value") this line was already present
local hreg = mc.mcRegGetHandle(inst, "iRegs0/TSoffset") --added this line
mc.mcProfileWriteString(inst, "PersistentDROs", "droGageBlockT", string.format (val))
mc.mcRegSetValueString(hreg, tostring(val)) --added this line.
-
ive made it this far and its returning the numbers as it should. again this is in the script editor so who knows if it will actually work on the machine. if you see any issues please don't hesitate to point them out.
function m6()
local inst = mc.mcGetInstance()
local posmode = mc.mcCntlGetPoundVar(inst, mc.SV_MOD_GROUP_3) --get the current mode so we can return to it when macro ends
local selectedtool = 1 --mc.mcToolGetSelected(inst)
local currenttool = 2 --mc.mcToolGetCurrent(inst)
local xstart = mc.mcAxisGetPos(inst, 0) --X Axis--
local ystart = mc.mcAxisGetPos(inst, 1) --Y Axis--
local hreg = mc.mcRegGetHandle(inst, "iRegs0/TSoffset")
local val = mc.mcRegGetValueString(hreg)
local tsoffset = tonumber(val)
-
This is what I came up with. It is working in the editor. Well see in the morning if it will run on the machine. I would like to add a little more on the math end though dealing with negative numbers. Well see how it does on the machine and go from there. I changed a few things to make it easier to change variables if I need to as well. again, if anyone sees any issues, or has some advice on what I could do to improve it. Don't hesitate to post.
function m6()
local inst = mc.mcGetInstance()
local posmode = mc.mcCntlGetPoundVar(inst, mc.SV_MOD_GROUP_3) --get the current mode so we can return to it when macro ends
local selectedtool = 1 --mc.mcToolGetSelected(inst)
local currenttool = 2 --mc.mcToolGetCurrent(inst)
local xstart = mc.mcAxisGetPos(inst, 0) --X Axis--
local ystart = mc.mcAxisGetPos(inst, 1) --Y Axis--
local xchangepos = 12
local ychangepos = -46.0857
local xprobepos = .6831
local yprobepos = -46.0857
local reg = mc.mcRegGetHandle(inst, "iRegs0/TSoffset") --Get register handle
local regval = mc.mcRegGetValueString(reg) --Get the string
local tsoffset = tonumber(regval) --The value set in the Tool Offset Gage Block Height
if selectedtool == currenttool then
mc.mcCntlSetLastError(inst, "No Tool Changed Required")
else
mc.mcCntlGcodeExecuteWait(inst, "G53 G0 Z-0.2\nG53 G0 X"..xchangepos.." Y"..ychangepos.."") --Move the Z to Home.Then to the X, Y Coords for our tool change.
mc.mcCntlSetLastError(inst, "Current tool == " .. tostring(selectedtool) .. " Previous Tool == " .. tostring(currenttool)) --Specify which tools changed--
wx.wxMessageBox("Remove Dust Boot and Change Tool \nThen Press Ok")
mc.mcCntlGcodeExecuteWait(inst, "G53 G0 X"..xprobepos.."Y"..yprobepos.."") --Move to Tool Setter position--
wx.wxMessageBox("Click Ok to Begin Probing the New Tool","Click OK to continue")
mc.mcToolSetCurrent(inst, selectedtool) --change selected tool to current
mc.mcCntlSetLastError(inst, "Probing in Progress!")
mc.mcCntlGcodeExecuteWait(inst, " G91 G31 Z-5. F10.")--probe the new tool
local ProbedZ = mc.mcCntlGetPoundVar(inst, mc.SV_PROBE_POS_Z) -- Z Probe position in Machine coords
mc.mcCntlGcodeExecute(inst, string.format('G ' .. posmode))--return to pre macro mode G90, or G91
mc.mcCntlGcodeExecuteWait(inst, "G00 G53 Z-0.2")--Retract
local NewOffset = math.abs(ProbedZ - tsoffset)
mc.mcToolSetData(inst, mc.MTOOL_MILL_HEIGHT, selectedtool, NewOffset)
mc.mcCntlSetLastError(inst, string.format("Auto tool setting complete, Offset = %.4f", NewOffset))
mc.mcCntlGcodeExecuteWait(inst,"G53 G0 X"..xchangepos.."")
wx.wxMessageBox("Toolchange Complete.\nReplace dust boot")
mc.mcCntlGcodeExecuteWait(inst, "G90 G0 X"..xstart.."Y"..ystart)
end
end
if (mc.mcInEditor() == 1) then
m6()
end
-
--To my understanding your trying to use these two Probing Screens Dro's
--Make sure you have created registers GageBlock and GageBlockT before you can write and read them.
local GageBlock = scr.GetProperty("droGageBlock", "Value")
local GageBlockT = scr.GetProperty("droGageBlockT", "Value")
WriteReg('iRegs0/GageBlock',tonumber(GageBlock));
WriteReg('iRegs0/GageBlockT',tonumber(GageBlockT));
--Never tried to share the same named variable but worth a test
--if not just change them. (more of a scripting timing and use issue id expect)
--Just have to make sure any changes to the Dro's get reread and rewritten to the registers
--I do remember if you try to read the registers to soon after writing to them they are not available.
--so a dwell might need to be used if in the same script
--But in most cases registers are updated in the PLC or button script and then used in the M code.
local GageBlock = ReadReg("iRegs0/GageBlock");
local GageBlockT = ReadReg("iRegs0/GageBlockT");
-
Thanks you both for your lending your knowledge. The only time I want to write to the register is when I input a new number into the tool offset gage block height DRO manually.
-so I can measure the top of my stock with my touch probe.
-zero my z for my work offset
-move over to the tool setter position
-probe it to get the offset in height of the material top and the tool setter top.
-input that number into the droGageBlockT location, have that write to the register to be used in the m6 macro.
-then proceed with an m6 to change to the first tool I want to use.
-the m6 will then read that droGageBlockT and use it to set my tool offset
If that makes any sense at all. I have no way to change tools repeatably on my router. So I cant setup a normal tool table like I'm used to. This was the only solution I could come up with to automate changing tools and setting their offsets mid program without jogging around and manually zeroing with each tool change.
when I tested this manually all the math came out correct and my tool heights were set correctly. I guess that doesn't mean it will work when I try and automate it.
I just created the registers on my machines PC. Loaded the new m6 macro to it. I'm going to give it a go. The script worked in the editor again, but my last one did as well and failed when an m6 was called. which joe explained very well as to why that happened.
-
ok so now the code runs perfectly fine. But all the offsets are wrong. Its driving me crazy lol. I thought I could reference the same thing as the "touch" function when setting TLO. If I input my "tool setter height" in the touch function the same as I do in the "gage block dro" on the offsets tab. the touch function sets my offsets correctly. I run the M6 and its not even close…
-
Hi,
I experimented a little on my laptop along the lines of your proposal and I had a similar problem.
I haven't really sorted out why.
What I found was that just because I entered a new number into the DRO that did not necessarily translate into the update
of the iRegs0 register that I was using as a relay.
I altered the code of the 'On Update' event script to copy the data from the DRO to the destination register. The data WOULD
be copied, I found, if I hit the <Set Z> or <Set Tool> button. I concluded therefore that the 'On Update' script runs
reliably ONLY AFTER one of the two buttons is pressed.
The only way I can see to overcome this problem is to put some code into the the PLC script that copies the data from the
DRO to the register. I am loathe to do so because of the software overhead that represents but there may not be much choice.
The second question remains, lets say we did bite the bullet and put code in the PLC script to keep the register updated,
or as I call it 'in lockstep' with the DRO.....does that code run during Gcode interpreter sessions. It would really only make sense
that the PLC script should run irrespective of which chunk (GUI or Mach core) is in control. This is the true measure of my
ignorance of how Mach4 works, but the truth is I don't know whether that is the case or not.
In some respects while I endeavor to help others by contributing on the forum, I in fact have to learn about Mach and I do so
by others posing questions that I never thought to ask. Thus its contributing to the forum that aids my learning curve.
Craig
-
Hi,
I wrote some code to put in the PLC script. It seems to work, that is to say that if you type in a new number
into the droGageBlockT and <enter> the PLC chunk will in very short order, within milliseconds, update the iRegs0/droRelay
register. As the PLC script runs multiple times per second, 20 times per second by default, the register should always reflect
the value of the DRO.
--Cause iRegs0/workZMax register to be updated by GageBlockDRO
local inst=mc.mcGetInstance()
local hreg=mc.mcRegGetHandle(inst,"iRegs0/droRelay")
local val = scr.GetProperty("droGageBlockT", "Value")
mc.mcRegSetValue(hreg,tonumber(val))
--End of chunk
The question still remains...'will this short chunk maintain the updates when the Gcode Interpreter chunk is in control?'
Try it out and let us now.
Craig
-
Mine seems to update the register when I input a new number and just press enter. Pretty reliably. I will still use your code to have the reassurance I don't need to check it every time I do change the value. I applicate the time you've spent helping me resolve these issues too. I've learned quite a bit, not only about the lua end of mach, but just the way everything operates in general.
The last issue that is haunting me are these damn offsets.
-If i turn on the machine.
-home it.
-go to my workpiece, zero my g54 z. im not really concerned about x and y until i sort these offsets out.
-go to the tool setter position.
-probe it for height. its about .775 above my work z currently.
-set that value in both the "touch plate height" in the touch menu, and the tool offset gage height(which is where our register is referencing)
-use the tool setter to set the touch probe height with the "touch" function. it writes 0 into TLO
-then i call a m6 t2 from mdi
-it runs though the m6 function as it should
-but my offsets are way off.
now if i do the same process starting over. then change to tool 2 manually and probe it with the "touch" function as well, it sets my offset correctly. The only math i need the m6 macro to do is subtract my "droGageBlockT" value from the z probe position. I have tried a couple different expressions to get it to return the correct number. Im doing something wrong it seems like. I went into the script for the "touch" function. It seems to do no more than what im trying to achieve with mine. subtracting the "touch plate height" from the z position. which in this case the touch plate height is the same as our gage block height register. what am i doing wrong here. I'll reference below the touch script im referring to.
function TouchOffZNeg1() --Set tool length offset
GetPreState()
local CurTool = mc.mcToolGetCurrent(inst) --Current Tool Num
if (CurTool > 0) and (CurTool < 255) then
GetMachPos('Z')
TouchOff('Z', -1) -- Do a touch move in the X negative direction
local ZPos = mc.mcAxisGetProbePos(inst, mc.Z_AXIS, 0)
ToMachPos('Z')
local GageBlock = ToffPlate
local OffsetVal = ZPos - GageBlock
OffsetState = mc.mcCntlGetPoundVar(inst, mc.SV_MOD_GROUP_8) --Current Height Offset State
mc.mcCntlGcodeExecuteWait(inst, "G49")
mc.mcToolSetData(inst, mc.MTOOL_MILL_HEIGHT, CurTool, OffsetVal)
mc.mcCntlSetLastError(inst, string.format("Tool %.0f Height Offset Set: %.4f", CurTool, OffsetVal))
if (OffsetState ~= 49) then
mc.mcCntlMdiExecute(inst, string.format("G%.1f", OffsetState))
end
else
mc.mcCntlSetLastError(inst, ('Cannot set a height for an invalid tool number. Call a valid tool and try again.'))
end
mc.mcCntlGcodeExecute(inst, string.format('G ' .. m_CurAbsMode .. '\nF ' .. m_CurFeed)) --Set mode and feed back
end
-
id start with mc.mcCntlSetLastError print out of each variable in the script then look at the history to see what is not correct.
but I suspect as id mentioned before its a timing issue and a sleep of a few seconds (maybe 3) needs to be used then look at the variables again in the same script. As it takes a little time for all the registers to update.