Hello Guest it is September 26, 2020, 01:05:53 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 changing this:

mc.mcCntlGcodeExecute(inst, g_code)


mc.mcCntlGcodeExecuteWait(inst, g_code)

M30 in MDI is basically a no op if you don't have a pallet changer.  The other thing M30 does is rewind the file, but MDI isn't a file and MDI will not rewind.  So I'm thinking that the MDI is just plain ignoring the M30 and the ends process before the G code gets started.  Hence why I'm thinking the Wait variant of the call should be used. 

Try it and see.

Also, I see you are not checking the return code from the API call.  A lot of mysteries are solved by checking the return codes. 


You can use any port you wish, as long as the PLC and Mach's MODBUS agree on the port number.  But I doubt that is your problem.  I don't think that is the MODBUS port setting.  I think that is the general communications port setting used for communicating with other PLCs and the for connecting to the PLC with the configuration software. 

For Ethernet, your communications cassette needs to be an AFPX-COM5.  Looking at the manual on page 7-16, it doens't look like MODBUS is supported on the Ethenet interface.  Only on the serial interface.  That is just how I'm reading it, but I could be wrong.  Also, look at page 7-78 and it shows a MODBUS config dialog.  This is what I was talking about where you may have to configure the PLC to turn MODBUS on.  Their example shows linking MODBUS to one of the serial com ports, but that would be where you could link it to the Ethernet interface and set the port number. 

This is the manual I was referring to: https://www.panasonic-electric-works.com/cps/rde/xbcr/pew_eu_en/mn_63489_0013_en_fpx.pdf


Mach4 General Discussion / Re: Corrupted Machine.ini file
« on: March 26, 2020, 03:39:14 PM »
Turning off the machine without properly shutting down Windows?   


Mach4 General Discussion / Re: Remapping pin in script?
« on: March 26, 2020, 04:27:49 AM »
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. 


Here is a good dissertation on MODBUS from the people who's library we use in Mach4.  After reading it, you will most likely know more than you ever thought you would want to about MODBUS.  But...  it will help you solve your issue. 


Make sure that the PLC is listening on TCP/IP port 502 on the Ethernet.  Sometimes, you have to turn on MODBUS support! 


Mach4 General Discussion / Re: Remapping pin in script?
« on: March 25, 2020, 08:51:26 PM »
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()

Code: [Select]
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

-- 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

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
-- 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
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
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
mc.mcCntlSetLastError(inst, 'Invalid parameter value!')
return(mc.MERROR_INVALID_PARAM) -- error out
return(mc.MERROR_NOERROR) -- success

-- 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.

Mach4 General Discussion / Re: Mach4 on Parallels?
« on: March 25, 2020, 06:33:55 PM »
The demo may not even run on a VM.  And I know it will not license on a VM at all.  It is never a good idea to run a machine controller on a VM because Mach running on a VM gets even less CPU time than it would otherwise.  Buy a used computer on eBay and you will be MUCH happier. 


Mach4 General Discussion / Re: Open Builds black box
« on: March 24, 2020, 11:57:51 AM »
No.  Unless they write a plugin, it will not run.


Mach4 General Discussion / Re: Mach 4 Won't Shut Down!
« on: March 24, 2020, 12:10:02 AM »
Some plugin is keeping Mach from shutting down.  Copy your profile and launch it.  Then disable each plugin, one by one, until the problem goes away. 


Spend a bit of time learning to use the debugger.  The Zerobrane editor has a great debugger and it will show you where the issue is.  It is also very important to "compile" your macro scripts in the editor.  It will check for syntax errors.  Then run the debugger to catch runtime errors. 

Why would you use M62 in your M code?  That is to set an output that is synchronized with motion.  If you are executing M3, there is no motion!  Use mc.mcSignalGetHandle() and mc.mcSignalSetState() instead.