Machsupport Forum

MachPro => MachPro General Discussion => Topic started by: joeaverage on September 11, 2026, 10:43:48 PM

Title: MachPro upgrade questions
Post by: joeaverage on September 11, 2026, 10:43:48 PM
Hi,
I have recently bought a MachPro (18" mill) license, and have a few questions that someone may have encountered.

In the first instance despite having MachPro, and having bought a PC to run it, I'm reluctant to take my existing Mach4Hobby installation out of my machine. I depend on
my machine to make a living, and I don't want to commit to a solution that I've not had the time to explore.

1) With Mach4 on my development PC, I have the motion control (ESS) setup, but no ESS actually connected. When I fire up Mach4 I can decline to have the ESS connected and yet Mach4 will load
and display. Then I can write scripts or try various edits as I please. With MachPro however I have the ESS as motion controller but if the motion control is not actually connected and working MachPro
refuses to load and run, and therefore I cannot write scripts or otherwise experiment. It seems that in order to experiment with MachPro I not only have to nominate the motion control, but it has to be present
in order to load and display? This is turn requires I physically dig the ESS out of my machine just to get my new PC/MachPro setup to run. Is this correct?

2) 99% of my existing Mach4 experience, and tool paths are three axis, but I do have a small number of four and five axis paths as well. As a consequence I have selected wx6.set, or rather
a personalised copy of wx6.set as my screen set. That screen set has a few personalised tweaks to match my machine.

It would appear that MachPro ships with ONLY a three axis screen set. Is this correct?

Will a Mach4 screen set be recognised and run under MachPro? In particular can I export my existing copy of wx6.set INTO MachPro and expect it to work?

Craig
Title: Re: MachPro upgrade questions
Post by: joeaverage on September 12, 2026, 05:34:23 PM
Hi,
OK, I tried copying my current Mach4Hobby screen set (Mywx6Copy.set) into the screens folder of MachPro.
In MachPro's Veiw tab I can see and load the imported screen set, and the screen loads with errors, namely a lot of Lua scripts are missing.
The screen does load, and it looks to be identical to that same veiw in Mach4Hobby....BUT......many of the buttons and functions are greyed out,
so the screen set is not usable as is.

I seem to recall that there was something like an Export function in Mach4 that allowed you to export not only the screen set but also the Lua code snippets
that made it work, but do you think I can find it! If anyone can remember how that is done, I'd appreciate a reminder.

Moving on.......

I downloaded and opened a small Gcode file in MachPro, and tried to run it.

First thing that happened is that MachPro complained and errored out that the machine has violated SoftLimits. I tried turning SoftLimits off and still could not clear the error warning
and therfeore could not get the code to run. This rather suggests that SoftLimits MUST be enabled and set up otherwise you cannot run any code? Does this sound correct?

The I tried setting up SoftLimits, and because this is not hooked to my machine I wanted to manually jog to the SoftLimits locations and thus populate the SoftLimits table....but I cannot jog!!!!
I reverted to manually populating the SoftLimits table in the Control Plugin/Homing-SoftLimits tab, in the same mannere as I would in Mach4Hobby.  Thus I eventually was able to get
SoftLimits to work and thus am able to run the Gcode file.

This brings me to the fact that I cannot manually jog. In Mach4Hobby there was a jog window with the familiar X+, X-, Y+  etc buttons. Pressing said buttons caused the machine to jog.
In that same window you could set jog speed, jog increment, jog mode (absolute/velocity) etc........but there is no such screen or window that I can find in MachPro standard three axis screen set.
Surely it must be possible to jog in MachPro from the screen or keyboard?

I thought then.......'I know, I'll read the manual'......always a last resort, but guess what the manual is  the Mach4 manual, it has nothing about the new MachPro screen set.
WTF???? MachPro is a new version of otherwise familiar software, but the manual describes the PREVIOUS version........not much f******ing help!.

MachLabs need to, if not update but include, instructions for the screen set that they have created.

As far as I can tell ALL the documentation that is included IS the same documentation from Mach4. In the sense that MachPro is an evolution of Mach4 that's OK, but what about documentation
describing those changes that occur in MachPro???

I have built a manual wired jog pendant and have been using it for several years on my Mach4Hobby machine. It is very much how I touch off and otherwise set the machine up. Each of the wires is hooked
via my breakout board/ESS combo to input signals to Mach4. Each Mach input has an entry in the Signal Library table, and each of those entries calls scripts in the ScreenLoad script that enact
the jogging. I presume there must be a similar functionality in MachPro.......but where is it? Where is the documentation describing it?

At the moment I cannot use MachPro. I need my machine to function, and I cannot get MachPro to even match the functionality that Mach4Hobby has.

Craig
Title: Re: MachPro upgrade questions
Post by: joeaverage on September 12, 2026, 05:49:28 PM
HI,
WTF happened to the ScreenLoad script?

In Mach4 you could open it and edit it, and it included the SignalLibrary  table.......but now the script is not much more than a dozen lines. When you chase the modules that are loaded
according to those lines they are all compiled.....you cannot read nor edit them. WTF???? How is anyone supposed to add signals in to the Signal Library table?

Is this a means that MachLabs have used to exclude users from reading/editing their own software installation?

Craig.
Title: Re: MachPro upgrade questions
Post by: Steve Stallings on September 12, 2026, 09:31:54 PM
You are posting in the Mach4 section of this forum. You might get more attention to your questions if you posted in the section for:

    Machsupport Forum
    /
    MachPro
    /
    MachPro General Discussion

Title: Re: MachPro upgrade questions
Post by: Tweakie.CNC on September 14, 2026, 01:14:10 AM
At Steve's suggestion & with Craig's approval this thread has now been moved to the 'MachPro General Discussion' section.

Tweakie.
Title: Re: MachPro upgrade questions
Post by: cd_edwards on September 14, 2026, 09:45:56 AM
Documentation  https://support.machmotion.com/shelves/machlabs-documentation
Not sure about signals, but I would imagine there is a function to add signals. Like the PLC script, there is an internal PLC which we cannot access and a method of adding a public PLC which we can access. In fact there is a widget for doing this. But I'm unsure if this is exactly what you need.
It will toggle IO and map that to a function. Jog X+ etc are some of the functions available to map. There's also a pendant panel for jogging, or a widget you add to the right side panel.
Right click on the right side panel and add a function called the Jogging panel.
Title: Re: MachPro upgrade questions
Post by: cd_edwards on September 14, 2026, 09:54:52 AM
https://support.machmotion.com/docs/current/index.html

Is another location for documentation on functions.
I noticed you asked about adding some "features" to the screen set. Good luck. I attempted the same. Basically it can not be done. Maybe if you created your own screen which does not rely on MachPro's at all, you might get away with it. On the tools screen, you can find Zero buttons for each axis though. Good luck with the BLUM routines, they are broke. and the old Mach4 probing has been replaced with something that looks like it, but I find it broken as well. MachPro's Paul Stephens, created a function for a widget which will call the old routine from a button. I've modified it to support a "Z height" for each probe input. This allows me to use a XYZ (0.2"), Wireless probe(1.818")  and a 3d digitizing probe (0").
Title: Re: MachPro upgrade questions
Post by: paul.stephens on September 14, 2026, 10:30:55 AM
Hi,

I will try to answer your questions to the best of my abilities.

Quote
1) With Mach4 on my development PC, I have the motion control (ESS) setup, but no ESS actually connected. When I fire up Mach4 I can decline to have the ESS connected and yet Mach4 will load
and display. Then I can write scripts or try various edits as I please. With MachPro however I have the ESS as motion controller but if the motion control is not actually connected and working MachPro
refuses to load and run, and therefore I cannot write scripts or otherwise experiment. It seems that in order to experiment with MachPro I not only have to nominate the motion control, but it has to be present
in order to load and display? This is turn requires I physically dig the ESS out of my machine just to get my new PC/MachPro setup to run. Is this correct?

This is dependent on the motion controller. The popup that you have for ESS will force MachPro to abort the startup process. For testing and configuration, I would recommend the SIM motion controller until you're ready to connect the ESS.

Quote
2) 99% of my existing Mach4 experience, and tool paths are three axis, but I do have a small number of four and five axis paths as well. As a consequence I have selected wx6.set, or rather
a personalised copy of wx6.set as my screen set. That screen set has a few personalised tweaks to match my machine.

The visible axis are purely dependent on the axis you have enabled. The more you have enabled, the more DRO's will populate on the GUI. No dev time should be required to show additional axis on your main page.

Quote
OK, I tried copying my current Mach4Hobby screen set (Mywx6Copy.set) into the screens folder of MachPro.
In MachPro's Veiw tab I can see and load the imported screen set, and the screen loads with errors, namely a lot of Lua scripts are missing.
The screen does load, and it looks to be identical to that same veiw in Mach4Hobby....BUT......many of the buttons and functions are greyed out,
so the screen set is not usable as is.

The Mach4 screens have a lot of dependencies that have been removed for MachPro. If you were really wanting to go back to the Mach4 screenset, you will need to make sure you have the correct modules in your modules folder to make the screen work properly.

Quote
I seem to recall that there was something like an Export function in Mach4 that allowed you to export not only the screen set but also the Lua code snippets
that made it work, but do you think I can find it! If anyone can remember how that is done, I'd appreciate a reminder.

This would be under Help→Support→ Package current profile. This however would not include all of the required dependencies of your screen, This will only move over your PMC, and everything directly in side of your profile folder.

Quote
First thing that happened is that MachPro complained and errored out that the machine has violated SoftLimits. I tried turning SoftLimits off and still could not clear the error warning
and therefore could not get the code to run. This rather suggests that SoftLimits MUST be enabled and set up otherwise you cannot run any code? Does this sound correct?

We do push soft limits for safety. If you're running into troubles with soft limits, I would recommend going into your configure → Control page and set your soft limits to -9999 - 9999. Especially for testing.

Quote
This brings me to the fact that I cannot manually jog. In Mach4Hobby there was a jog window with the familiar X+, X-, Y+  etc buttons. Pressing said buttons caused the machine to jog.
In that same window you could set jog speed, jog increment, jog mode (absolute/velocity) etc........but there is no such screen or window that I can find in MachPro standard three axis screen set.
Surely it must be possible to jog in MachPro from the screen or keyboard?

What version are you running? I believe current versions have the onscreen keyboard selected by default. If it is not there, you can right click on the right side of the screen, click select configure Dashboards, make sure your Rows is configured to be greater than one, and in the widgets dropdown, select "Jogging". This should give you onscreen jogging. When it is up, you can configure it by right clicking on the widget itself, selecting Configure Widget, and find the best configuration that suits you.
Here is some documentation on our dashboards:
https://support.machmotion.com/books/cnc-software/page/machpro-widgets-dashboard-commands-and-function-buttons (https://support.machmotion.com/books/cnc-software/page/machpro-widgets-dashboard-commands-and-function-buttons)

Quote
I thought then.......'I know, I'll read the manual'......always a last resort, but guess what the manual is  the Mach4 manual, it has nothing about the new MachPro screen set.
WTF???? MachPro is a new version of otherwise familiar software, but the manual describes the PREVIOUS version........not much f******ing help!.

A lot of the core of Mach is the same as it was built off of the bones of Mach4, however all of our MachPro documentation is located here:
https://support.machmotion.com/books/cnc-software/chapter/machpro-26-cnc-software-stack (https://support.machmotion.com/books/cnc-software/chapter/machpro-26-cnc-software-stack)

Quote
As far as I can tell ALL the documentation that is included IS the same documentation from Mach4. In the sense that MachPro is an evolution of Mach4 that's OK, but what about documentation
describing those changes that occur in MachPro???

We are trying our best to get out MachPro relevant documentation. We have a team dedicated to making this documentation and to get it out. It is approximately 10 years of constant development and changes added on top of the Mach4 framework.

Quote
I have built a manual wired jog pendant and have been using it for several years on my Mach4Hobby machine. It is very much how I touch off and otherwise set the machine up. Each of the wires is hooked
via my breakout board/ESS combo to input signals to Mach4. Each Mach input has an entry in the Signal Library table, and each of those entries calls scripts in the ScreenLoad script that enact
the jogging. I presume there must be a similar functionality in MachPro.......but where is it? Where is the documentation describing it?

We have a preferred method of handling custom scripts, as of right now, if you were to edit the screen load script, if you were to update mach in the future, your script will be blown out of the water.
Recommended custom development path:

If you had any other logic, like a PLC script, you could also do function UserGUIModule.UserScreenUnLoadScript()

Other helpful tools will be user commands as well. Lets say you have a button you want to add to the screen, in the same file, you can write your function with the custom logic, then you can use the following functions to make your buttons:

Code: [Select]
function UserGUIModule.CreateUserCommands()
-- w.CreateCommandActionOption("Example", function(from_opr_panel) w.SetSignalState(mc.OSIG_OUTPUT0, true) end)
-- w.CreateCommandFeedbackOption("Example", function() return w.GetSignalState(mc.OSIG_OUTPUT0) end)
-- w.CreateSimpleCommand("Example")
end
CreateSimpleCommand will add the button as a selectable option on your dashboard, you just give it a string as a recognizable name you can select, this will also tie in your logic to your button name.

CreateCommandActionOption will apply the "Action" to your button. The first Arguement is the button string you put in "CreateSimpleCommand". The second arguement is a list of your logic or functions. I recommend leaving function(from_opr_panel) but any function listed out after is the list of functions that will be ran after the button is selected. Lastly, you will need to put "end" at the end since this second arguement is like stating
Code: [Select]
function(from_opr_panel)
        YourCustomFunctionHere()
end
Lastly we have CreateCommandFeedbackOption. This is looking to return a Boolean value, usually used for more advanced logic. Once again it will be feedback or button name in a string format for the first argument, and the function calls for the second argument.

Let me know if you have any issues or questions and I will try to help when available.
Title: Re: MachPro upgrade questions
Post by: joeaverage on September 14, 2026, 02:27:40 PM
Hi Paul,
thanks for your reply. I need to work through it and digest it all.
Some of them I have discovered already.

Craig
Title: Re: MachPro upgrade questions
Post by: joeaverage on September 14, 2026, 04:07:20 PM
Hi Paul,
I was unaware of the extensive documentation yo have generated for MachPro, and am very pleased to see it.

I have followed the suggestions regarding accessing the screen load script. I'm not completely sure what I'm doing as yet, but it is a step in the right direction.

My question is 'where is the SignalLibrary table?.

In Mach4 if I wanted for instance to monitor an input  to the machine from an operator say, I would add an entry to the SignalLibrary table, and in that entry I would
call the functionality I wanted enacted on receipt of that signal.  In my current Mach4 installation I have about twenty such signal entries.Is it possible for me to continue
with that same idea? I presume that as MachPro is built on Mach4 that the same principle applies?

Craig
Title: Re: MachPro upgrade questions
Post by: paul.stephens on September 15, 2026, 12:08:41 PM
Hi,

I am not 100% confident in what you mean. We do have a signal library, but I don't believe this implementation was in Mach4. It was added with the CommonGUIModule inside of MachPro.

The main implementation is in CommonGUIModule:

SIG_LIBRARY_INST[_inst]: common, per-Mach-instance handlers.
MACHINE_TYPE_SIG_LIBRARY_INST[_inst]: machine-specific handlers, such as mill, plasma, grinder, or height-control behavior.
SCREEN_SIG_LIBRARY_INST[_inst]: screen-specific handlers for multi-instance screens.
SCREEN_SIG_LIBRARY: legacy/global screen handlers used by older screen versions.
Each table is keyed by a Mach signal ID. The value is a Lua callback:

Code: [Select]
SIG_LIBRARY_INST[_inst][signalId] = function(sig_state)
    -- Handle the signal transition
end
When Mach reports a signal transition, CommonSignalScript() converts the state to a Boolean and calls _CommonSignalScript(). That function dispatches the event through the layers above, then runs the generic SignalScript hooks:

CommonSignalScript

The common table is rebuilt by UpdateSignalLibraryArray() in CommonGUIModule. It registers handlers for:

It also stores the resolved spindle-brake signal ID in SIG_LIBRARY_INST[_inst].SpindleBrakeOutput and SIGNAL_LIB_ARRAY.SpindleBrakeOutput.

The rebuild entry point is CommonUpdateSignalLibraryArray() in CommonGUIModule. It:

The screen-specific tables are populated separately. For example:


This Lua “library” sits above the actual Mach signal subsystem. The actual signal objects are handled by the C++/Mach API layer using functions such as mcSignalGetHandle, mcSignalGetNextHandle, mcSignalGetInfo, mcSignalGetState, and mcSignalMap. The API documentation explicitly distinguishes signals from physical I/O: signals can be mapped to I/O, but the signal abstraction does not depend on a particular I/O device.


TableScopePurpose
SIG_LIBRARY_INSTPer Mach instanceCommon machine behavior
MACHINE_TYPE_SIG_LIBRARY_INST  Per Mach instanceMachine-specific behavior, such as mill, plasma, grinder, or height control
SCREEN_SIG_LIBRARY_INSTPer Mach instanceScreen-specific behavior
SCREEN_SIG_LIBRARYGlobal/legacyOlder single-instance screen handlers

Each table uses a signal ID as its key and a Lua function as its value:

Code: [Select]
SIG_LIBRARY_INST[instanceIndex][signalId] = function(signalState)
    -- React to the signal transition
endsignalState is normalized to a Boolean before dispatch.

Dispatch sequence
When Mach detects a signal transition, the following path is used:


The dispatcher does not stop after the first matching table. A signal can therefore have common, machine-specific, and screen-specific behavior.

Building the common library
CommonGUIModule.UpdateSignalLibraryArray() registers the standard handlers, including:


The wrapper, CommonGUIModule.CommonUpdateSignalLibraryArray(), also:

nstance indexing
The tables are indexed by the untagged instance index:
Code: [Select]
local instanceIndex = w.GetUTI(inst)
Handlers registered for one instance should remain associated with that instance. This matters in multi-instance configurations because the same signal number may have different mappings or machine behavior in different instances.

Registration example
A machine module can register a handler for an OEM-mapped signal like this:

Code: [Select]
local signalInfo = w.GetOEMParamIOSigObject(
    "TC_ToolReleaseButtonInput",
    instanceIndex
)

if signalInfo ~= nil and signalInfo["type"] == "Input Signal" then
    MACHINE_TYPE_SIG_LIBRARY_INST[instanceIndex][signalInfo["sigid"]] =
        function(signalState)
            m.ToolReleaseButtonInputChanged(signalState, 1)
        end
end
The mill and plasma implementations follow this pattern in MillGUIModule and PlasmaGUIModule.

Use Case: Tool Release Button
A useful example is a tool changer with a physical tool-release button.

Requirement
When the operator presses or releases the tool-release input:


Registration
During signal-library setup, the machine module resolves the OEM parameter to its actual signal ID and registers a callback:

Code: [Select]
local signalInfo = w.GetOEMParamIOSigObject(
    "TC_ToolReleaseButtonInput",
    instanceIndex
)

if signalInfo ~= nil and signalInfo["type"] == "Input Signal" then
    MACHINE_TYPE_SIG_LIBRARY_INST[instanceIndex][signalInfo["sigid"]] =
        function(signalState)
            m.ToolReleaseButtonInputChanged(signalState, 1)
        end
end
For a second spindle, the module can resolve a parameter such as:

Code: [Select]
TC_ToolReleaseButtonInput2
and register a callback that passes spindle index 2.

Runtime behavior

When the physical input changes:

Mach updates the underlying signal.
Mach invokes CommonSignalScript.
The signal ID is used to look up the callback in MACHINE_TYPE_SIG_LIBRARY_INST.
The callback invokes:
[li]The callback invokes:
[/li][/list]
Code: [Select]
[code]m.ToolReleaseButtonInputChanged(signalState, spindleIndex)[/code]
This keeps the machine module independent of the physical I/O device. The module only needs to know the logical OEM parameter and the resolved Mach signal ID.

Another Use Case: Machine Enable State
The common library registers mc.OSIG_MACHINE_ENABLED for every instance. Its callback updates the cached enable state and starts the appropriate enable or disable sequence.

The handler also performs special startup protection because Mach can emit an initial disabled state while signal synchronization is taking place. That logic is in CommonGUIModule.lua.

This is a good example of behavior that belongs in SIG_LIBRARY_INST rather than a machine-specific table because every screen and machine type needs consistent machine-enable behavior.

When to use each layer:

Use SIG_LIBRARY_INST when:

Use MACHINE_TYPE_SIG_LIBRARY_INST when:

Use SCREEN_SIG_LIBRARY_INST[ when:

Use SCREEN_SIG_LIBRARY when:

Use SCREEN_SIG_LIBRARY only for legacy/global screen behavior where the callback is intentionally not instance-specific.

Relationship to the Lua Signal Library
The Lua signal library described earlier operates above this lower-level signal/I/O layer:
Physical hardware or simulated device

For example, a tool-release button may be physically connected to an input device. The device is mapped to a logical signal. The GUI layer then registers a Lua callback keyed by that signal ID:
Code: [Select]
MACHINE_TYPE_SIG_LIBRARY_INST[instanceIndex][signalId] =
    function(signalState)
        m.ToolReleaseButtonInputChanged(signalState, spindleIndex)
    endThe callback does not need to know whether the signal came from:

I hope this info dump can help solve your questions?

Something else that will be beneficial if you wish to do any custom development for MachPro:
https://support.machmotion.com/docs/current/dir_f2541a3b18981391fa76fac5599e978a.html (https://support.machmotion.com/docs/current/dir_f2541a3b18981391fa76fac5599e978a.html)

This is some of our code documentation. 

I would highly recommend using the wrapper modules functions instead of the core mach API's as we have built in error handling for most of these functions. You should be able to invoke the wrapper module from anywhere with "w."
Title: Re: MachPro upgrade questions
Post by: joeaverage on September 15, 2026, 03:11:38 PM
Hi Paul,
thanks for your extensive reply.

I get a general sense as to how MachPro handles signals, but my programming skills are only fair and my understanding of your terminology is poor.
I do rather believe however that MachPro and Mach4 have a similarity.

In Mach4, for which I am familiar each screen set has a ScreenLoad script, and in that script there is a Lua table called SigLib{...........}. Given that the ScreenLoad script
is part of the screen set, and most operators choose to use say wx4.set or wx6.set as a basis for their own personalised copy, and thus survive Mach build updates.

This is the SigLib table in my current Mach4 installation:
Code: [Select]
---------------------------------------------------------------
-- Signal Library
---------------------------------------------------------------
SigLib = {
[mc.OSIG_MACHINE_ENABLED] = function (state)
    machEnabled = state;
    ButtonEnable()
end,

[mc.ISIG_INPUT0] = function (state)
   
end,

[mc.ISIG_INPUT1] = function (state) -- this is an example for a condition in the signal table.
   -- if (state == 1) then   
--        CycleStart()
--    --else
--        --mc.mcCntlFeedHold (0)
--    end

end,

[mc.OSIG_JOG_CONT] = function (state)
    if( state == 1) then
       scr.SetProperty('labJogMode', 'Label', 'Continuous');
       scr.SetProperty('txtJogInc', 'Bg Color', '#C0C0C0');--Light Grey
       scr.SetProperty('txtJogInc', 'Fg Color', '#808080');--Dark Grey
    end
end,

[mc.OSIG_JOG_INC] = function (state)
    if( state == 1) then
        scr.SetProperty('labJogMode', 'Label', 'Incremental');
        scr.SetProperty('txtJogInc', 'Bg Color', '#FFFFFF');--White   
        scr.SetProperty('txtJogInc', 'Fg Color', '#000000');--Black
   end
end,

[mc.OSIG_JOG_MPG] = function (state)
    if( state == 1) then
        scr.SetProperty('labJogMode', 'Label', '');
        scr.SetProperty('txtJogInc', 'Bg Color', '#C0C0C0');--Light Grey
        scr.SetProperty('txtJogInc', 'Fg Color', '#808080');--Dark Grey
        --add the bits to grey jog buttons becasue buttons can't be MPGs
    end
end,
[mc.ISIG_INPUT20] = function(state) --X servo alarm port1 pin10
if(state==1)then
mc.mcCntlEStop(inst)
local handle=mc.mcRegGetHandle(inst,"iRegs0/XAlarm")
mc.mcRegSetValue(handle,1)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/XAlarm")
mc.mcRegSetValue(handle,0)
end
end,
[mc.ISIG_INPUT21] = function(state) --Y servo alarm port1 pin11
if(state==1)then
mc.mcCntlEStop(inst)
local handle=mc.mcRegGetHandle(inst,"iRegs0/YAlarm")
mc.mcRegSetValue(handle,1)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/YAlarm")
mc.mcRegSetValue(handle,0)
end
end,
[mc.ISIG_INPUT22] = function(state) --Z servo alarm port1 pin12
if(state==1)then
mc.mcCntlEStop(inst)
local handle=mc.mcRegGetHandle(inst,"iRegs0/ZAlarm")
mc.mcRegSetValue(handle,1)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/ZAlarm")
mc.mcRegSetValue(handle,0)
end
end,
[mc.ISIG_INPUT23] = function(state) --A servo alarm port1 pin13
if(state==1)then
mc.mcCntlEStop(inst)
local handle=mc.mcRegGetHandle(inst,"iRegs0/AAlarm")
mc.mcRegSetValue(handle,1)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/AAlarm")
mc.mcRegSetValue(handle,0)
end
end,
[mc.ISIG_INPUT24] = function(state) --B servo alarm port1 pin15
if(state==1)then
mc.mcCntlEStop(inst)
local handle=mc.mcRegGetHandle(inst,"iRegs0/BAlarm")
mc.mcRegSetValue(handle,1)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/BAlarm")
mc.mcRegSetValue(handle,0)
end
end,
[mc.ISIG_INPUT29] = function(state) --C servo alarm port2 pin2
if(state==1)then
mc.mcCntlEStop(inst)
local handle=mc.mcRegGetHandle(inst,"iRegs0/CAlarm")
mc.mcRegSetValue(handle,1)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/CAlarm")
mc.mcRegSetValue(handle,0)
end
end,

[mc.ISIG_INPUT25] = function(state) --AXIS1 port3 pin6
if(state==1)then
local handle=mc.mcRegGetHandle(inst,"iRegs0/AXIS1")
mc.mcRegSetValue(handle,0)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/AXIS1")
mc.mcRegSetValue(handle,1)
end
ChangeJogAxis()
end,
[mc.ISIG_INPUT26] = function(state) --AXIS2 port3 pin7
if(state==1)then
local handle=mc.mcRegGetHandle(inst,"iRegs0/AXIS2")
mc.mcRegSetValue(handle,0)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/AXIS2")
mc.mcRegSetValue(handle,1)
end
ChangeJogAxis()
end,
[mc.ISIG_INPUT27] = function(state) --AXIS3  port3 pin8
if(state==1)then
local handle=mc.mcRegGetHandle(inst,"iRegs0/AXIS3")
mc.mcRegSetValue(handle,0)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/AXIS3")
mc.mcRegSetValue(handle,1)
end
ChangeJogAxis()
end,

[mc.ISIG_INPUT28] = function(state) --FEEDHOLD port3 pin9
mc.mcCntlFeedHold(inst)
end,
[mc.ISIG_INPUT30] = function(state) --AXIS3  port3 pin8
if(state==1)then
local handle=mc.mcRegGetHandle(inst,"iRegs0/Velocity1")
mc.mcRegSetValue(handle,1)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/Velocity1")
mc.mcRegSetValue(handle,0)
end
ChangeJogAxis()
end,
[mc.ISIG_INPUT31] = function(state) --AXIS3  port3 pin8
if(state==1)then
local handle=mc.mcRegGetHandle(inst,"iRegs0/Velocity2")
mc.mcRegSetValue(handle,0)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/Velocity2")
mc.mcRegSetValue(handle,1)
end
ChangeJogAxis()
end,
[mc.ISIG_INPUT1]=function(state)

if(state==1)then

local handle=mc.mcRegGetHandle(inst,"iRegs0/Trial")
local LEDState=mc.mcRegGetValue(inst,handle)
wx.wxMessageBox("LED State=="..tostring(LEDState))
if(LEDState==1)then
wx.wxMessageBox("here"..tostring(LEDState))
local handle=mc.mcRegGetHandle(inst,"iRegs0/Trial")
mc.mcRegSetValue(handle,0)
else
local handle=mc.mcRegGetHandle(inst,"iRegs0/Trial")
mc.mcRegSetValue(handle,1)
end
end
end,

}
Several of the signals are generic and came fro the donor screen set, wx6.set in this case, but quite a number more are signal entries specific to my machine and I coded them.
I think you are familiar with the general idea, whenever Mach detects a signal change, of any description , from any source,  the SignalScript runs, wherein it interrogates the
SigLib table, and if it encounters an entry for that signal identity it executes the function in that table entry. My understanding is that MachPro is similar.

Where MachPro and Mach4 differ is that the SigLib table is immediately readily available to the user to add signal entries or change functionalities. Because the SigLib table is in the
ScreenLoad script it is in effect custom to the users machine.

As you can see from the code I have entries for the servo axis alarms, with each latching data into a register, and enacting an Estop. Easy.
Other signals are from my wired pendant. The SigLib entries capture those signal events and invoke functions also within the ScreenLoad script. This is a method I am very familiar with,
it is both simple and yet immensly flexible and powerful.

Why did you deem in necessary to do away with it?

Craig
Title: Re: MachPro upgrade questions
Post by: paul.stephens on September 16, 2026, 03:05:30 PM
Hi,

That concept still exists.. MachPro still works exactly the way you described: when Mach detects a signal change, a Signal Script runs, it consults a table keyed by signal ID, and if an entry exists for that signal, its function executes. Your understanding of the mechanism is spot on.

What changed is where your custom entries live, and that change was made to protect people doing exactly what you're doing.

Why it changed:

In Mach4, your SigLib lived inside the screen set's Screen Load script, so the only way to customize it was to copy wx4.set or wx6.set and maintain a fork and your copy drifted further from the shipped screens with every update.

In MachPro, the signal handling is split into layers:

Core layer- the shipped screen code handles the things every machine needs (limit switches, homing status, machine enable/disable, emergency stop).
Machine-type layer- mill, plasma, lathe-specific behavior (tool changers, torch height control, etc.).
Screen layer- screen cosmetics like your jog-mode labels.
User layer- this is yours. It runs first, before the built-in layers, and it lives in a file that belongs to your profile, not to the shipped screen set.
That user layer is the direct equivalent of your SigLib, with one improvement: because it's a dedicated user file rather than a copy of our screen code, a MachPro update can improve the shipped screens without touching your custom signal handlers at all. No more maintaining a fork.

Where your code goes in MachPro:

Create (or edit) this file in your MachPro installation:
Code: [Select]
Profiles\<YourProfileName>\Macros\Scripts\UserGUIModule.mcs
That file sits inside your machine profile, so it is custom to your machine and survives updates, same as your personalized screen set, but cleaner.

Inside it you can define a signal library table almost identically to your Mach4 one:

Code: [Select]
local UserGUIModule = {}

USER_SIG_LIBRARY = {
    [mc.ISIG_INPUT20] = function(state)   --EXAMPLE X servo alarm
        local inst = mc.mcGetInstance("UserGUIModule, USER_SIG_LIBRARY, X servo alarm")
        if state then
            mc.mcCntlEStop(inst)
            local handle = mc.mcRegGetHandle(inst, "iRegs0/XAlarm")
            mc.mcRegSetValue(handle, 1)
        else
            local handle = mc.mcRegGetHandle(inst, "iRegs0/XAlarm")
            mc.mcRegSetValue(handle, 0)
        end
    end,
    -- ... add your other signals here, same pattern ...
}

function UserGUIModule.SignalScript(sig, state)
    if USER_SIG_LIBRARY ~= nil and USER_SIG_LIBRARY[sig] ~= nil then
        USER_SIG_LIBRARY[sig](state)
    end
    return true, true, "User Signal Script Complete"
end

return UserGUIModule
Two small differences from your Mach4 code to watch for:


One more thing worth knowing:

MachPro runs the user signal handler first, then its own built-in layers. So your servo-alarm handler and the built-in limit/homing handlers can both respond to signals without interfering with each other. In Mach4, a single SigLib table meant your entry replaced (or was replaced by) whatever the donor screen set had in MachPro they coexist.


Title: Re: MachPro upgrade questions
Post by: joeaverage on September 16, 2026, 03:43:34 PM
Hi Paul,
excellent description. I do absolutely now understand how and why you have proceeded in the manner you have, and that refinement in signal handling over
what I am used to in Mach4 is to be congratulated. It is also true that I'm going to have to learn a new procedure that reflects this newer architecture, but I readily
and easily understand why the effort is worth it.

Can I also assume that any functionality that I would normally include in the Mach4 ScreenLoad script I can include in UserGUIModule.mcs?

Craig
Title: Re: MachPro upgrade questions
Post by: paul.stephens on September 17, 2026, 11:42:34 AM
Hi,

Quote
Can I also assume that any functionality that I would normally include in the Mach4 ScreenLoad script I can include in UserGUIModule.mcs?

That is correct! We Ideally want to keep any custom User logic abstracted from the main framework. It is the same way for MCodes as well. We have a UserMCodeModule that is used for MCodes. The process is slightly different for them, but the results are the same.

I'll run through the basics of the MCode as well..

How to make a new MCode:

What is an MCode?
An MCode is a command in a part program (G-code file) that makes the machine do something other than move; turn a spindle on, open a clamp, run a probe routine, and so on. MCodes look like M3 (spindle clockwise) or M30 (end of program).

Mach comes with many MCodes already built in. You can also create your own, for example, M500 could turn on a vacuum pump, open a door, or run any sequence your machine needs. This guide walks through creating M500 from scratch. The same steps work for any new MCode, just pick a number that isn't already used (numbers 500 and above are the safest choices for custom codes).

The Big Picture (two files, two jobs)
A custom MCode needs two files. Keeping them straight is the whole trick:

FileFolder PathJob / Description
m500.mcsMach\Profiles\<your profile>\Macros\The doorbell. When the machine sees M500 in a program, it looks for and runs this file. Without this file, nothing happens, ever.
UserMCodeModule.mcs     Mach\Profiles\<your profile>\Macros\Scripts\     The brain. This is where you write what M500 actually does.

Think of it this way: the machine can't call you unless you have a doorbell (m500.mcs). The doorbell's only job is to ring you. What you do when you answer is written in the brain (UserMCodeModule.mcs).

Adding a Custom MCode:
Step 1: Create the doorbell: m500.mcs
Open the folder Mach\Profiles\<your profile>\Macros\.
Create a new plain-text file named exactly m500.mcs (all lowercase; not M500.txt, not m500.mcs.txt - Windows sometimes hides the extension, so double-check).
Paste this in, exactly as shown, and save:
Code: [Select]
function m500(hVars, GcodeComment)
    return m.InvokeMacro('m500', hVars, GcodeComment)
end

if (mc.mcInEditor() == 1) then
    m500()
endYou never need to edit this file again. It simply says: "When M500 runs, go find my instructions in UserMCodeModule."

If someday you add M501, M502, etc., each gets its own copy of this file with only the number changed (m501.mcs containing function m501(...) / m.InvokeMacro('m501', ...)).

Step 2: Create the brain; UserMCodeModule.mcs
Open the folder Mach\Profiles\<your profile>\Macros\Scripts\.

Check whether UserMCodeModule.mcs already exists:

If it exists: open it in a text editor (or the Mach script editor) and skip to step 4 - you'll just add to it.
If it does not exist: create it and paste in the starter template below.
Starter template for a brand-new UserMCodeModule.mcs:
Code: [Select]
local UserMCodeModule = {}

-- Custom MCode functions go here (Step 4).

return UserMCodeModuleNow write what M500 should do. Add this function inside the file (between the two lines of the starter template):
Code: [Select]
function UserMCodeModule.m500(hVars)
    ------------------ Your instructions go below this line ------------------

    -- Example: turn OUTPUT #4 on.
    local hReg, rc = mc.mcRegGetHandle(inst, "mc.OSIG_OUTPUT4")
    if rc == mc.MERROR_NOERROR then
        mc.mcRegSetValue(hReg, 1)
    end

    ------------------ Don't edit below this line ------------------
    return true, true, w.FunctionCompleted()
end
What the parts mean:

function UserMCodeModule.m500(hVars); the name must match the MCode: m500 for M500, m501 for M501, and so on. This is how the doorbell finds the right instructions.
The middle is where you put your actual machine logic: turn outputs on/off, wait for inputs, jog an axis, write to registers, show a message, anything the Mach scripting API can do.
return true, true, w.FunctionCompleted(); the standard "I finished successfully" sign-off. Leave it as the last line.

If something can go wrong, report it like this instead of the success line:
Code: [Select]
    return nil, false, "M500 failed: vacuum sensor never turned on"Returning false as the second value stops the program and shows your message to the operator as an alarm, which is exactly what you want when a safety check fails.
Save the file.

Step 3: Try it
Restart Mach (or reload the screen script) so it picks up the new files.
Go to the MDI line, type M500, and press Enter.
Your instructions run. In the example above, output #4 turns on.
If nothing happens
Check these in order:

Optional extras (when you're comfortable)
Code: [Select]
Passing a value to your MCode. You can write M500 P1 in a program and read the P value inside your function:
function UserMCodeModule.m500(hVars)
    local pValue, ok, errMsg = m.GetMCodeLocalVar(hVars, mc.SV_P)
    if ok ~= true then
        pValue = 0   -- P word wasn't given; use a default
    end
    -- ... use pValue to decide what to do ...
    return true, true, w.FunctionCompleted()
end
Safety lockout. If M500 must not run unless a guard is closed, check that input first and return nil, false, "message" to abort with an alarm before doing anything else.

Where the GUI module fits. You may also have a UserGUIModule.mcs file in the same Scripts folder. That file is for screen behavior (buttons, the PLC script, LEDs) - not MCodes. MCode logic always belongs in UserMCodeModule.mcs. If your M500 needs something visible on screen (like an indicator), the screen part goes in UserGUIModule and the machine action stays in UserMCodeModule.

How to modify an existing MCode

First: The Golden Rule
Never edit the stock macro files. Every built-in MCode (M3, M5, M6, M8, M30, …) already has a file in Mach\Profiles\<your profile>\Macros\ - like m3.mcs - plus built-in logic inside Mach's modules. Do not edit those files, and do not edit Mach's modules. Why:

Updates will overwrite your changes. When MachPro software is updated, stock files get replaced and your edits silently vanish.
You don't need to. Mach has a built-in extension system - called hooks - designed exactly for this. Your changes go in your file: UserMCodeModule.mcs in Mach\Profiles\<your profile>\Macros\Scripts\. That file is yours; updates never touch it.

The Big Picture: Hooks
Every built-in MCode runs its job in stages, and at specific points it pauses and asks: "Does the user have anything to say about this?" Those asking-points are hooks. For example, when M3 (spindle forward) runs, it asks at these moments, in this order:
Code: [Select]
M3 starts
  → hook "m3"        (before anything happens)
  → the built-in job (start the spindle)
  → hook "m3End"     (after the job finished)
If you wrote a function named UserMCodeModule.m3 in your UserMCodeModule.mcs file, it gets called at that first hook point. If you wrote UserMCodeModule.m3End, it gets called at the second. If you wrote neither, Mach shrugs and carries on; hooks are purely optional.

Most MCodes follow this pattern: a hook named after the code (m3, m8, m6…) that runs before the built-in job, and an …End hook (m3End, m8End, m6End…) that runs after it.

Your Two Choices:
When a hook is called, your function answers one question: should the built-in job still run? Your answer is the first value you return:

Your first return value   What happensUse this to…
return true, true, ...Built-in job runs normallyAdd behavior before/after the stock job (log it, turn on an extra output, check a condition)
return false, true, ...Built-in job is skippedReplace the stock behavior entirely with your own
return nil, false, "message"Everything stops, operator sees your message     as an alarmBlock the MCode when a safety condition fails

Recipe 1: Add something before the stock job (most common)
Example: you want M3 to also turn on a "spindle running" lamp (output #5).

Open Mach\Profiles\<your profile>\Macros\Scripts\UserMCodeModule.mcs.
If it doesn't exist, create it with this starter:

Code: [Select]
local UserMCodeModule = {}

return UserMCodeModule
Add a function named after the MCode; this runs before the spindle starts:

Code: [Select]
function UserMCodeModule.m3(hVars)
    -- Turn on the spindle lamp.
    local hReg, rc = mc.mcRegGetHandle(inst, "mc.OSIG_OUTPUT5")
    if rc == mc.MERROR_NOERROR then
        mc.mcRegSetValue(hReg, 1)
    end

    return true, true, w.FunctionCompleted()   -- "true" = now run the normal M3 job
end
Save and select "Compile Scripts". In rare cases, you will need to restart Mach. Now every M3 - from a program, MDI, or a screen button - lights the lamp first, then starts the spindle as usual.

Recipe 2: Add something after the stock job
Use the …End hook instead. Example: after M5 (spindle stop) finishes, turn the lamp off:
Code: [Select]
function UserMCodeModule.m5End(hVars)
    local hReg, rc = mc.mcRegGetHandle(inst, "mc.OSIG_OUTPUT5")
    if rc == mc.MERROR_NOERROR then
        mc.mcRegSetValue(hReg, 0)
    end

    return true, true, w.FunctionCompleted()
end
Recipe 3: Block the MCode when a condition isn't met

Example: don't allow M3 unless the guard door is closed (input #2).

Code: [Select]
function UserMCodeModule.m3(hVars)
    local hReg, rc = mc.mcRegGetHandle(inst, "mc.ISIG_INPUT2")
    if rc == mc.MERROR_NOERROR then
        local doorClosed = mc.mcRegGetValue(hReg)
        if doorClosed ~= 1 then
            return nil, false, "M3 refused: guard door is open"
        end
    end

    return true, true, w.FunctionCompleted()
end
Returning false as the second value aborts the whole MCode and shows your message to the operator. Nothing else runs; the spindle never starts.

Recipe 4: Replace the stock behavior entirely

Return false as the first value. Mach skips its built-in job and considers the MCode done.

Example: your machine has no physical spindle relay; M3 should only set a register for your VFD over Modbus, and never run the stock spindle logic:
Code: [Select]
function UserMCodeModule.m3(hVars)
    -- My own spindle-start logic here (VFD register writes, etc.)
    -- ...

    return false, true, w.FunctionCompleted()   -- "false" = skip Mach's built-in M3 job
endBe careful with this one. The stock job often does bookkeeping you can't see (state tracking, status displays). Replacing M6 (tool change) or M30 (end of program) this way, for instance, can leave the control's idea of "what's happening" out of sync. Prefer Recipes 1–3 unless you're sure.

Which hook names exist?
m<code>  runs before the built-in job: m3, m4, m5, m6, m8, m9, m30, …
m<code>End  runs after the built-in job: m3End, m5End, …
Some complex operations have extra named hooks; tool change, for example, offers PreMainToolChangeCycle and PostMainToolChangeCycle.
If you're not sure which hooks a particular MCode supports, look at that MCode's Default file (read-only!) in Mach\Profiles\<your profile>\Macros\ and search Mach's modules for RunHooks("…  every name found there is a hook you can use. You can also search in:
https://support.machmotion.com/docs/current/dir_f2541a3b18981391fa76fac5599e978a.html (https://support.machmotion.com/docs/current/dir_f2541a3b18981391fa76fac5599e978a.html)

Testing and Troubleshooting
Select "Compile Scripts" or restart Mach - hooks are loaded at startup.
Trigger the MCode from the MDI line.
If your hook doesn't seem to run, check:

Quick reference
You want to…Hook nameReturn
Add before stock job     UserMCodeModule.m3     true, true, w.FunctionCompleted()
Add after stock jobUserMCodeModule.m3End     true, true, w.FunctionCompleted()
Block with alarmUserMCodeModule.m3nil, false, "message"
Replace stock jobUserMCodeModule.m3false, true, w.FunctionCompleted()
Title: Re: MachPro upgrade questions
Post by: joeaverage on September 17, 2026, 03:01:24 PM
Hi Paul,
another excellent description.

I have several Mcodes on which my work depends.

In particular m40 and m41, which were back in Mach3 days, built-in functions to open a data file, and then close it. This file would be used for storing probing or point cloud data.

I use Autoleveller, a freeware utility to probe PCB blanks and relies on storing probing data. Mach4 had some facsimilies of m40, m41 but I had to extensively modify them to use Autoleveller.
The procedures you've outlined will allow me to import those macros into MachPro.

The same advice with respects to built-in Mach4 Mcodes also applied, you risked overwriting Mach's functionality with unpredictable results. You could however do so if you chose.
For instance I have a custom m8 macro to introduce a delay when turning on the coolant pump. When Mach4 encountered an Mcode it would search, in the first instance,
in the Profile/Macros folder, ie the user file,  and enact it if it did find it. If there was no such macro in that folder then Mach would 'search up the file tree' until it found it,
usually Mach4's built-in function.

MachPro's handling of the same process is very much more structured. Sure it adds some architectural complexity but much increases the reliability of the outcome.

Also it demystifies the use of 'hooks', a term I had not previously been familiar with in connection with Mach software.

I think it fair to say that in your last two posts you have very convincingly demonstrated that MachPro is in fact a more architecturally sophisticated evolution of Mach4. All the functionality
that I regarded as essential in Mach4 is available, in fact is a subset of what is available in MachPro. All to the good. There remains now another 'bone of contention' regarding the
editability or otherwise of the screen set. This I will address it in that thread, as you have comprehensively answered my upgrade concerns in this thread.

Craig