Messages

3571

Show"N"Tell ( Your Machines) / Re: Controller and drivers

« on: October 09, 2018, 02:15:04 PM »

Hi,

Is it possible to use Mach 4 with the ESS on a laptop? Or do I need a desktop ?

Yes, the ESS takes over all the critical timing duty from the PC and therefore the timing abilities of the PC and laptops in
particular no longer present a hurdle they once did.

I run my machine with a dual core Atom miniITX board with on chip graphics, a very low power/performance PC but it does an
entirely adequate job.

I haven't tried one of the LattePandas yet, but with 4/64G and Windows 10 installed all for $209.......

https://www.dfrobot.com/product-1585.html

Craig

3572

Show"N"Tell ( Your Machines) / Re: Controller and drivers

« on: October 09, 2018, 01:56:02 PM »

Hi,
I use the Homman Designs MB-02V6 and they are fine. Note they are TTL output, ie 5V. If you want 24V IO or optisolated or PWM
outputs then you will have to add your own circuitry. That exactly what I do, electronics is my thing, so its easy to do.

The CNC Room MB02 comes into its own if you don't want to add interface circuitry.

Craig

3573

Mach4 General Discussion / Re: Homing & Limit Switches

« on: October 09, 2018, 02:54:46 AM »

Hi,
with powerful and fast industrial machines a 'limit event' shuts the machine down instantly and totally.....its a legal requirement.

Thus an opening switch contact will cause all the electrical contactors to drop out, the spindle stops, the axis and spindle brakes come on,
hydraulic pumps stop, coolant pumps stop.....no ifs or buts....no computer required just a safety interlock circuit.

In normal circumstances you hope that a limit switch never activates, if it does, everything stops, often with tool breakage and the part being ruined.
For those situations you simply MUST have separate home switches, otherwise every time you tried homing your machine would shut down.
Remember to satisfy the law you cannot disable the limits under any circumstances.

Our hobby machines are not that powerful or fast and we can probably ignore the safety laws which apply if you are employing people to operate
machines. None the less I still advocate separate switches.

One distinct advantage is that limit switches are situated to activate at the very end of the allowed axis travel, usually that situates the switches at the ends
of the axis. Your home switch does not have to be at the end of travel and may therefore be mounted at a more convenient location with respect to
vulnerability to damage or contamination say. Also it allows you to choose switches which are optimized to the task. For instance I use roller plunger
switches for homing, they allow repeatability of better than 0.02mm but I use proximity switches for limits.

Irrespective of whether you combine limit and home switches or not there are some good precautions to take to avoid noise. Mark has already suggested
screened cable.

Another idea is to have some reasonable current flowing in the circuit at all times, say 20mA. This is another way of saying that a 'moderate impedance limit
circuit is less sensitive to noise than a very high impedance circuit or a very low impedance circuit'.

A high impedance circuit is likely to suffer from 'voltage' or 'displacement' noise whereas vey low impedance circuits are subject to 'induced current'
noise. For instance with respect to the pic attached. With the resistor of 250 Ohm as shown and a 5V supply with the switches closed about 20mA flows through
them. This circuit would still work with a resistance of 25kOhms but the current would now be only be 200uA and therefore much more prone to
capacitively induced noise spikes from an adjacent circuit. Likewise if the resistor is reduced to 20 Ohms the current is now 250mA but is now
subject to magnetically coupled noise spikes from adjacent circuits.

A little capacitance doesn't hurt either, I've shown a 1nF capacitor, you could buy ten of them for $1. You could use higher vales for more noise
suppression but eventually you will cause the speed of response to slow. If you need as much a 0.1uF you should look to find why that other
'bothersome' circuit is radiating that much noise.

Craig

3574

Show"N"Tell ( Your Machines) / Re: Controller and drivers

« on: October 08, 2018, 11:43:23 PM »

Hi,
yes they'll do the job nicely. Considerably cheaper than the Schnieder ones you linked to earlier.

You may have noted there are a couple of choices. You could use 60V units which are a little cheaper,
you would of course require a separate 60V power supply, rather denting any cost saving.

The DYN4 models are 220VAC input, yep just hook them up to the incoming mains voltage via a fuse/breaker/contactor
or whatever.....no extra power supply required. These would be preferred. Naturally if you choose the 200V drives
then you'll want the 200V servos as you have listed.

I note in one of my earlier posts I claimed the price was $147....but that was for the 60V unit.....good spotting
on your part, it so easy to make a mistake.

Craig

3575

Mach4 General Discussion / Re: Homing & Limit Switches

« on: October 08, 2018, 02:12:01 PM »

Hi,
I have always advocated having separate home and limit switches.

I suspect that when you have them programmed as dual duty that intermittent noise is affecting them.
When programmed as home switches only the occasional spurious 'home event' doesn't matter, the machine carries on. When programmed
as limits however any spurious signal will be treated as a 'limit event' and Mach will stop.

May I suggest putting a 0.1uf capacitor across each input. Note that it may slow the response to the switches to the extent that it would
be unusable in practice but may help you resolve whether in fact the problem you describe is due to noise.

Craig

3576

Mach4 General Discussion / Re: Need help with M6 Macro, translating from Mach3 to Mach4

« on: October 08, 2018, 01:52:03 AM »

Hi,
we really need to rest it on your hardware. Depending on just exactly how and when the tool-in-position switch operates could
have a major bearing on if it works.

Craig

3577

Mach4 General Discussion / Re: lua error

« on: October 07, 2018, 05:40:32 AM »

Hi madi,
the four most economical and capable boards are:

https://warp9td.com/ The ESS is the model of choice.
https://www.cncdrive.com/UC300ETH.html The UC300ETH is the model of choice.
https://www.poscope.com/product/pokeys57cnc/ The Ethernet 57CNC is the model of choice.
http://www.pmdx.com/pmdx-424 The 424 is the model of choice.

A rather more expensive unit but very capable, especially if you have old DC servos to deal with is:
http://www.vitalsystem.com/portal/motion/hicon/hicon_integra/hicon_integra.php

All of these companies support their products and they work as advertised and all have been around for years.

Each of these boards are slightly different from each other, some has this feature but not that one and so on.

Prehaps not surprisingly the Vital Systems Hicon, the most expensive one, has the most developed features including THC, the only one so far to
have it.
Warp9 are trying to catch up, they have just added lathe threading and backlash compensation.
PMDX is the dark horse here, very good lathe threading capability but no Backlash compensation.
The UC300 is a relative newcomer to Mach4 (been doing Mach3 for years) and so has fewer features but a good value board with lots of IO.
The 57CNC has good balance of features, flexible IO with good analogue features.

There are some other differences also....the ESS and the UC300 really require BoBs. I personally favour the simple and cheap BoBs because my
electronics skills allow me to adapt a cheap board to my requirements. If your electronics is not good then more sophisticated BoBs are
probably right for you the MB02 is a good choice for the ESS and a UB1 for the UC300. The PMDX doesn't require a BOB, its built in and has its own
power supply and makes an appealing choice for a no fuss solution.

In truth while they are all subtly different they all work GREAT....any of them will be a much MUCH happier experience than your XHC board.

Craig

3578

Mach4 General Discussion / Re: Need help with M6 Macro, translating from Mach3 to Mach4

« on: October 07, 2018, 04:40:38 AM »

Hi.
yet another error:

Code: [Select]

local hreg=mc.mcRegGetHandle(inst,'iRegs0/TurretLock')
local hsig=mc.mcSignalGetHandle(inst,mc.OSIG_OUTPUT3)
mc.mcSignalSetState(hsig,(mc.mcRegGetValue(hreg)))
local hreg=mc.mcRegGetHandle(inst,'iRegs0/TurretAdvance')
local hsig=mc.mcSignalGetHandle(inst,mc.OSIG_OUTPUT4)
mc.mcSignalSetState(hsig,(mc.mcRegGetValue(hreg)))
It getting late in the day and I'm making all sorts of mistakes....my apologies to those of you trying to follow what I'm doing.

Craig

3579

Mach4 General Discussion / Re: Need help with M6 Macro, translating from Mach3 to Mach4

« on: October 07, 2018, 04:13:03 AM »

Hi,
gross error in the PLC script, try this instead:

Code: [Select]

local hreg=mc.mcRegGetHandle(inst,'iReg0/TurretLock')
local hsig=mc.mcSignalGetHandle(inst,mc.OSIG_OUTPUT3)
mc.mcSignalSetState(hsig,(mc.mcRegGetValue(hreg)))
local hreg=mc.mcRegGetHandle(inst,'iRegs0/TurretAdvance')
local hsig=mc.mcSignalGetHandle(inst,mc.OSIG_OUTPUT4)
Craig

3580

Mach4 General Discussion / Re: Need help with M6 Macro, translating from Mach3 to Mach4

« on: October 07, 2018, 04:01:46 AM »

Hi,
I have had some more thoughts about using the registers vs the ISIG_INPUTnnn and OSIG_OUTPUTnnn.

Part of me is convinced I need to use registers so that the data can be used by both the GUI AND Machs core Gcode processor.
The problem as evidenced by the code I have written is that I seem to be duplicating everything.

I realize now what I can do.

We have two input signals from the index and position switches on your turret. They have to be treated as input signals, ie ISIG_INPUT....
That's how we have treated them and recalling the code which we placed in the SigLib table:

mc.ISIG_INPUT3]=function(state)
   local hreg=mc.mcRegGetHandle(inst,'iRegs0/ToolIndex')
   if state==1 then
      mc.mcRegSetValue(hreg,1)
   else
      mc.mcRegSetValue(hreg,0)
   end
end,
[mc.ISIG_INPUT4]=function(state)
   local hreg=mc.mcRegGetHandle(inst,'iRegs0/ToolPosition')
   if state==1 then
      mc.mcRegSetValue(hreg,1)
   else
      mc.mcRegSetValue(hreg,0)
   end
end,
the registers ToolIndex and ToolPosition will always be in lockstep with ISIG_INPUT3 and ISIG_INPUT4. Thus I don't need to use Signal APIs to read the
inputs, just use the Reg APIs instead.

The question is how do we deal with the outputs? The outputs must use the OSIG APIs to cause the output pins of your controller to operate.
However we wish to use the registers TurretLock and TurretAdvance internally. This can only happen if you duplicate the API calls, hardly
code efficient and worse it will fail when Machs Gcode processor is running and starves the GUI of service then the OSOG_OUTPUT APIs wont work.

The answer is that OSIG_OUTPUT3 must be in lockstep with TurretLock and OSIG_OUTPUT4 with TurretAdvance.
This can be achieved by a few lines of code in the PLC script.

This is the code I will put in the PLC script:

Code: [Select]

local hreg=mc.mcRegGetHandle(inst,'iReg0/TurretLock')
local hsig=mc.mcSignalGetHandle(inst,mc.OSIG_OUTPUT3)
mc.mcSignalSetState(hsig)=mc.mcRegGetValue(hreg)
local hreg=mc.mcRegGetHandle(inst,'iRegs0/TurretAdvance')
local hsig=mc.mcSignalGetHandle(inst,mc.OSIG_OUTPUT4)
This will allow some simplification of the two macros we have written thus far:

Code: [Select]

function m180()
-- Lock the turret.
local inst=mc.mcGetInstance()
local hreg=mc.mcRegGetHandle(inst,'iRegs0/TurretLock')
if (mc.mcRegGetValue(hreg)==0) then
mc.mcRegSetValue(hreg,1)
end
local rc=mc.mcSignalWait(inst,mc.ISIG_INPUT4,1,11)
if (rc==mc.MERROR_NOERROR) then
elseif (rc==mc.MERROR_TIMED_OUT) then
wx.wxMessageBox('Turret failed to lock')
return
end
mc.mcCntlSetLastError(inst,'Turret Locked')
mc.mcRegSetValue(hreg,0)
end
if (mc.mcInEditor()==1) then
m180()
endAnd m185:

Code: [Select]

function m185()
--Advance the Turret
local inst=mc.mcGetInstance()
local hreg1=mc.mcRegGetHandle(inst,'iRegs0/TurretLock')
local hreg2=mc.mcRegGetHandle(inst,'iRegs0/TurretAdvance')
local hreg3=mc.mcRegGetHandle(inst,'iRegs0/TurretPosition')
if (mc.mcRegGetValue(hreg1)==0) then
mc.mcRegSetValue(hreg1,1)
end
mc.mcRegSetValue(hreg2,1)
local rc=mc.mcSignalWait(inst,mc.ISIG_INPUT4,1,10)
if (rc==mc.MERROR_TIMED_OUT) then
wx.wxMessageBox('Turret failed to Advance')
return
end
mc.mcRegSetValue(hreg2,0)
--********************************************************************
local inst=mc.mcGetInstance()
local hreg=mc.mcRegGetHandle(inst,'iRegs0/TurretLock')
if (mc.mcRegGetValue(hreg)==0) then
mc.mcRegSetValue(hreg,1)
end
local rc=mc.mcSignalWait(inst,mc.ISIG_INPUT4,1,11)
if (rc==mc.MERROR_NOERROR) then
elseif (rc==mc.MERROR_TIMED_OUT) then
wx.wxMessageBox('Turret failed to lock')
return
end
mc.mcCntlSetLastError(inst,'Turret Locked')
mc.mcRegSetValue(hreg,0)
--************************************************************************
local hreg4=mc.mcRegGetHandle(inst,'iRegs0/TurretPosition')
local currentTool=mc.mcRegGetValue(hreg4)
local currentTool=currentTool + 1
if (currentTool==6) then currentTool=0 end
mc.mcRegSetValue(hreg4,currentTool)
end
if (mc.mcInEditor()==1) then
m185()
end

Craig