Messages

771

Galil / Re: Galil controller compatability (what works with the plugin)

« on: April 20, 2017, 02:48:52 PM »

These are not definitive. 

1. Only the 40x0, 41x3 and 18x6 controllers are "officially" supported by the Mach 4 Galil plugin.  There is code in the plugin to run a 21x3, but no testing has been done on them what so ever. 
2. The Galil will perform the same no matter what is running it.  Mach 4 has more features than Mach 3 in some areas while Mach 3 has more in others.  To give a definitive answer, I would need to know what functionality you are looking for. 

To be safe with that 21x3, I would suggest sticking with Mach 3.  I would keep a lookout for a 41x3 controller.  They really are a better fit for a machine motion controller because we can use contour mode with them.  The 21x3 only supports linear interpolation and while it works, it is not optimum for the task at hand. 

Steve

772

Mach4 General Discussion / Re: probing with do loop

« on: April 02, 2017, 12:17:32 AM »

The probing routines are using LUA co-routines (a cooperative multi-tasking scheme that emulates threads), if I remember correctly.  This is so calling the probe routine from a buttons doesn't lock up the GUI for the duration of the probe operation.  So I don't think you can use it in a loop like that because the probing function actually returns before the probing is complete!  You might want to wait on the control to go to an idle state before looping.  But you might also have to wait on the control to NOT be in the idle state before waiting on the idle state.  It will be tricky.  And if you call it from a button, the GUI will be unresponsive until the loops are done.  So... 

In my opinion, it would be easier to write a G code generator wizard to generate G code to digitize the surface. 

773

Mach4 General Discussion / Re: Touch button Hobby vs Industrial

« on: March 27, 2017, 12:06:18 PM »

If you paid $1400 for industrial, you will get support.  The kind of support that almost anything in the industrial world gets.  Because time is money in that world.  Now, this doesn't mean Artsoft is going to wire the machine up for you.  Or help you make a VFD from vendor x work.  Or retrofit the control at all.  We expect that has already been done by some OEM.  What it means is if a working machine suddenly has a problem, Artsoft will help diagnose the problem so that a resolution can be affected as quickly as possible.  That is where the majority of cost is born.  Otherwise, you just get the industrial features.  

Industrial also has the "capability" of running multiple planners to run things such as screw machines and mill/turn machines.  The GUI for these machines will be different and will most likely be developed by the OEM.  

Industrial, being for the industrial market, will not have the hobby touch modules installed by default.  The industrial world uses Macro B routines for probing which are supplied by the industrial probe manufacturer (Renishaw, Blum, etc...).  So to "hobby-ize" industrial, one would have to copy the hobby screen sets AND modules to the industrial installation.  

Most machines running industrial are definitely from an OEM.  The OEM would then be the first line of support to the customer.  And Artsoft would support the OEM.

For the hobbyist, Mach Industrial doesn't have any advantages over Hobby unless your hobby machine is a screw machine or you want to play with Macro B or make a prettier screen set.  I have Industrial on my machine because I have Renishaw probes (that cost MORE than Mach Industrial!!!) and want to use them with the Renishaw Macro B routines.  

Steve

774

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

775

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

776

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

777

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

778

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

779

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

780

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