Hello Guest it is March 29, 2024, 02:52:28 AM

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.


Topics - rhtuttle

Pages: « 1 2 3 4 5 6 7 8 9 »
61
Mach4 General Discussion / DRO behavior
« on: November 09, 2017, 01:29:30 PM »

If a DRO who's DRO code is set to CurrentJogIncr. has a valid number (read, one of the 10 jog increments defined) entered through the keyboard the 'core/inst' register entries for JogIncX through JogIncC are updated with the new value and when incremental jogging is requested the axis moves the correct amount.  Same thing occurs when using the 'Incremental Jog Step' button. 

It appears that some event is triggered when the value changes.

If however you change the value programmaticaly, e.g. scr.SetProperty('droJogInc',"Value",tostring(SetInc)) , the event is not fired.  Shouldn't any change to the 'Value' call the update event/action?
Is there a way to force/call that event/action?

Additionally, it you write to the registers, new values:

        mc.mcJogSetInc(mInst, mc.X_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.Y_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.Z_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.A_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.B_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.C_AXIS, SetInc) -- set inc for axis

they are ignored on further incremental jog requests.  Is it not correct to read the register for the jog increment each time an incremental move is made?

And why is there no mcJogCycleIncrement() api available?

TIA

RT

62
Mach4 General Discussion / Macro help mcCntlGcodeExecuteWait
« on: November 03, 2017, 06:16:52 PM »
Using latest build 3481 -pmdx411 - Lathe mode

When I use this code in the MDI it functions as expected
g83 x0 z.6 r0 q.30 p.1 f4
so I don't think this is pmdx related

I have tried running the macro from both the mdi: M6999 D1.5

and from a button that gets the current Zaxis position and calls(correctly) the macro

I have tried mcCntlGcodeExecute and mcCntlGcodeExecuteWait and both basically run as expected, peck to.6 on the Zaxis but then continues on for another cycle and then just keeps going past the .6 mark.

I have also tried mcCntlMdiExecute and it wont run at all.

What am I missing in the macro sCode string?
Which api call should  I be using?

Code: [Select]
function m6999(hVars) 
  local roughFeed=4
  local roughSpeed=600
  local zStart=0
  local zEnd=0
 
  local inst=mc.mcGetInstance()

-- make sure the spindle is set in low gear,   manual change 
  if mc.mcSpindleGetCurrentRange(inst)~=0 then
    wx.wxMessageBox('Set Spindle Gearing to Low Speed')
    mc.mcSpindleSetRange(inst,0)
  end
--make sure the macro is called with the current z position 
  if (hVars ~= nil) then
    local DFlag = mc.mcCntlGetLocalVarFlag(inst, hVars, mc.SV_D)
    if(DFlag == 1) then
      zStart = mc.mcCntlGetLocalVar(inst, hVars, mc.SV_D)
  zEnd=zStart*.4
      mc.mcCntlSetLastError(inst,"Peck Drill From "..zStart.." to "..zEnd)
    end
  else
    wx.wxMessageBox("hVars=nil")
    return 0
  end
--macro assumes that you want to drill 60% through the material 
  if zStart<=zEnd then
    wx.wxMessageBox("zStart  is <= to zEnd")
    return 0
  end
  ts=os.time()

--Peck Drill
sCode=""
  sCode=sCode.."M3 S"..tostring(roughSpeed).."\n"
  sCode=sCode.."g83 x0 z"..zEnd.." r0 q.30 p.1 f4\n"
  sCode=sCode.."M80".."\n"
  sCode=sCode.."M5".."\n"
-- move back an inch to allow for the swapping of reel seat end to finish through drill
  sCode=sCode.."g0 z"..tostring(zStart+1).."\n"
--  wx.wxMessageBox(sCode)
  mc.mcCntlGcodeExecuteWait(inst,sCode)
  tr=os.difftime(os.time(),ts)/60
  mc.mcCntlSetLastError(inst,"Pecking Time: "..string.format("%.1f min",tr))
  return 1
end
if mc.mcInEditor()==1 then
  m6999()
end

Any help Greatly appreciated.

RT

63
Mach4 General Discussion / Update error
« on: November 02, 2017, 06:50:07 PM »
Today I decided to update Mach4 to the latest build on the PMDX site, Build3481

After downloading and installing the new build I imported the lathe profile package I created just prior to installation.  After answering yes to about 25 windows asking me if I wanted to overwrite files the screen load script ran and then I got the following error window.

I don't know what caused it or how to fix it.

Any help greatly appreciated 

64
Mach4 General Discussion / sms to phone
« on: October 31, 2017, 11:56:17 AM »
I would like to be notified when a script is complete by sending a SMS text message to my cell phone.
Has anyone successfully been able to do this with Mach4?  I found this snippet from the web but I get an error message:
Got a socket error trying to read. Address '192.168.1.5'. Port 52181


-- load the smtp support
local sckt = require("socket.smtp")

-- Connects to server "localhost" and sends a message to users
from = "<luasocket@example.com>"

rcpt = {
  "<myPhoneNumberHere@vtext.com>"
}

mesgt = {
  headers = {
    to = "Ralph Tuttle <myPhoneNumberHere@vtext.com>",
    subject = "CNC Lathe Task Complete"
  },
  body = "CNC Lathe Task Complete, body"
}

r, e = sckt.send{
  from = from,
  rcpt = rcpt,
  source = smtp.message(mesgt)
}


TIA

RT


65
Mach4 General Discussion / Mach4lathe - Not ready for prime time
« on: April 27, 2017, 12:43:55 PM »
Mach4 Lathe is not supported at this time by either New Fangled Solutions, SmoothStepper, PMDX or UCDrive.  Since few users of Mach4 use Mach4Lathe, the plugins have not been tested with any kind of rigor. 

I identified problems with the UC100 plugin and only after having gone public on forums did they finally admit that they had not tested it on Lathe and that it should not be used with Mach4 Lathe.

I then went to PMDX 411 and their plugin and ran into another bug (G31).  Six weeks ago I opened a ticket with NFS and five weeks ago posted to the PMDX forum.  As usual everyone assumed that it was user error that caused the problem.  I created a YouTube video showing the problem, provided all requested information three weeks ago and PMDX acknowledged that they have a problem with their plugin.  No further response from them to date.

I’ve now wasted three months of my hobby time chasing down bugs that should have been caught with basic testing.

There are flaws in the lathe wizards as well that I have not yet publicly addressed.

I would seriously suggest that anyone considering purchasing or moving to Mach4Lathe re-evaluate that decision at this time. 


RT

66
Mach4 General Discussion / Mach4 logging facility
« on: March 25, 2017, 02:02:53 PM »
Can anyone tell me whether they can replicate this problem.  Just load mach4lathe profile and then go to 'Diagnostics->Logging...' and see if you get the standard logging window or a window that has nothing yet has a taskbar presence.  I have it on two machines and get the same invisible window.  If I load Mach4mill I get the standard logging window.

I have re-installed on one of those machines both using ver 3233.

TIA

RT

67
Mach4 General Discussion / G31
« on: March 14, 2017, 04:27:43 PM »
Thought I would measure to see what kind of consistency I was getting from my probe strikes.

I put the following code in a button:

 mc.mcCntlGcodeExecuteWait(inst,'G31 X0 F0.5')  -- First slow strike
 r1,rc=mc.mcAxisGetProbePos(inst,0,false)
 r2=mc.mcAxisGetPos(inst,0)
 mc.mcCntlGcodeExecuteWait(inst,'G01 X.3 f0.5')
 mc.mcCntlSetLastError(inst,string.format('%1.4f : %1.4f : %1.4f',r1,r2,r1-r2))


The difference between the position in the dro and the probe strike position is consistently .0080 or .0079

While probing the dro's don't change at all, is that how it should be?

Each time I execute it the positions change:

.1958 : 0.2037 : -.0080
.2036 : 0.2037 : -.0080    - creep of 0.0078
.2115 : 0.2195 : -.0080    - creep of 0.0079

Each time the probe beginning position is closer to the contact position even though I start at .3 and return to .3

Its as if the machine position is adjusting automatically for the difference in strike versus end.  Is it supposed do that?

I have checked my couplings and they are secure and I don't believe I am losing steps.

I am using pmdx411 and their plugin is fairly new and I am using it with m4turn.

Before I go to the pmdx forum I want to confirm that this is not normal behavior.

Thanks,

RT



68
Mach4 General Discussion / Mach4/Lua script do's and Dont's
« on: March 13, 2017, 04:05:26 PM »
I am hoping someone can explain the do's and don't's of Mach4/Lua and  macro scripts and GUI's and how they interplay. 

As I understand it there are two instances of Mach4 Lua code running simultaneously.  One for the GUI(screen load script) and one for running macros/gcode/movement?

I was told to create a module for code that is to be used by both the screen and macro scripts.  I have some code that I put in the mach4hobby\modules directory and named it rtMyModulse.lua. It contains 3 functions at this point.

My ScrrenLoadScript contains:  rt=require "rtMyModule" in the load modules section which successfully instantiates rt for use in the screen.

The first two functions work as expected from both the a screen button and a call to a macro (m9002.mcs example below).

The third function rtProbeX(dir) also works in a button script: rt.rtProbeX(1).

However, when I call m9000 from the mdi, or from a button using: mc.mcCntlMdiExecute(inst,"m9000"), it calls rtProbeX and executes the first part past the 'quick strike' and then fails.

Can a macro run several mcCntlExecuteGcodeWait?
Can a function in a module be called by a macro and execute several mcCntlExecuteGcodeWait?
Can you mcCntlSetLastError from a macro?
Can a function in a module be called by a macro and execute mcCntlSetLastError?

I've read that Lua does not have real threads but do the Gui and macro scripts not communicate/syncronize through callbacks or coroutine?

Are there any whitepapers on Mach4 structure and interplay?

rtMyModule.lua
Code: [Select]
ocal rtModule = {}
  local inst = mc.mcGetInstance()
  local profile = mc.mcProfileGetName(inst)
  local path = mc.mcCntlGetMachDir(inst)
 
  function rtModule.rtMessage(msg)
    wx.wxMessageBox(msg)
  end
 
  function rtModule.rtAudio(fileName)
    local audio=wx.wxSound(path.."\\Sounds\\"..fileName..".wav",inst)
    audio:Play()
  end

  function rtModule.rtAudioCountDown(StartNum,EndNum)
    local i=StartNum
    while i>=EndNum do
      rtModule.rtAudio(""..i)
      wx.wxMilliSleep(900)
      i=i-1
    end 
  end
 
 function rtModule.rtProbeX(Dir)
  local r1,r2,r3,retVal,rc
  --  local inst=mc.mcGetInstance()
  local xStart,rc

  xStart=mc.mcAxisGetPos(inst,0)-- Save starting X pos
  -- mc.mcCntlSetLastError(inst,"")
  mc.mcCntlGcodeExecuteWait(inst,"G31 X0 F4")  -- Quick strike

  r1,rc=mc.mcAxisGetProbePos(inst,0,false)
  mc.mcCntlGcodeExecuteWait(inst,'G01 X'..tostring(mc.mcAxisGetPos(inst,0)+0.030*Dir)..' F4') --Back off
  mc.mcCntlGcodeExecuteWait(inst,'G31 X0 F0.5')  -- First slow strike
  r1,rc=mc.mcAxisGetProbePos(inst,0,false)
  mc.mcCntlGcodeExecuteWait(inst,'G01 X'..tostring(mc.mcAxisGetPos(inst,0)+0.030*Dir)..' F4') --Back off
  mc.mcCntlGcodeExecuteWait(inst,'G31 X0 F0.5') -- Second slow strike
  r2,rc=mc.mcAxisGetProbePos(inst,0,false)
  mc.mcCntlGcodeExecuteWait(inst,'G01 X'..tostring(mc.mcAxisGetPos(inst,0)+0.030*Dir)..' F4')  --Back off
  mc.mcCntlGcodeExecuteWait(inst,'G31 X0 F0.5') -- Third slow strike
  r3,rc=mc.mcAxisGetProbePos(inst,0,false)

  mc.mcCntlGcodeExecuteWait(inst,'G01 F8 X'..xStart)--return to starting position
  retVal=(r1+r2+r3)/3  -- average the strikes
  --  mc.mcCntlSetLastError(inst,string.format("%1.4f - %1.4f - %1.4f ",r1,r2,r3))
  return retVal
end

return rtModule



m9000.mcs
Code: [Select]
--m9000 lathe centering probe

function m9000(hVars)
    local xDis=1
    local zDis=.25
    local zStart
    local zEnd
    local xPos
    local xNeg
    local flag, rc
    local rt = require "rtMyModule"
    local inst = mc.mcGetInstance() -- Get the current instance
    local nilPoundVar = mc.mcCntlGetPoundVar(inst,0)
    local message = ""

    if hVars ~= nil then
      flag, rc = mc.mcCntlGetLocalVarFlag(inst, hVars, mc.SV_X)
      if (flag == 1) then
        xDis, rc = mc.mcCntlGetLocalVar(inst, hVars, mc.SV_X)
        if xDis==nil then
          xDis=1
        end
      end
      flag, rc = mc.mcCntlGetLocalVarFlag(inst, hVars, mc.SV_Z)
      if (flag == 1) then
        zDis, rc = mc.mcCntlGetLocalVar(inst, hVars, mc.SV_Z)
        if zdis==nil then
          zDis=0.25
        end
      end
    end

    mc.mcAxisSetPos(inst,0,0)
    zStart,rc=mc.mcAxisGetPos(inst,2)
    zEnd=zStart-zDis
    mc.mcCntlGcodeExecuteWait(inst,'G0 F1 X'..xDis..'\nG0 F1 Z'..zEnd)
    --mc.mcCntlSetLastError(inst, "Probing for Positive X" )
    xPos= rt.rtProbeX(1)
    mc.mcCntlGcodeExecuteWait(inst,'G0 Z'..zStart)
    mc.mcCntlGcodeExecuteWait(inst,'G0 X'..-xDis)
    mc.mcCntlGcodeExecuteWait(inst,'G0 Z'..tostring(zStart-zDis))
    --mc.mcCntlSetLastError(inst, "Probing for Negative X" )
    xNeg= rt.rtProbeX(-1)
    mc.mcCntlGcodeExecuteWait(inst,'G0 Z'..zStart)
    mc.mcCntlGcodeExecuteWait(inst,'g01 f8 X'..tostring(2*xPos-(xPos-xNeg)))
    mc.mcAxisSetPos(inst,0,0) 
end

if (mc.mcInEditor() == 1) then
    m9000(0)
end


m9002.mcs
Code: [Select]
function m9002()  --testing load rtMyModule
 local inst = mc.mcGetInstance()
 
 mc.mcCntlGcodeExecuteWait(inst,"g1F4 x1")
 
 rt = require "rtMyModule"
 
 if rt==nil then

    wx.wxMessageBox("rt==nil")

  else

    rt.rtMessage('Another Hello')

  end

end



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

Can anyone enlighten this old dog as to why this fails and what the rules and regulations are for scripting screen use and macro use?

RT

69
Mach4 General Discussion / Combo List Box
« on: March 07, 2017, 01:06:45 PM »
I don't see a list box or combo list box in the screen designer.  Is that something I missed or is going to be added or do we have to create one in lua?

TIA

RT

70
Mach4 General Discussion / UC100 Mach4 Lathe G83 fail
« on: February 26, 2017, 07:15:49 PM »
When executing a G83 in Mach4 it does not perform as it should.  I have uploaded a YouTube video showing the failure.  I had previously used this exact same code when I was running under Mach3 before they came out with the Mach4 plugin and it worked perfectly.  UCNC believes it is a Mach4 bug.  Can any of you duplicate the error with any other motion controller or Uc100?
 

https://www.youtube.com/watch?v=oQWuqf_LF60

TIA

RT

Pages: « 1 2 3 4 5 6 7 8 9 »