Hello Guest it is October 03, 2023, 04:11:43 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - rhtuttle

Mach4 General Discussion / Coroutines, Button Scripts, Modules, Probing
« on: January 31, 2018, 01:47:20 PM »
I am posting this as a means of saying thank you to all of you that have helped me to begin to understand how Mach4 operates and hope that this serves as a jump start for all of the new users of Mach4

This example shows:
How to use a coroutine in a button script so the GUI does not lock while probing.
The use of a module so that the routine can be used by any button.
Using Lua's ability to return multiple values from a function
Use of registers used by Mach4 for probe
Use of global vars set with the screen load script load modules section
Use of the scr variable to retrieve and set screen elements
Use of relative movements in Lathe since fanuc lathes do not recognize G91

A big thank you to DazTheGas for his video on coroutines: https://www.youtube.com/watch?v=t2xQYvAXT8o&feature=youtu.be
and to Brannab for her video on using the screen editor: https://www.youtube.com/watch?v=P1xZkFgS5cQ

Be sure to watch both of these if your new to Mach4.

The file 'load_modules.mcs' residing in the profile's '\Macros' directory and loads any of your self defined modules for the profile being used.

Code: [Select]
-- C:\Mach4Hobby\Profiles\MyTurn4\Macros\load_modules.mcs
-- Load modules that you want to be able to use from Mcodes
inst = mc.mcGetInstance()
local profile = mc.mcProfileGetName(inst)
local path = mc.mcCntlGetMachDir(inst)

package.path = path.."\\Profiles\\"..profile.."\\Modules\\?.lua;"..path.."\\Modules\\?.lua;"

--ErrorCheck module
package.loaded.mcErrorCheck = nil
ec = require "mcErrorCheck"

mm = require "mcMasterModule" -- resides: C:\Mach4Hobby\Modules
prb = require "mcProbing"     -- resides: C:\Mach4Hobby\Modules
rt = require "rtMyModule"     -- resides: C:\Mach4Hobby\Profiles\MyTurn4\Modules
gs = require "GcodeScripter"  -- resides: C:\Mach4Hobby\Profiles\MyTurn4\Modules

The following is one of the functions (probe) I use in a module 'rtMyModule.lua' that resides in the profile's '\Modules' subdirectory.  The function could be defined and used in a button script but would then not be available to any other button calls.  I use this function for five buttons on a tab I created.

Code: [Select]
local rtModule = {}

-- probes using relative positioning and returns the work and machine coordinates of a successful strike
-- rc==nil for failure and rc==0 for success
function rtModule.probe(prbNmbr,axis,dis,spd)
  if prb==nil then
    --build:3481 prb and mm are initialized in the load script. mcMasterModule.lu and mcProbing.lua
    wx.wxMessageBox('prb is nil')
    return nil,nil,nil
  if not prb.CheckProbe(1,tonumber(prbNmbr)) then--CheckProbe throws an error message if probe is obstructed
    return nil,nil,nil
  --set vars for the axis to probe and their vars, see Mill GCode Programming.pdf page 19 g31
  --Lathe does not recognize G91 so axes are represented by alternate letters for relative positioning
  if axis=='Z'then
  elseif axis=='X'then
  elseif axis=='Y'then
--[[ need axis alternate letters for A,B,C
  elseif axis=='C'then
    wx.wxMessageBox('Invalid Axis: '..axis)

  --execute the gcode and call the coroutine to let the GUI be updated
  --these two lines act like what you would expect mcCntlGcodeExecuteWait to do
  mc.mcCntlGcodeExecute(mc.mcGetInstance(),'g'..tostring(prbNmbr)..relAxis..tostring(dis)..' f'..tostring(spd))

  --check for valid probe strike
  local rc=mc.mcCntlProbeGetStrikeStatus(mc.mcGetInstance())
  if rc==0 then
    wx.wxMessageBox('Fault: No Probe Strike')
    return nil,nil,nil

  --find where the probe made contact
  local posWrk,rc=mc.mcAxisGetProbePos(mc.mcGetInstance(),mcAxis,0)--probe Strike Position Work Coords
  local posMach,rc=mc.mcAxisGetProbePos(mc.mcGetInstance(),mcAxis,1)--probe Strike Position Machine Coords

  --at this point you could execute more probes by:
  -- local s='g1'..tostring(prbNmbr)..relAxis..tostring(-dis)..'\n' --back off
  -- s=s..'g'..tostring(prbNmbr)..relAxis..tostring(dis)..'\n'      --probe
  -- mc.mcCntlGcodeExecute(mc.mcGetInstance(),s)
  -- coroutine.yield()

  return posWrk,posMach,0 --return the work and machine coordinates for the strike and indicate success with 0

return rtModule

--Button code to probe from current position for x minus direction

Code: [Select]
wait=coroutine.create(  --wait defined in PLC script found in screen edit mode top entry in the Screen Tree Manager
  function ()
  -- set results initially to nil for visual confirmation of good or bad result
  -- get parameters
  local prbCde=scr.GetProperty('txtProbeCode','Value') --which probe input is being used: 31.0 31.1,31.2,31.3
  local dis=scr.GetProperty('txtProbeDistance','Value') -- max distance to probe
  local spd=scr.GetProperty('txtProbeSpeed','Value') -- speed to probe at
  local prbDia=tonumber(tostring(scr.GetProperty('txtProbeDiameter','Value'))) --used for tool setting calculation

  --call the probe function defined in Module rtMyModule.lua, rt set in Screen Load Script Load Module section
  --probe returns the position of the probe strike in work and machine coordinates
  -- probe returns nils for unsuccessful probe attempt
  local prbWrk,prbMach,rc=rt.probe(prbCde,'x','-'..dis,spd)
  if rc~=0 then

  local prbOver=mc.mcAxisGetMachinePos(mc.mcGetInstance(),mc.X_AXIS) -- overshoot of probe
  local prbErr=math.Wrk(prbMach-prbOver)  -- difference between Strike point and stop/overshoot point

  -- 0==success, update results
  if rc==0 then
    mc.mcCntlSetLastError(mc.mcGetInstance(),'X Probe Complete')



Mach4 General Discussion / Re: Mach4 Lathe 3481 Demo, Inc. Jog, Dia mode
« on: January 30, 2018, 05:53:49 PM »
I don't think you can change that behavior. Probably best to open a ticket with NFS on this one.

Mach4 General Discussion / G91 - Lathe
« on: January 30, 2018, 04:23:24 PM »
Since lathe doesn't have a g91 you swap letters for relative moves
x ->u

Anyone know the abc for sure?



Mach4 General Discussion / Re: Lathe Tool Table Setting Tools Help
« on: January 30, 2018, 11:23:25 AM »
As a Quick test issue a t0202 then a t0203 and watch the dros change to the new offsets and the current offset change to 3 and the current tool stay at 2.



Mach4 General Discussion / Re: Lathe 'Set X Offset'
« on: January 29, 2018, 10:24:14 AM »
FYI,  The Set X and Set Z offset buttons DO change the active tool offsets.  If you have the tool table open it will not show the change until you close it and reopen the tool table. 


Mach4 General Discussion / Re: Lathe Fixture offsets
« on: January 27, 2018, 10:14:31 PM »
Ok thanks Rich, that makes sense.  Do you just put the g5x.x in your code?  As you can tell I'm not a machinist but working hard to learn as much as I can.  Your willingness to share your knowledge is greatly appreciated.


Mach4 General Discussion / Lathe 'Set X Offset'
« on: January 27, 2018, 07:56:36 PM »
What offsets are being affected by 'Set X Offset' or 'Set Z Offset' buttons when using Mach4 lathe?  I only see the x and z dros being changed and nothing in the tool table or fixture table.

When reading about setting up the tool table some of the posts reference setting fixture offsets.  How do fixture offsets affect tool table settings?



Mach4 General Discussion / Lathe Fixture offsets
« on: January 27, 2018, 07:53:21 PM »
Could someone explain when you would use fixture offsets with a lathe?



Dude1, As a pre-release licensee of Mach4 I am 'entitled' to an industrial license but then I just have to learn another language :-\  Maybe someday when I get to fully retire  :D

cbyrd, I've watched that video multiple times and it is very well done.

Brett, I never looked at that module before and as a non mill user I didn't see the 'Touch' button.  Very nice code and example of how to create and use a LUA UI.  Sure wish that had been ported to the wxLathe screenset  ;)

However, I think you all missed my main point.  I'm not just looking for a solution(smurph's plc 'state' paradigm is the most likely path), i'm looking to understand how the mcProbing.lua module gets by without using the PLC or coroutines and uses multiple mcCntlGcodeExecuteWait commands without locking the GUI.



PS.  Why oh why is there not a mc.ISIG_ISPROBING signal?

I have just spent the better part of a day examining the probing wizard and the mcProbing.lua file.  I have monitored and searched the many posts regarding both probing, g31 calls and locked GUIs.  I have used coroutines in a homing button script because there was a mcAxisHomeComplete that I could loop on.  

With regards to g31 calls, there seems to be no equivalent api function, ISIG, register or poundvar that you can poll to find out if it has finished moving.  There is a thread by Smurph that talks about using a plc script to monitor a register variable that seems viable.  

Did I miss an API, ISIG or some other method of determinig that a g31 call has completed, not whether it struck but whether it has completed its move? isStill and isInCycle don't work during a probe.

After going through the probing wizard buttons, the mcProbing.lua and mcMasterModule.lua functions I found no coroutines, no use of the PLC wait nor any reading or setting of registers.  Just successive calls to mcCntlGcodeExecuteWait...and it does not lock up the screen.

When I call a 'substantially' similar routine in a module I created, I get a locked screen until the module function finishes its mcCntlGcodeExecuteWait.

Any help?