Messages

351

Mach4 General Discussion / Re: M code Error calling a macro

« on: March 22, 2017, 12:00:06 AM »

If you want a M code macro and a screen button to have the same functionality, put the code in a module and load the module in both the screen load script and the M code macro. 

Make sure the m720 macro script filename is lower case.  As in "m720.mcs".  Also, you have functions within the m720 function.  While this works in LUA, it can be confusing.  The Write/GetRegister functions would be better suited in a file all by themselves.  Say "utility.mcs" and drop that file into the macros directory.  Or, as mentioned above, put in a global module. 

Steve

352

Mach4 General Discussion / Re: Optional Stop Output

« on: March 08, 2017, 12:42:52 AM »

We can't put each possible thing in Mach that everyone could possibly want.  Heck, we can't even dream them all up!  But what we did try to do with Mach 4 is give users a tool set that they can use to modify or make the system work as they please. 

Now, I'm going to get a bit nerdy here, but Mach 4 borrows heavily on one of the greatest tool sets that mankind has ever invented.  And that tool set is the UNIX operating system.  If you have ever played with UNIX, or a clone thereof, you will know that it has a lot of little low level executable files (commands) that each do one particular thing really well.  One can accomplish almost anything by combining these commands (sed grep cat, etc..) to do a task that is not otherwise provided by the base operating system.  So Mach 4 is very similar in that regard. 

One thing we learned with Mach 3 is you can try to put the Kitchen sink in there but it gets REALLY hard to maintain.  Sooner or later, a more fundamental change will come along and break the Kitchen sink functionality and we end up with a bunch of dirty dishes.    I review the feature request thread quite often and honestly, there are a lot of Kitchen sinks in there.  Not that they are bad ideas at all.  Just most of them can be accomplished already!  I know people are just breaking the surface of what can be done with Mach 4.  It takes time for the knowledge base to grow.  But in time, it will become second nature and the line between what can be accomplished with the tool set and what actually needs to become a new tool will get clearer. 

Steve

353

Mach4 General Discussion / Re: Combo List Box

« on: March 07, 2017, 06:56:31 PM »

You didn't miss it.  And it is too generic to be used as a screen control, so I doubt it will ever be added.  So LUA is the way. 

Steve

354

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

355

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

356

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

357

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

358

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

359

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

360

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