Messages

291

Mach4 General Discussion / Re: Lua Macro Parameters

« on: March 07, 2017, 06:53:51 PM »

Yeah, that should be fine.  However, I forgot to mention that you might have to set the package path so that the LUA instance can find it.

For the stock profiles, we have a laod_modules.mcs that can be modified (or added to, etc...)

Code: [Select]

---------------------------------------------------------------
-- 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;"
--package.path = path .. "\\Modules\\?.lua;" .. path .. "\\Profiles\\" ..  profile .. "\\Modules\\?.lua;"

--rt module
package.loaded.rtModule = nil
rt = require "rtModule"

That is a modified "load_modules.mcs" file that is distributed in the stock Mach4Mill profile. 

Steve

292

Mach4 General Discussion / Re: Optional Stop Output

« on: March 07, 2017, 06:42:25 PM »

M01 (when opt stop is enabled) to does nothing more than programmatically doing the equivalent of hitting the stop button.  It just returns the machine to the idle state. 

Now, knowing this, one could craft up some code to put in the PLC script.  Here are the logic steps that you would want to take into account.

1. G code must have been running prior to the M01.
2. If G code was running AND OSIG_OPT_STOP is high AND G code was running AND the machine state is idle THEN buzzer!

#1 would need a variable to keep track of this information.  So put a global variable called gCodeWasRunning at the top of the screen load script.

gCodeWasRunning = 0 --keeps track if g code was running.

It is also very convenient to track interesting signal states with a variable as well.  So add a variable to track OSIG_OPT_STOP.

optStop = 0 --tracks OSIG_OPT_STOP

Now we need something to set this variable.  OSIG_GCODE_RUNNING will do fine for this.  So insert a bit of code in the siglib portion of the screen load script to set this variable to 1 if the state of OSIG_GCODE_RUNNING is equal to one.  And add something to track the OSIG_OPT_STOP signal here too.

Code: [Select]

[mc.OSIG_GCODE_RUNNING] = function (state)
    if( state == 1) then
       -- only set if the state is 1.
       gCodeWasRunning = 1
    end
end,
[mc.OSIG_OPT_STOP] = function (state)
    optStop = state;
end,

Next, in the PLC script add the following:

Code: [Select]

-- this assumes that mstate is declared above and that mc.mcCntlGetState() is called to set it.
if (gCodeWasRunning == 1 and optStop == 1 and mstate == mc.MC_STATE_IDLE) then
    gCodeWasRunning = 0 --reset the flag.
    --start buzzer
end

You probably would want to put something in the start cycle button to kill the buzzer if it is sounding as well. 

Steve

293

Mach4 General Discussion / Re: Lua Macro Parameters

« on: March 07, 2017, 05:59:41 PM »

The reason for building a module is to place common code in it.  But let's investigate why we need common code in the first place.  It is safe to assume, if one is writing common code, that the common code will be used by multiple things.  As DazTheGas stated, there are two instances of LUA running.  One instance in the GUI and one instance that the M codes (macros) use.  So these are the multiple things that will be using your common code.  However, both of them need to know about the common code!  You do this with the "require" LUA keyword.

1. For the GUI, you "require" the module in the screen load script.  
2. For the macros, you place a file in the macros directory that you "require" the module in.  DasTheGas' suggestion is a file that you create named "functions.lua".  But it could be any file name as long as it has a .lua or .mcs extention.  

example functions.lua:

Code: [Select]

package.loaded.rtModule = nil
rt = require "rtModule"

When Mach is restarted, it will include functions.lua when it builds the mcLua.mcc file from ALL of the files in the macros directory.  

Once that is done, you will be able to call rt.rtMessage() from both a screen script AND a M code macro.  

Steve

294

Mach4 General Discussion / Re: G76 threading cycle bug ?

« on: March 06, 2017, 06:59:47 PM »

Please see the G76 documentation in the Lathe user's manual.  The K word (for 2 block style G76) takes 1 to 4.  The canned cycle wizard is most likely labeled wrong. 

Steve

295

Mach4 General Discussion / Re: How does G31 Behave?

« on: March 03, 2017, 06:57:04 PM »

Probing is a motion controller function.  All it is to Mach is a regular feed move.  So the first thing I would check is to make sure that the motion controller supports probing and if it does, how to set it up.  For instance, on a Galil, the probe has to be wired to inputs 1, 2, 3, and 4.  Then we map one of those inputs to the Probe signal in Mach.  The probe signal is there just for diagnostics purposes.  Just so the user can jiggle the probe and see the LED flash.  

But back to your question of solving the problem.  Yes, a G31 would be a good way to do it.  It is called a "protected move".  

Steve

296

Mach4 General Discussion / Re: Mach4 3axis only? Still waiting for 4 Axis.

« on: March 03, 2017, 06:50:43 PM »

Man, you sure know how to win friends and influence people! 

Steve

297

Mach4 General Discussion / Re: Preload-Tool Macro

« on: March 03, 2017, 06:35:27 PM »

Nice!!!  I love it when a plan comes together.  Can you feel the powah?!?!  

You gotta love those Hurcos! 

Steve

298

Mach4 General Discussion / Re: Offset image in tool path window

« on: March 03, 2017, 04:38:09 PM »

Yes.  If you want to set multiple fixture offsets, say G54, G55, G56, and G57, and don't want to constantly regen the tool path for each one.  Or just setting the G54 X, Y and Z offset one at a time.  Do you want the tool path to regenerate three times?  Or just once by pressing a button after you set all of the offsets?

The screen is flexible enough so that you can make it do whatever you want.  There is nothing set in stone.  However, it is setup for normal workflow by default. 

Steve

299

Mach4 General Discussion / Re: Tools values not changing

« on: March 01, 2017, 02:14:16 AM »

Executing "T0101 M6" will change the tool number.  M6 does the magic.  T by itself does nothing but set the selected tool.  e.g. the tool M6 will make active. 

Steve

300

Mach4 General Discussion / Re: How to make Mach 4 wait for spindle to come up to speed?

« on: February 28, 2017, 06:51:21 PM »

Two options here:

1. Use the time based waits.
2. Use VFD outputs.

For #1, you must enter the spindle ramp times in the Spindle tab for each range.  Range 0 is the default range. 
For #2, if your VFD has output for "at speed" and "at zero", simply wire them to an input on your controller or I/O device.  Then map those inputs to the ISIG_AT_SPEED and ISIG_AT_ZERO signals.

Steve