Messages

3501

Mach4 General Discussion / Re: jog step increment w/shuttle express

« on: November 17, 2018, 03:38:53 PM »

Hi,
while the Mach website is be re-designed the search function is on the blink.

Not sure about the shuttle pro but there are a number of API's specifically to deal with jogging. This one sets the jog inrement:

LUA Syntax:
rc = mc.mcJogSetInc(
      number mInst,
      number axisId,
      number increment)

Is it possible to have a shuttle pro button trigger a macro? If so then judicious use of this API could do the job.

Craig

3502

Mach4 General Discussion / Re: Mach4 plasma Pokey57cnc Proma Thc...

« on: November 16, 2018, 08:57:32 PM »

Hi,
you need to email them and ask specifically whether their Mach4 plugin supports THC. The last I heard is that it did not.

If you have a look on the Vital Systems website you will see that not only does their board and plugin support THC they also have
a custom THC screen that allow you to enter all the parameters.

To my knowledge Mach4 does not have such a screen. There has been some talk about NFS doing so. Various controller
manufacturers are 'waiting' for NFS to include some features like a THC screen before they work on their boards to support THC.
That's a cop out, Vital Systems have a working board and plugin AND made their own custom screen.

I have seen at various times comments from Warp9 TD (ESS), PoKeys (57CNC) and CNCDrive (UC300) all complain that because
Mach4 doesn't have such a screen 'they can't possibly support THC'. That's rubbish....its just an excuse so they don't have to do the work
and make the investment to support THC.

You need to talk to PoKeys direct and get confirmation about their support or otherwise of THC for Mach4......don't be confused by THC
support in Mach3.....you need to know about Mach4's status.

Craig

3503

Mach4 General Discussion / Re: Mach4 plasma Pokey57cnc Proma Thc...

« on: November 16, 2018, 06:54:20 PM »

Hi,
yes they sell THC controllers BUT have you confirmed they work with the Mach4 plugin?

The 57CNC certainly has THC support in Mach3 but have not heard or aware that their Mach4 plugin supports it.

Craig

3504

Mach4 General Discussion / Re: Mach4 plasma Pokey57cnc Proma Thc...

« on: November 15, 2018, 11:02:38 PM »

Hi,
I may be wrong about this but I don't believe that the 57CNC plugin supports THC. In fact to my knowledge the HiCon Integra
from Vital Systems is the only Mach4 ready external motion controller that supports realtime THC.

May I suggest emailing PoKeys and ask about the status of THC with mach4.

Craig

3505

General Mach Discussion / Re: Probing speed

« on: November 15, 2018, 03:46:59 PM »

Hi,
just to show how the calculation works I will demonstrate using the parameter of my mill, namely acceleration of 375mm/s².

At 50mm/min approach:
V=50/60
  =0.8333 mm/s
t_s=V/a
   =0.8333/375
   =2.22ms
d=0.5 * 375 * (0.00222²)
  =0.925um
ie the overrun is les than 1 um, plenty good enough accuracy.

At 100 mm/min:
V=100/60
  =1.666mm/s
t_s=1.6666 / 375
    =4.444ms
d=0.5 * 375* (0.00444²)
  =3.7 um

ie at 100mm/min the overrun is about the same as the accuracy of my machine, ie its acceptable.

At 200mm/min:
V=200/60
  =3.33mm/s
t_s=3.333/375
   =8.88 ms
d=0.5 * 375* (0.00833²)
  =14.8 um

ie at 200 mm/min approach the overrun is nearly 15um and about three times the accuracy of my machine. If I am probing normal 1 oz board,
35um copper, then the probing overrun amounts to 43% of the thickness of the copper layer which is unacceptable.

Craig

3506

General Mach Discussion / Re: Probing speed

« on: November 15, 2018, 02:36:59 PM »

Hi,
the PCB material for this board has a very heavy copper layer, 12oz/yard sq. or 420um! Normal 1 oz board has 35um
copper layer.

There are a number of consequences when using a PCB like that. First is that you cant really etch it, there is to much undercutting
to allow fine features. The second is that you can take only small step-over cuts to prevent the endmill from overloading and breaking.
My board has up to 600VDC applied and so I want 5mm clearance between adjacent tracks and at 0.2mm step over requires a large number
of repeatitions.......hence the long cycle time.

Craig

3507

General Mach Discussion / Re: Probing speed

« on: November 15, 2018, 01:01:31 PM »

Hi,
kool.

I use a software accessory called Autoleveller for probing PCB blanks. It generates a probe file which is then used to modify (slightly) the
Z height Gcodes of a PCB isolation routing file. Getting the depth of cut correct to 0.01mm (or better if you can!) is critical to the success
of making PCBs, especially surface mount boards with fine features.

I have one board 0f 135mm X 150mm and it is probed at approx. 10mm intervals with a total of 210 probe points. The Autoleveller program
actually produces the Gcode to probe the board....a bit like a Wizard....very convenient. I program it with 1000mm/min rapids between probe locations,
the initial height above the blank from which to start probing is 2mm and the probe approach speed is 50mm/min.

To probe all 210 locations takes 7 minutes, tedious but not unduly so. The routing file takes nearly 10 hours.....and requires as many as eight 0.5mm
endmills......that's pretty tedious!

I have tried increasing the probe approach speed to 100mm/min but noticed on a very small reduction in the overall time it takes to probe the board.
While I would expect 100mm/min approach to give me accurate probe results I expect more certain accuracy at 50mm/min! Given the extra time taken to
probe at the slower approach speed is only of the order of a minute I did not persevere with approaches of 100mm/min.

Where you can save some time is to start with the initial height of the probe above the board at 1mm rather than the 2mm I commonly use.
The PCB blank when double sided taped to the spoil board is flat and true to within 0.1mm or thereabouts. Thus I could probably get away
with withdrawing the probe to only 0.5mm and still be confident that it would clear the PCB and rapid to the next probe location without
contact. That would save some cycle time.

All up I tend to probe at 50mm/min......it has proven to give me accurate results to within less than the accuracy of my machine and yet fast enough
to be useful.

Craig

3508

General Mach Discussion / Re: Probing speed

« on: November 15, 2018, 12:11:32 PM »

Hi,
prior to using the SmoothStepper I used the same probing routine with a parallel port. I never measured the response.
I never felt it was necessary.

Why don't you try some different approach speeds to see if there is any measurable difference?

With one touch plate in the machine try approaching at your current 5mm/min and then try at 100mm/min.

With my current setup (Mach4/ESS) I would not expect to see any measureable difference until I get to 200mm/min approach speed.

Craig

3509

General Mach Discussion / Re: G-code limit in Mach3

« on: November 14, 2018, 07:11:31 PM »

Hi Gerry,

Actually, I think it's 10 million lines.

Now that you mention it I do recall a limit being mentioned for Mach3.

I had a thread going on the Mach4 board and smurph made reference to 3d files of up to 100 million lines!
The biggest file I've ever run is 5 million lines, a PCB routing file. On the little dual core Atom PC I use to run my machine
it takes about 4 minutes to load the file and draw the toolpath. Once it has drawn the toolpath it seems fine thereafter.
Exactly how the toolpath generation differs between Mach4 and Mach3 I don't know. It seems once the first draw is done
Mach4 runs very much more smoothly and no need to turn the toolpath off.

I can load the same 5 million line file on my i7 laptop, itself quite dated, 8G Ram,2GHz CPU in about 30 seconds including the
initial toolpath draw. Just goes to show that a more powerful PC speeds up the load/initial draw. Interestingly the much more
powerful PC (i7 laptop) performs no differently, that I can tell anyway, to the Atom once the toolplath is running.

Craig

3510

General Mach Discussion / Re: Probing speed

« on: November 14, 2018, 05:22:08 PM »

Hi,
if  I understand correctly the moment a probe event is detected the advancing axis is decelerated to a stop. If it were crash stopped
there is the potential for to lose steps and therefore the probing would be inaccurate and the machine would have lost reference.

For a given probing speed V_p and a de-acceleration (given by the motor tuning), a, then the distance traveled, d, from the probe event (t=0)
until stopped at t_s:

d=1/2 * a* t_s²
where t_s is solved from V_p=a*t _s
or:
t_s= V_p/a

(Gallieos equations for constant acceleration)

So you can calculate the overrun and effect on accuracy, or even make allowance for the overrun in the calculation of the probe point.

I probe PCB material for the purpose of applying a leveling correction. It accommodates any warp, twist or bow in the material. I normally probe at 50mm/min.
My steppers are tuned to an acceleration of 375mm/s². I have tried probing at 10mm/min and noticed no difference in the probe file that results.
I conclude therefore that the axis acceleration is such that the overrun is so small that it is masked by the lost motion (flexure + backlash) which is less than 4 um.

There is one circumstance where a significant probe inaccuracy can occur. When a probe makes contact the motion controller, be it a parallel port or an external
controller, how quickly does the controller apply the de-acceleration? In the case of my ESS the best I have been able to measure (using my storage scope)
is 15us between the probe event and the step pulse stream changing to max de-acceleration. Note that probing is supported at hardware level by the ESS.
If I waited for the probe event to be signaled to Mach4 before the de-acceleration was applied then the delay would be about 20 ms, about 10ms each way comm
delay. It would be worse, much worse, in Mach3 given the longer comm delays.

My contention is that: IF the motion controller supports probing at the hardware level resulting in near instantaneous application of de-acceleration AND the maximum
acceleration of the de-accelerating axis is reasonable THEN excepting extreme probe approach velocity the probe results will be accurate to within the flexure/backlash
of the machine.

IF however probing is programmed as opposed to realtime implementation THEN even moderate approach velocities produce significant overrun and therefore
inaccuracy.

Craig