Hello Guest it is September 21, 2019, 10:47:21 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.


Messages - smurph

51
Mach4 General Discussion / Re: hold all axis also on jog
« on: April 02, 2019, 06:50:50 PM »
To expand further with some more best practices, break the code up into functional elements.  The OP's original question was about inhibiting motion and jogs.  So let's make the code a bit more modular. 

Code: [Select]
function InhibitMotion(inhibit)
    local inst = mc.mcGetInstance('InhibitMotion()')
    local rc, hSigInhitbitMotion

    hSigInhitbitMotion, rc = mc.mcSignalGetHandle(inst, mc.ISIG_MOTION_INHIBIT)
    if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
        mc.mcCntlMacroAlarm(inst, 600, 'Could not retrieve ISIG_MOTION_INHIBIT signal handle!')
return
end

if (inhibit) then
rc = mc.mcSignalSetState(hSigInhitbitMotion, 1) -- raise the mc.ISIG_MOTION_INHIBIT signal
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 602, 'Could not set ISIG_MOTION_INHIBIT signal state to 1!')
return
end
else
rc = mc.mcSignalSetState(hSigInhitbitMotion, 0) -- lower the mc.ISIG_MOTION_INHIBIT signal
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 604, 'Could not set ISIG_MOTION_INHIBIT signal state to 0!')
return
end
    end
end

function InhibitJog(inhibit)
    local inst = mc.mcGetInstance('InhibitMotion()')
    local rc, hSigInhitbitJog

    hSigInhitbitJog, rc = mc.mcSignalGetHandle(inst, mc.ISIG_JOG_INHIBIT)
    if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
        mc.mcCntlMacroAlarm(inst, 601, 'Could not retrieve ISIG_JOG_INHIBIT signal handle!')
return
end

if (inhibit) then
rc = mc.mcSignalSetState(hSigInhitbitJog, 1) -- raise the mc.ISIG_JOG_INHIBIT signal
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 603, 'Could not set ISIG_JOG_INHIBIT signal state to 1!')
return
end
else
rc = mc.mcSignalSetState(hSigInhitbitJog, 0) -- lower the mc.ISIG_JOG_INHIBIT signal
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 605, 'Could not set ISIG_JOG_INHIBIT signal state to 0!')
return
end
    end
end

function InhibitMotionAndJog(inhibit)
InhibitMotion(inhibit)
InhibitJog(inhibit)
end


There are three functions in that code snippet; InhibitMotion(), InhibitJog(), and InhibitMotionAndJog().  Each takes one parameter called inhibit.  InhibitMotionAndJog() simply calls InhibitMotion() and InhibitJog().  Breaking the functions up like this give you the option of using these function in other piece of code, if needed.  What if you simply wanted to inhibit jogs?  Well...  there is a function for that.  :)

Now that we have them inhibit functions, we can call them a variety of ways.  Through the PLC script, through the signal script, or the siglib in the screen load script.   

Example for the PLC script checking if the machine is homed:
Code: [Select]
-- the following functions should reside in the screen load script.
function CheckHomed()
    local inst = mc.mcGetInstance('CheckHomed()')
    local homedX, homedY, homedZ, homed, rc, hSigInhitbitMotion, inhibitMotion
    homedX, rc = mc.mcAxisIsHomed(inst, mc.X_AXIS)
    if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
        mc.mcCntlMacroAlarm(inst, 5000, 'Could not retrieve X axis homed condition!')
return
end
    homedY, rc = mc.mcAxisIsHomed(inst, mc.Y_AXIS)
    if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
        mc.mcCntlMacroAlarm(inst, 5001, 'Could not retrieve Y axis homed condition!')
return
end
    homedZ, rc = mc.mcAxisIsHomed(inst, mc.Z_AXIS)
    if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
        mc.mcCntlMacroAlarm(inst, 5002, 'Could not retrieve Z axis homed condition!')
return
end

    hSigInhitbitMotion, rc = mc.mcSignalGetHandle(inst, mc.ISIG_MOTION_INHIBIT)
    if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
        mc.mcCntlMacroAlarm(inst, 5003, 'Could not retrieve ISIG_MOTION_INHIBIT signal handle!')
return
end

    inhibitMotion, rc = mc.mcSignalGetState(hSigInhitbitMotion)
    if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
        mc.mcCntlMacroAlarm(inst, 5005, 'Could not retrieve ISIG_MOTION_INHIBIT signal state!')
return
end

homed = homedX and homedY and homedZ
   
if ((homed == 0) and (inhibitMotion == 0)) then
InhibitMotionAndJog(true)
elseif ((homed == 1) and (inhibitMotion == 1)) then
InhibitMotionAndJog(false)
    end
end

-- and a line in the PLC script like:
CheckHomed()

Example for the siglib using inputs 1, 2 and 3.
Code: [Select]
---------------------------------------------------------------
-- Signal Library
---------------------------------------------------------------
SigLib = {
[mc.OSIG_MACHINE_ENABLED] = function (state)
machEnabled = state;
    ButtonEnable()
end,

[mc.ISIG_INPUT0] = function (state)
   
end,

[mc.ISIG_INPUT1] = function (state)
if (state == 1) then   
InhibitMotion(true)
else
InhibitMotion(false)
end
end,

[mc.ISIG_INPUT2] = function (state)
if (state == 1) then   
InhibitJog(true)
else
InhibitJog(false)
end
end,

[mc.ISIG_INPUT3] = function (state)
if (state == 1) then   
InhibitMotionAndJog(true)
else
InhibitMotionAndJog(false)
end
end

Steve

52
Mach4 General Discussion / Re: hold all axis also on jog
« on: April 02, 2019, 09:40:59 AM »
when checking return codes, is it preferred to use the actual error definition versus the number?

Yes.  The underlying number could change, although not very likely.  However, the possibility exists, so use the constant whenever possible.  You just can't go wrong using constants. 

Steve


53
Mach4 General Discussion / Re: hold all axis also on jog
« on: April 01, 2019, 07:58:18 PM »
Read the code again.  Those alarm conditions are only there if an API return code indicates failure.  In the case of an API failure, you probably WANT to stop the machine.  All of those tests are there to make the code bullet proof and safe, as all production machine should be.  In normal operation, the script would just prevent all movement unless the machine has been homed.  Of course, you could change the script to be trigger on any condition.  Say another input that is raised when the label cylinder is down. 

Steve

54
Mach4 General Discussion / Re: hold all axis also on jog
« on: April 01, 2019, 07:50:33 PM »
BTW,

mc.mcCntlMacroAlarm(inst, 5005, 'Could not set ISIG_MOTION_INHIBIT signal state to 1!')

is the same as the following G code line:

#3000 = 5005 (Could not set ISIG_MOTION_INHIBIT signal state to 1!)

There is also mcCntlMacroStop() which will just stop a cycle but it does NOT raise an alarm (or OSIG_ALARM) and thus does not need a reset to clear it.  Is it the same as the following G code line:

#3001 = 1001 (This is a macro stop!)

Steve

55
Mach4 General Discussion / Re: hold all axis also on jog
« on: April 01, 2019, 07:44:19 PM »
Yes.  ISIG_MOTION_INHIBIT can also be use with safety devices like a light curtain to stop the machine if the operator crosses the boundary. 

It is one of the three following inhibit signals. 

Motion Inhibit  ISIG_MOTION_INHIBIT
Jog Inhibit  ISIG_JOG_INHIBIT
MPG Inhibit  ISIG_MPG_INHIBIT

Motion is ALL motion.  But Jog and MPG can be inhibited separately. 

Steve

56
Mach4 General Discussion / Re: hold all axis also on jog
« on: April 01, 2019, 07:32:17 PM »
It does just that.  Forces an alarm state.  An alarm will stop the machine if it is running a G code file.  And it requires a Reset to clear the alarm condition.  It also raises the OSIG_ALARM signal (that could be used to drive a flashing light, for example).  The number is arbitrary.  I used 5000 and walked it up so that if something happens, you could tell where in the script by matching the alarm number.  The the alarm number and text is put in the status history. 

Steve

57
Mach4 General Discussion / Re: hold all axis also on jog
« on: April 01, 2019, 07:10:59 PM »
Use the motion inhibit input signal.  ISIG_MOTION_INHIBIT

In the Screen load script:
Code: [Select]
function Checkhomed()
local inst = mc.mcGetInstance('CheckHomed')
local homedX, homedY, homedZ, homed, rc, hSig, inhibit
homedX, rc = mc.mcAxisIsHomed(inst, mc.X_AXIS)
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 5000, 'Could not retrieve X axis homed condition!')
return
end
homedY, rc = mc.mcAxisIsHomed(inst, mc.Y_AXIS)
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 5001, 'Could not retrieve Y axis homed condition!')
return
end
homedZ, rc = mc.mcAxisIsHomed(inst, mc.Z_AXIS)
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 5002, 'Could not retrieve Z axis homed condition!')
return
end

hSig, rc = mc.mcSignalGetHandle(mc.ISIG_MOTION_INHIBIT)
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 5003, 'Could not retrieve ISIG_MOTION_INHIBIT signal handle!')
return
end
inhibit, rc = mc.mcSignalGetState(hSig)
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 5004, 'Could not retrieve ISIG_MOTION_INHIBIT signal state!')
return
end

homed = homedX and homedY and homedZ
   
if ((homed == 0) and (inhibit == 0)) then
rc = mc.mcSignalSetState(hSig, 1) -- raise the mc.ISIG_MOTION_INHIBIT signal
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 5005, 'Could not set ISIG_MOTION_INHIBIT signal state to 1!')
return
end
elseif ((homed == 1) and (inhibit == 1)) then
rc = mc.mcSignalSetState(hSig, 0) -- raise the mc.ISIG_MOTION_INHIBIT signal
if (rc ~= mc.MERROR_NOERROR) then -- check retun codes!
mc.mcCntlMacroAlarm(inst, 5006, 'Could not set ISIG_MOTION_INHIBIT signal state to 0!')
return
end
end
end

Then call Checkhomed() from the PLC script
Steve

58
Mach4 General Discussion / Re: Using the Serial plugin from a macro
« on: April 01, 2019, 06:24:21 PM »
I would use the laurs232 module instead.  Do it all in your M3/M4/M5 mocros.  The serial plugin is old... pre LUA modules.  Once we put LUA modules in, it pretty much eliminated the need for the serial plugin. 

59
Mach4 General Discussion / Re: How do I make the Extents mode visible
« on: April 01, 2019, 12:16:24 AM »
The inside the core tool paths still use the API tool path functions.  And the core tool path properties (color, line width, etc..) will be the default for any newly instantiated tool path control in the screen editor.  We decided to move the tool path code directly in the GUI for a variety of reasons.  Not the least of which is making a remote GUI that can operate the control on the machine.  It is in the latest builds.  I call it Mach4GUIR.exe.  Very original.  Not many people would have thought about appending an R to the Mach4GUI.exe.  :D  Anyway, all jokes aside, GUIR doesn't currently have a tool path.  But it will soon!  And that just couldn't be done with the tool path in the local core.

But a version of the tool path does still exist in the core.  It is just that our main GUI doesn't use it anymore.  However, the static wxMach.exe GUI still uses the core's tool path.

We originally put the tool path in the core so that people who wanted to write their own GUIs didn't have to mess with OpenGL.  They simply use our API. 

You can't really create a new tool path control on the fly.  But you can have one that is hidden and then show it.  Mach Motion uses that technique in their screen sets. 

I loved Mach 3.  What a masterpiece it was.  Art simply did an amazing thing when he created it.  But Mach 4 is doing really well now as most newcomers are simply not going for Mach 3.  And despite what people post here, there are a lot of people that were running Mach 3 making the move to Mach 4.  Especially if they need something custom. 

You are welcome for the new stuff.  It is my pleasure.  Stuff I have in mind for the future is 3rd order planner, tie the multiple instances together for true multi-path capabilities (Screw machines, Mill/Turns, etc..), and kinematics.

Steve

60
Mach4 General Discussion / Re: How do I make the Extents mode visible
« on: March 31, 2019, 01:42:59 PM »
Well...  now that the tool paths have been moved entirely to the GUI, mcToolPathGetDrawLimits() isn't used by the GUI anymore (And that was a predominantly GUI API function call, as plugins and motion controllers would never use it). 

The limits do indeed use the soft limits and there is nothing that can change that at the moment.  Or the line style.  I may put something in the tool path properties for the line style.

I'll also think about adding a collision boundary that can be set independently of the soft limits. 

Steve