Messages

1

Mach4 General Discussion / Re: stop while Mfuncion run

« on: August 18, 2019, 11:49:20 PM »

Look at the LUA syntax.  It is different than the C syntax you posted. 

state, rc = mc.mcCntlGetState(inst)

if (state == mc.MC_STATE_IDLE) then
    -- We are no longer running because of a stop or e-stop.
end

Here are some interesting control state constants:
mc.MC_STATE_IDLE
mc.MC_STATE_JOG -- manual jogging
mc.MC_STATE_DRYRUN --dry run
mc.MC_STATE_HOME
mc.MC_STATE_FRUN -- running a G code file.
mc.MC_STATE_MRUN -- running MDI G code. 

Steve

2

Mach4 General Discussion / Re: Popup - "Configure a correct IP adress"

« on: August 18, 2019, 02:59:19 PM »

I'm going to beg to differ.  That popup is NOT coming from Mach.  Mach cares nothing about IP addresses.  Only motion and IO devices may care about IP addresses.  Even the popup suggests it is a message from a device.  So if it is not coming from ESS or Mach, then perhaps it is some other plugin that supports an Ethernet device?  Or a script, possibly?

Steve

3

Mach4 General Discussion / Re: stop while Mfuncion run

« on: August 18, 2019, 02:51:19 PM »

Checking the state of the control, mcCntlGetState(), looking for a non running state could be used.  You would need to check the state after every call that does not return an error when the control is stopped.  For example, mcSignalSteState().  It is perfectly fine to set a signal state when the control is stopped.  So you MUST use some other method to check for a stop condition with those types of API calls. 

Steve

4

Mach4 General Discussion / Re: rs485 VFD Spindle Control

« on: August 16, 2019, 01:09:56 PM »

Mach 3 plugins will NOT install into Mach 4.  I can answer that part.  As to if there is something similar to that Mach 3 plugin, I don't know.   

Steve

5

Mach4 General Discussion / Re: Lua script problems

« on: August 16, 2019, 12:48:18 PM »

wait(1) is the main problem.  At least that is what the error log said.  In order to use it, it must be defined ABOVE the code from which you want to call it.  It looks like you were nesting that wait function inside another function?  Possibly the m110() function? 

This should work:

Code: [Select]

-- Dust Collector button script
-- M110/M111 Output 50 signal 1100

function wait(seconds)
  local start = os.time()
  repeat until os.time() > start + seconds
end

function m110()
    inst = mc.mcGetInstance()
    local hSig, rc = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT50)
 
    mc.mcSignalSetState(hSig, 1)
   
    wait(1)
    mc.mcSignalSetState(hSig, 0)
end --end function m110

Also, you may run into a even more hard to deal with problem if several macro scripts define a wait() function.  Only the LAST loaded wait() function will be used!  Now which one will it be?  The answer is "You don't know!"

The best way to use common functions that are available to ALL macro scripts is by using modules. 

But you don't even need to define the wait() function or use modules for this.  Fortunately, we have LUA with wxWidgets bindings and you can use its' wx.wxMilliSleep() function.  If you want to wait 1 second, then do wx.wxMilliSleep(1000).  Half a second is 500, etc...

Steve

6

Mach4 General Discussion / Re: stop while Mfuncion run

« on: August 16, 2019, 12:04:52 AM »

It is up to you, the script writer/programmer, to catch the stop condition and abort the rest of the script.  This is mainly done with checking the return codes from the API functions.  e.g. If the return code is not mc.MERROR_NOERROR, abort the script.

Steve

7

Mach4 General Discussion / Re: Macro from MDI

« on: August 14, 2019, 12:49:12 AM »

It is probably a case issue.  The macron filename needs to be lower case.  We will use m103 for the macro name for this example.  So "m103.mcs" (correct) vs. M101.mcs (incorrect).  Then, inside the file, there should be a function called m103().  This function should also be lower case.  Finally, the the stub code InEditor needs to call the lower case m103() function.

In summary, just lower case the filename and function name.  If either is upper case it will run in the editor but not in MDI or a G code file.  (Sound familiar?)  Oh, and the function name and filename had better match.  For example, you don't want a filename of m103.mcs and have a function inside it named m102(). 

Steve

8

Mach4 General Discussion / Re: Getting this error when I try to use a message box with my M6 Script

« on: August 06, 2019, 12:46:48 AM »

I run a Galil so the whole tool changer is done in Galil code.  All my M6 script does is post the called tool to the Galil is it is 1 to 16.  Otherwise if the tool is greater than what the ATC has (17 or above), it does EXACTLY what the manual tool change script does. 

Steve

9

Mach4 General Discussion / Re: Getting this error when I try to use a message box with my M6 Script

« on: August 06, 2019, 12:17:47 AM »

Legal tool number range?  That is pretty much defined by you, or the tool changer.  But there no hard rule to any of it.  For instance, my ATC is a 16 pod geneva drive carousel.  Tools 1-16 occupy the ATC and if 17 and above it called out, my M6 script goes into manual tool change mode.  VERY flexible.  Since I know my tool changer only holds 16 tools, that is the number I hard code in the M6 script.

Steve

10

Mach4 General Discussion / Re: Getting this error when I try to use a message box with my M6 Script

« on: August 05, 2019, 11:55:40 PM »

The error is what it says.  You can't use wxMessageBox in any thread other than the main thread.  But it is a programmer error and not a bug type of error.  You can use wxMessageBox() in the PLC script because the PLC script is run in the main thread of the GUI. 

Using wxMessageBox() isn't a really good idea inside of Mach.  It is there because it is part of wxLua.  But just because it is there doesn't mean it is a good thing to use.  Use mc.mcCntlSetLastError() instead.  Or have the PLC script look at a flag or something to use wxMessageBox().

Steve