Hello Guest it is February 19, 2020, 06:11:01 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

Try updating your video driver.


Mach4 Plugins / Re: Mach4 Galil Question
« on: November 06, 2018, 03:46:59 AM »
There is no need to have Mach do anything higher up the chain.  You can set "off on error" on the Galil and do it totally on the Galil.  The error will be seen as a following error.


Mach4 General Discussion / Re: Screen Set Ideas
« on: October 28, 2018, 04:03:40 PM »
Joyous?  I made you life more joyous, right?  :)

Mach4 General Discussion / Re: Mach 4 Goto Work Zero
« on: October 22, 2018, 05:05:02 PM »
This isn't so much about customization as it is trying to get a stock (out of the box) system.  The stock Mill profiles are either 4 or 6 axes.  So on the 4 axis profile, we expect all for axes to be enabled.  Simply enabling the 4th axis is all that is required even if it will not be used. 

Maybe we should have a 3 axis only screen set.  But we could do (and have to maintain) screen sets until the cows come home and not cover all possible scenarios.  So we compromised on two Mill profiles. 


Mach4 General Discussion / Re: homing 2 axis
« on: October 22, 2018, 04:46:15 PM »
Gecko is not a motion controller.  A motion controller drives the gecko.  Usually the PC's parallel port or some motion controller like the ESS or a PoKeys. 

If the two motors are mapped to one axis (a gantry type setup), then the homing SHOULD work as I described above.  So I would talk to your motion controller provider and get them to fix that. 

Failing that, you could use the LUA script API to "unmap" one of the motors from the axis in question and "map" that motor to an OOB axis.  Then you can home the original axis (that now only has one motor) and then home the OOB axis (that now has a motor mapped to it).  Then, once all of the homing is done, unmap the motor from the OOB and map if back to the original axis. 

You will probably want to read the API manual to see what functions are available.  In the Axis category. 

Again, the default homing action SHOULD be sufficient for you.  And if it worked, no scripting would be required.  That is why I suggest asking the motion controller provider to clear this up. 


Mach4 General Discussion / Re: homing 2 axis
« on: October 21, 2018, 02:56:03 PM »
This would all depend on how the motion plugin handles homing, meaning homing is a motion controller function.  The correct behavior would be where motor 1 hits its' home switch first, stops, and motor 3 continues to its' home switch. 

So the question now becomes what motion controller are you using?


-30 is MERROR_NOT_COMPILED.  This means that there is a macro with a syntax error that could not compile.  The system tries to compile all of the macros that have changed since the last compile when the control is reset.  Loading a file does an implicit reset on the control.


Make sure your the settings in the config dialog are correct.  e.g. T on M6 line is too to use. 


Mach4 General Discussion / Re: Calling one G-Code file from another
« on: September 28, 2018, 11:58:30 PM »
In a word, subprograms.  :)  Watch this video and see the magic.  https://www.youtube.com/watch?v=fT0wjbO4NpE

The idea would be that each of your different functions would be a a subprogram.  Then any main part program could call them. 


Mach4 General Discussion / Re: Macros for lathe spindle range change
« on: September 16, 2018, 12:27:02 AM »
local NextSpindleRange = mc.mcCntlGetLocalVar(inst, hVars, mc.SV_P)

That line pulls the P word from the G code line.  It will be hard to debug in the editor since you can't really execute a G code line.  There are also these related functions available:

flag, rc = mc.mcCntlGetLocalVarFlag(number inst, number hVars, number varNumber)  -- This one tels you if the G code word was set on the G code line.  e.g.  "M101 P1"

Code: [Select]
local flag
flag, rc = mc.mcCntlGetLocalVarFlag(inst, hVars, mc.SV_P)  -- flag would equal 1 because P1 was specified on the G code line.
flag, rc = mc.mcCntlGetLocalVarFlag(inst, hVars, mc.SV_Q)  -- flag would equal 0 because Q was specified on the G code line.

comment, rc = mc.mcCntlGetLocalComment(number inst, number hVars) -- retrieve the comment on the G code line that contains the M code. 

As I said earlier, it is hard to debug these things because no G code line has been executed when debugging in the script editor.  So I put in a little helper API function that will simulate it.  :)

hVars, rc = mc.mcCntlCreateLocalVars(number inst, string gCodeLine)

It would be used in the function call stub like this:

Code: [Select]
if (mc.mcInEditor() == 1) then
   -- The function call stub is only ever executed when in the editor debugging, so it is safe to leave this in for testing.
   local inst = mc.mcGetInstance()
   local hVars, rc
   hVars, rc = mc.mcCntlCreateLocalVars(number inst, string gCodeLine)

There are caveats to passung G code words to M codes.  One is you can't use the M word as a variable.  You can use a word more than once.  And finally, the M code that takes variables has to be the only thing on the line.