Hello Guest it is November 18, 2019, 02:28:29 PM

Author Topic: Read droGageBlockT  (Read 362 times)

0 Members and 1 Guest are viewing this topic.

Read droGageBlockT
« 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. 
Re: Read droGageBlockT
« Reply #1 on: May 24, 2019, 05:56:34 PM »
what is the register?

How are you trying to read the DRO?

My wife left with my best friend...
     and I miss him!
Re: Read droGageBlockT
« Reply #2 on: May 24, 2019, 08:35:58 PM »
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")
      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)


if (mc.mcInEditor() == 1) then
Re: Read droGageBlockT
« Reply #3 on: May 24, 2019, 09:15:45 PM »
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
Re: Read droGageBlockT
« Reply #4 on: May 24, 2019, 11:49:42 PM »
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:
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.


My wife left with my best friend...
     and I miss him!
Re: Read droGageBlockT
« Reply #5 on: May 25, 2019, 12:03:46 AM »
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?
Re: Read droGageBlockT
« Reply #6 on: May 25, 2019, 12:11:19 AM »
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.

My wife left with my best friend...
     and I miss him!
Re: Read droGageBlockT
« Reply #7 on: May 25, 2019, 12:35:01 AM »
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
Re: Read droGageBlockT
« Reply #8 on: May 25, 2019, 01:20:15 AM »
I have gone and looked again through all the named registers in the Regfile Diagnostic tree and there is no such

It must therefore be a pound variable.
I have posted some lists of known pound variables and Enums and other uselful lists here:


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?

My wife left with my best friend...
     and I miss him!
Re: Read droGageBlockT
« Reply #9 on: May 25, 2019, 02:06:24 AM »
well I tried my search scheme and it didn't work.

This is the macro I wrote:
Code: [Select]
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)

if (mc.mcInEditor()==1)then

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.

My wife left with my best friend...
     and I miss him!