Hello Guest it is March 28, 2024, 10:35:45 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

451
General Mach Discussion / Re: Access to maintenance parameter values
« on: March 15, 2017, 10:15:28 AM »
In the turn xml there are entries for dist0 to dist5, I assume those are axis xyzabc.  Mine have values for 0,2,3 which would correspond to x,z,a which I have.

There is also a SecondsOn value which I presume is what is retrieved with the TotalHours param.  I couldn't find anything else on the subject.

452
Mach4 General Discussion / Re: G31
« on: March 15, 2017, 09:40:01 AM »
Update,

Ran straight from the MDI:

g1 x.4 f.5
g1 x.3

ran 10 times and the positioning was unchanged

ran straight from the mdi:

g31 x0 f.5
g1 x.3

Ran once and hung until I pressed the stop button

Ran straight from the mdi:

g1 x.3
g31 x0 f.5

ran 5 times and each time the x.3 was closer to the centerline by approx .008

Thoughts?

RT

453
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



454
Mach4 General Discussion / Re: Mach4/Lua script do's and Dont's
« on: March 13, 2017, 05:42:40 PM »
I don't believe that is going to work either.  mdiExecute will only execute lines of gCode/mCode and returns immediately before the code is fully executed.  If I want to get the result of a probe I can't do that until the strike has occurred.  It seems we are back to the old while isMoving() sleep for a while except we don't have that function anymore.

Does the mcCntlIsInCycle work for files only or mdi and macro calls to execute gcode?

455
Mach4 General Discussion / Re: Mach4/Lua script do's and Dont's
« on: March 13, 2017, 05:10:04 PM »
Hi Daz,

Yes, the module does actually load, I am able to call the rtAudio and the rtCountDown through m calls so I know the module is loaded, and the call to rtProbeX actually issues the first g31 'Quick Strike' and backs off and then hangs.  No movement after that.  If I wait and press stop I would actually get a lasterror displayed, before I commented them out.  

Just saw Chaoticone's response.  Not able to use GcodeExecuteWait.  I'll try gCodeExecute unless he tells me that's a no-no too.

RT

456
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

457
General Mach Discussion / Re: Question on Xbox 360 Plug-In on Mach 3
« on: March 11, 2017, 11:20:25 AM »
Not sure which zero you want to go to but:

Create a new macro, lets say m888.m1s

In it write

code("G0 Z0")

then configure you xBox controller A button to custom macro#1 and put 888 into the Custom Macro#1 box.

You can put as many moves or commands as you want:

code("G0 Z1")
code("G0 X0")
code("G0 Y0")
code("G0 Z0")

HTH

RT

458
General Mach Discussion / Re: Inconsistant ATC Positioning
« on: March 11, 2017, 11:01:43 AM »
Quote
When the required tool is selected and the turret rotates I need it to run back against it's stop for every tool selected, when it's there then the DRO needs to be reset maybe

I don't know what is 'right' but if that is what you want to do then in each place where I commented out the line like this one for tool 4:

REM    SetOemDRO(803,4)

you would remove the REM and change it to:

   SetOemDRO(803,135)

I assume you are using stepper motors and backing up against the stop until the stepper loses steps. then I guess this would work.  Personally I would make your moves
G0 A138
while isMoving()
wend
G0 A135

No need to then reset the DRO.


Like I said I don't have a turret so I don't know what the proper way to use it.

Good luck

RT


459
General Mach Discussion / Re: Inconsistant ATC Positioning
« on: March 10, 2017, 06:41:54 PM »
What version of Mach3 are you running?

460
General Mach Discussion / Re: Inconsistant ATC Positioning
« on: March 10, 2017, 06:39:31 PM »
George,

If the speed setting is 1% then that is why your turret ref is so slooooow.  Change it to higher number!


I can only assume that you copy and pasted the code incorrectly so I have attached the file.  It runs in my editor