Hello Guest it is September 20, 2020, 08:53:28 PM

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

Mach4 General Discussion / Re: Ignore M Calls While Loading
« on: April 20, 2017, 03:21:52 PM »
You could use mc.mcmcToolPathGetGenerating().


Mach4 General Discussion / Re: mc.mcToolPathGenerate()
« on: April 20, 2017, 03:17:25 PM »
It will only work in the idle machine state.  :(  Why, because it uses the interpreter to generate the tool path.  So running the interpreter to run a file and generate a tool path is definitely mutually exclusive. 


There is no support for unsolicited messages in the Mach3/Galil plugin.  The Galil software will allow you to turn them on, but we don't have an interface to accept them in the plugin. 


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. 


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. 

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.  


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. 


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. 


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. 


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.