Messages

321

Mach4 General Discussion / Re: Mach 4 MODBUS TCP to Panasonic PLC communications

« on: March 27, 2020, 04:41:19 PM »

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

Steve

322

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?   

Steve

323

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. 

Steve

324

Mach4 General Discussion / Re: Mach 4 MODBUS TCP to Panasonic PLC communications

« on: March 25, 2020, 11:32:36 PM »

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. 

https://www.modbusdriver.com/doc/libmbusmaster/modbus.html

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

Steve

325

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


326

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. 

Steve

327

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.

Steve

328

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. 

Steve

329

Mach4 General Discussion / Re: Why won't this M3 Macro not execute in G-code or MDI

« on: March 23, 2020, 08:18:46 PM »

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. 

Steve

330

Mach4 General Discussion / Re: Use of 3d printer with Mach4 and pokeys 57CNC

« on: March 23, 2020, 04:49:38 PM »

How could I  run a extruder step motor from mach4/pokeys. How could the extruder know how much filament to extrude.

Use a step dir spindle and control the motor with the S word, M3 for start, and M5 for stop.  See the Spindle tab in the configuration dialog.

How could I control the two heaters (base plate and extruder) from mach4/pokeys. There are several thermistors on the printer to feedback temperatures.

Bring the thermistors into a compatible ADC (analog input).  Then implement a heater control in the screen's PLC script or even a PMC ladder script. 

I am hoping if I cannot run it all from MAch4, I could use the Smoothie board for the heaters and extruders and  mach4/pokeys for the Steppers.

Mach can do it.

Steve