Messages

1

Mach4 General Discussion / License error 4

« on: December 24, 2018, 09:29:50 PM »

I was just touching off a group of tools and on the last one I noticed my Z position was around double what it should have been (machine position -30ish when it only has 20ish inches of travel).  Machine returns to zero at top of travel, as if the scaling is off.  This happened twice tonight.  The second time I looked in the history and just before I set the last tool offset it said "license error 4".
The only way I found to recover from this issue is to restart Mach.

2

Mach4 General Discussion / Cant jog incrementally or MPG at minimum step/unit (.0001)

« on: December 24, 2018, 11:33:46 AM »

I have dealt with this annoyance for a couple years now, but I need to find a solution.  My steps/unit is 10,000, so I should have a resolution of .0001.  Through MDI I can move in .0001 steps (G0 G91 Z-.0001) successfully.  I am not able to jog in mpg or incremental mode at .0001.  If I give the mpg wheel a spin it will move a few tenths, nothing predictable though.
My setup is MPG and jog buttons through Pokeys 56e, configured through Pokeys plugin for Mach4.  Motion is using a Hicon Integra 7766.  I don't know if this is a pokeys issue or Mach.
Thanks!

3

Mach4 General Discussion / Re: Macro works in MDI but not during program execution

« on: May 08, 2018, 12:56:51 PM »

After scrutinizing the macro line by line, adding error catches, loops, alarms, etc, I figured out it wasn't the macro at all.  One little contact, placed in the plc logic by me several months ago while I was experimenting with something else finally tripped me up.  It was working in MDI mode, but apparently just barely.
Thanks for the help though.

4

Mach4 General Discussion / Re: Macro works in MDI but not during program execution

« on: May 07, 2018, 09:09:13 AM »

Is it possible for an error here to cause it to not run the two lines before mcSignalWait()? 
I will start testing for more error codes tonight, possibly mcSignalGetHandle and mcSignalSetState as well.

5

Mach4 General Discussion / Macro works in MDI but not during program execution

« on: May 06, 2018, 09:09:28 PM »

This toolchange macro used to work fine in both MDI and when called from a program, now for some reason it is skipping the "loosendraw" lines - and only during program execution.  It works fine when called from MDI.

The lines it is skipping are

--LOOSEN DRAWBAR
hsig, rc=mc.mcSignalGetHandle(inst, loosendraw)
mc.mcSignalSetState(hsig, 1)

rc=mc.mcSignalWait(inst, mc.ISIG_INPUT19,mc.WAIT_MODE_HIGH, 5.);

if (rc==mc.MERROR_TIMED_OUT) then
    hsig, rc=mc.mcSignalGetHandle(inst, loosendraw)
    mc.mcSignalSetState(hsig, 0)
    hsig, rc=mc.mcSignalGetHandle(inst, spindleorient)
    mc.mcSignalSetState(hsig, 0)
    mc.mcCntlSetLastError(inst, "LOOSEN DRAWBAR TIMED OUT")
    mc.mcCntlFeedHold(inst)
    mc.mcCntlCycleStop(inst)
    do return end
end   

hsig, rc=mc.mcSignalGetHandle(inst, loosendraw)
mc.mcSignalSetState(hsig, 0)

I hope someone can help, I am beyond frustrated right now.

Code: [Select]

function m6()

local inst = mc.mcGetInstance()
local selectedtool = mc.mcToolGetSelected(inst)
local currenttool = mc.mcToolGetCurrent(inst)
--local selectedtool = 2
--local currenttool = 1
local spindleorient = mc.OSIG_OUTPUT2
local spindleoriented=mc.ISIG_INPUT18
local loosendraw = mc.OSIG_OUTPUT3
local drawloose = mc.ISIG_INPUT19
local tightendraw = mc.OSIG_OUTPUT4
local drawtight = mc.ISIG_INPUT20
local shuttleout = mc.OSIG_OUTPUT5



local xoffset = -29.7469
local yoffset = -14.2502
local zoffset = -22.30

if selectedtool == currenttool then
mc.mcCntlSetLastError(inst, "Current tool == Selected"..selectedtool)
else

--SHUTTLE IN
hsig, rc=mc.mcSignalGetHandle(inst, shuttleout)
mc.mcSignalSetState(hsig, 0)

hsig, rc=mc.mcSignalGetHandle(inst, spindleorient)
mc.mcSignalSetState(hsig, 1)
mc.mcCntlGcodeExecuteWait(inst, "G0 G53 Z-14.")
if currenttool == 0 then
else
mc.mcCntlGcodeExecuteWait(inst, "G53 X"..xoffset+2.5+currenttool*5-5. .. " Y"..yoffset-2.5)
--mc.mcCntlGcodeExecuteWait(inst,"G53 Y"..yoffset-2.5)
mc.mcCntlGcodeExecuteWait(inst, "G53 Z"..zoffset+3.)
end
hsig, rc=mc.mcSignalGetHandle(inst, spindleoriented)
orient =mc.mcSignalGetState(hsig)
while orient do
    orient =mc.mcSignalGetState(hsig)
    if orient == 1 then break end
end
--if currenttool > 0 then
mc.mcCntlGcodeExecuteWait(inst," F100.")
mc.mcCntlGcodeExecuteWait(inst, "G53 G1 Z"..zoffset)

--LOOSEN DRAWBAR
hsig, rc=mc.mcSignalGetHandle(inst, loosendraw)
mc.mcSignalSetState(hsig, 1)

rc=mc.mcSignalWait(inst, mc.ISIG_INPUT19,mc.WAIT_MODE_HIGH, 5.);

if (rc==mc.MERROR_TIMED_OUT) then
    hsig, rc=mc.mcSignalGetHandle(inst, loosendraw)
    mc.mcSignalSetState(hsig, 0)
    hsig, rc=mc.mcSignalGetHandle(inst, spindleorient)
    mc.mcSignalSetState(hsig, 0)
    mc.mcCntlSetLastError(inst, "LOOSEN DRAWBAR TIMED OUT")
    mc.mcCntlFeedHold(inst)
    mc.mcCntlCycleStop(inst)
    do return end
end   

hsig, rc=mc.mcSignalGetHandle(inst, loosendraw)
mc.mcSignalSetState(hsig, 0)
--end
--MOVE UP
mc.mcCntlGcodeExecuteWait(inst, "G0 G53 Z"..zoffset+4.)

if selectedtool == 0 then
    hsig, rc=mc.mcSignalGetHandle(inst, spindleorient)
    mc.mcSignalSetState(hsig, 0)
    mc.mcToolSetCurrent(inst, selectedtool)
    hsig, rc=mc.mcSignalGetHandle(inst, shuttleout)
    mc.mcSignalSetState(hsig, 1)

    do return end
end

mc.mcCntlGcodeExecuteWait(inst, "G53 X"..xoffset+2.5+(selectedtool*5)-5. .. " Y"..yoffset-2.5)
mc.mcCntlGcodeExecuteWait(inst, "G53 Z"..zoffset+1.5)
mc.mcCntlGcodeExecuteWait(inst, "G53 G1 Z"..zoffset)
--TIGHTEN DRAWBAR
hsig, rc=mc.mcSignalGetHandle(inst, tightendraw)
mc.mcSignalSetState(hsig, 1)
rc=mc.mcSignalWait(inst, mc.ISIG_INPUT20,mc.WAIT_MODE_HIGH, 5.);

if (rc==mc.MERROR_TIMED_OUT) then
    hsig, rc=mc.mcSignalGetHandle(inst, tightendraw)
    mc.mcSignalSetState(hsig, 0)
    hsig, rc=mc.mcSignalGetHandle(inst, spindleorient)
    mc.mcSignalSetState(hsig, 0)
    mc.mcCntlSetLastError(inst, "DRAWBAR TIGHTEN TIMED OUT")
    mc.mcCntlFeedHold(inst)
    mc.mcCntlCycleStop(inst)
    do return end
end   

hsig, rc=mc.mcSignalGetHandle(inst, tightendraw)
mc.mcSignalSetState(hsig, 0)

mc.mcCntlGcodeExecuteWait(inst, "G53 G0 Z-14.")




hsig, rc=mc.mcSignalGetHandle(inst, spindleorient)
mc.mcSignalSetState(hsig, 0)
mc.mcToolSetCurrent(inst, selectedtool)
end
--SHUTTLE OUT
hsig, rc=mc.mcSignalGetHandle(inst, shuttleout)
mc.mcSignalSetState(hsig, 1)


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


6

Mach4 General Discussion / Re: G00 to G00 rapid block overlap (corner rounding)?

« on: January 01, 2018, 12:37:35 AM »

I uploaded a video of the operation which I would say was a success.
Would sure like to see this added as a feature to mach.

https://youtu.be/kbdbChisIdA

7

Mach4 General Discussion / Re: G00 to G00 rapid block overlap (corner rounding)?

« on: December 27, 2017, 08:51:20 AM »

In case anyone is interested, I ended up posting out both ways for comparison.  Same parameters for both
.062" drill
retract plane .227"
feed plane .197"
drill depth .13"
20ipm @ 20,000rpm
The simple G81 code takes 5minutes 30 seconds to drill the 422 holes in one part.
for the longhand version I turned off the canned cycle in mastercam and reposted the code.  I then converted all the G0 to G1 @ F200., and had to add a line at every hole to make sure it was retracting to the retract plane and not feed plane.
I ran the cv feedrate wizard and changed the max angle to 105
The longhand run time is 3minutes 45 seconds, a savings of over 4 hours at 150 parts.  This was a lot of work though, it would be great if there was a parameter to turn this feature on for rapid moves.

8

Mach4 General Discussion / G00 to G00 rapid block overlap (corner rounding)?

« on: December 26, 2017, 11:55:12 AM »

Is their a parameter equivalent to the fanuc 1722 (overlap for consecutive G00 blocks) in Mach4?  This would, for example, start the acceleration of the x axis when the z-axis has reached a certain deceleration point, essentially rounding corners.  I have over 60,000 holes to drill in 150 parts, and this time savings can really add up.  Right now it looks like in a drill cycle when the z retracts it will decel to zero before x/y moves start.  Are these moves controlled by the trajectory planner or is that only for feed moves?
I may have to post this out in longhand G1 moves at max feedrate to make it work.

9

Mach4 General Discussion / Re: How to make Lua wait for signal state to change

« on: December 09, 2017, 08:30:25 AM »

tightendraw is defined earlier as mc.OSIG_OUTPUT4. 
Anyhow, it works.  Stops the program and exits the macro as expected.
Will post the complete program once it is cleaned up.

10

Mach4 General Discussion / Re: How to make Lua wait for signal state to change

« on: December 08, 2017, 01:24:30 PM »

I wish I could say I understand the terminology in that manual.  I had to google syntactic sugar lol. 
I will test out the below unless you can tell me I am making a mistake.
Thanks!
Joe

Code: [Select]

if (rc==mc.MERROR_TIMED_OUT) then
  hsig, rc=mc.mcSignalGetHandle(inst, loosendraw)
  mc.mcSignalSetState(hsig, 0)
  mc.mcCntlSetLastError(inst, "TIMED OUT")
  mc.mcCntlFeedHold(inst)
  mc.mcCntlCycleStop(inst)

  do return end
end