Is it possible to remap pins in script?

My spindle is on port2/pin 14
My router is on port2/pin 17

If there was a way to remap these pins, it would solve the M3/M8 command i need.

Sometimes it is better to solve a problem with hardware (relay) instead of software.

The hardware way:

You put a relay down stream of the M3 pin and control the relay with another pin.  The relay should have a normally closed contact and a normally open contact.

Relay not energized == M3 will control the spindle: 

                 /------ -> Spindle motor start.
m3 -> ----/
                  ------ -> Router motor start. 

Relay energized == M3 controls the router.

                  ------ -> Spindle motor start.
m3 -> ----\
                 \ ------ -> Router motor start. 
                 
You use another output(pin) to energize/de-energize this relay.  This was from the concept I replied with on you first post about this dual Z machine. 

The software way:

You can remap a signal from one physical output to another with API calls.  Port2/pin14 and port2/pin17 are mapped to a Mach output singlanls, right?  These are usually mapped in the Input and Output signal tabs of the config dialog. 

Take a look at mcSignalMap() and mcSignalUnmap().  Used this in conjuction with mcSingalGetHandle() and mcIoGetHandle()

function mapSpindleFwd(to)
local inst = mc.mcGetInstance('MyPinSwapProggy')
local oSigSpindleCW = mc.OSIG_SPINDLEFWD -- constant for the output signal you are using with M3 (usually spindle forward)
local hSigSpinfleCW = 0 -- The handle to the spindle forward signal
local rc = mc.MERROR_NOERROR -- our return code variable.  It is VERY imporatant to check the API return codes!!!!

local hIoSpindle = 0 -- The handle to port2/pin14
local hIoRouter = 0 -- The handle to port2/pin17
-- Set the following to the real path in the form of devName/ioName
-- Get this information from the output signal mapping tab of the config dialog. 
local pathSpindle = 'dev/port2-pin14'
local pathRouter = 'dev/port2-pin14'

hSigSpinfleCW, rc = mc.mcSignalGetHandle(inst, oSigSpindleCW)
if (rc ~= mc.MERROR_NOERROR) then
mc.mcCntlSetLastError(inst, 'Failed to get the spindle fwd handle.')
return(rc) -- error out
end

-- Now to do the actual deed...
rc = mc.mcSignalUnmap(hSigSpinfleCW); -- unmap the existing signal.
if (rc ~= mc.MERROR_NOERROR) then
mc.mcCntlSetLastError(inst, 'Failed to unmap the spindle fwd signal.')
return(rc) -- error out
end

if (to == 0) then
hIoSpindle, rc = mc.mcIoGetHandle(inst, pathSpindle)
if (rc ~= mc.MERROR_NOERROR) then
mc.mcCntlSetLastError(inst, 'Failed to get the spindle I/O handle.')
return(rc) -- error out
end
-- Map spindle forward to the spindle.
rc = mc.mcSignalMap(hSigSpinfleCW, hIoSpindle)
if (rc ~= mc.MERROR_NOERROR) then
mc.mcCntlSetLastError(inst, 'Failed to map the spindle fwd signal to the spindle.')
return(rc) -- error out
end
elseif  (to == 1) then
hIoRouter, rc = mc.mcIoGetHandle(inst, pathRouter)
if (rc ~= mc.MERROR_NOERROR) then
mc.mcCntlSetLastError(inst, 'Failed to get the router I/O handle.')
return(rc) -- error out
end
rc = mc.mcSignalMap(hSigSpinfleCW, hIoRouter)
if (rc ~= mc.MERROR_NOERROR) then
mc.mcCntlSetLastError(inst, 'Failed to map the spindle fwd signal to the spindle.')
return(rc) -- error out
end
else
mc.mcCntlSetLastError(inst, 'Invalid parameter value!')
return(mc.MERROR_INVALID_PARAM) -- error out
end
return(mc.MERROR_NOERROR) -- success
end

-- example usage
local toSpindle = 0 -- sometimes setting up constants is easier to read later on!!! 
local toRouter = 1

rc = mapSpindleFwd(toSpindle) -- maps M3 to the spindle output.
rc = mapSpindleFwd(toRouter) -- maps M3 to the router output.


Thanks again for the time you've put into the comprehensive reply!

Why would it be better to go the hardware route instead of software?

Well, I like to use the machine control software in a manner that is closest to "box stock" so that I have to change very little if I ever upgrade the software.  For example, on my Matsuura MC500 that I retrofitted with Mach3 years ago, I ended up opting to run the tool changer with a PLC.  That decision wasn't a stroke of genius by any means!  Instead, I arrived at it because my tool changer didn't run as fast as I would have like it to when I controlled it directly from Mach3.  Anyway, I started running the tool change from a PLC which knew instantly when an input was tripped instead of waiting up to 200 milliseconds.  This made the tool changer run faster and more consistent.  Fast forward a few years and I put Mach4 on that machine.  Guess what?  I didn't have to do squat to get the tool changer working in Mach4!  My M6 macro is pretty much a 1 line affair.  All because I implemented the tool changer in hardware.  Well...  the PLC is programmed, but it is entirely self contained. 

I realize that you can't solve every problem like this.  But as a general rule of thumb, I now do as much as I can with how I build or retrofit a machine so that the machine's "personality" or how it works in not dependent on the software that runs it.  Say you get everything programmed just like you want it and 5 years later, a bolt of lightening takes your control PC out.  And it magically took out all of your configuration backups too (because we are backing everything up, right?).  Are you going to remember the special programming that you did?   

So there are some very valid reasons why one way of solving a problem is better than another.  I'm not saying that the relay is the best solution for your problem.  I just wanted to throw some different methods of solving a problem out there.  Use the best method for your machine. 

Steve

Thanks for pointing out the differences.
Will look to go the relay route.
Another thing to study into... :-)

Any idea which relay i'm using best?
Searched my electro suppliers webshop but there aren't any relays that handle the low current 24mA to activate the relay.
they all need 5mA or more.

Seems like 5mA is less than 24mA?  What motion controller are you using? 

If it gets too complicated on the hardware side, go with the software solution.  Like I said, use the best method for your machine.  You are the one retrofitting it and would know best.  I was just pointing out that there can be more than one way to solve a problem. 

Steve.

Typo - Needed to be 5A instead of 5mA.
A friend of mine will make something on a small board for the application.

For use on a ess smoothstepper

Trying to assign Output 10 for the relay but can't get it working at the moment.
Ive assigned Port1Pin1 on the ess as pinout for output 10.

iv'e tried to incorporate the piece of code you gave me into a macro but if i check the voltage on the assigned pin the voltage stays 0.

mc.mcSignalSetState(0, mc.OSIG_OUTPUT10, 1) -- marking we are using the router as Z (and possibly energize a SPDT to rout the M3 signal).
do i need to add some script in the screen script to make this happen?

Hi,
reading a signal is a two step process:
1) Get the signals handle
2) Read the state of the memory location specified by the handle.

local inst=mc.mcGetInstance()
local SignalHandle=mc.mcSignalGetHandle(inst,mc.OSIG_OUTPUT10)
local TheAnswer=mc.mcSignalGetState(SignalHandle)

Craig