Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Posted by
Lester Caine
on 2007-05-24 12:51:36 UTC
R Rogers
Now that you have top posted I'll oblige by doing the same.
But I'll trim the rest of the message.
There ARE areas that windows is totally incapable of supporting, but the
current discussion is about how we can run spindle synchronised machining.
Mach3 does this using a small number of pulses per revolution simply because
it can't get a faster encoder signal back through windows. This approach only
works if you can maintain a steady spindle speed, and it does work as long as
you remain within the limits.
The more accurate method is to use a high resolution encoder which requires a
controller that can handle the input and produce drive pulses to one or more
linear axis at a variable rate that can be controlled. Simple screw cutting
would just use a single rate reduction to a single axis, but the real target
is the ornamental turning market where you need to vary the rate and also the
cut depth depending on position along the work and around the work. Something
that a single pulse per rev would have even more difficulty with.
We have several options as HOW to do this from hard coded 'electronic
gearboxes' such as ELS provides, through the various real time modules - which
may or may not have suitable code yet - to the co-processor market such as
GREX and ARCNC100. None of those devices will be running windows, so the fact
that they MAY be running Linux is not really relevant. They need a real time
operating system that can handle the problem - Linux - as I had already said -
has the advantage that any of us who are capable can get involved, while the
likes of GREX, ncPod and USBCNC are restricted to those who have access to the
code.
Now the user interface TO the co-processor is a different problem and *YES*
windows is the preferred option, and probably running Mach3. But it does not
HAVE to be and if properly set up, a co-processor that accurately runs a set
of gCode downloaded to it does not NEED all the eye candy in order to work.
You just need messages when to change tools if you can't run to an automatic
tool changer. So I supply an ITX based computer with all the machines I sell -
currently just running Mach3, and nothing else, but if I want to supply a more
powerful solution Linux is an option rather than having to add the cost of
additional hardware and it actually costs somewhat less then the Mach3/XP
option simply by removing those licences ( and I could run a slower cheaper
ITX board). So if that is providing the co-processor can I really justify a
second computer just to provide a windows front end? I would rather make it a
slave of the design computer - and just download gCode direct from the design
programs. No need for Mach3 at all, and the nc-machine just runs stand alone?
So did your ranting have any connection with the points being discussed?
( Weather windows is going to survive is an argument I will not waste time on
here. Let me just say that my current business is based on supplying Linux
based information management systems to councils who are now actually
SPECIFYING them for their next upgrades - simply because they don't WANT
multimedia sound systems on staff desks :) But this *IS* off list )
--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Now that you have top posted I'll oblige by doing the same.
But I'll trim the rest of the message.
There ARE areas that windows is totally incapable of supporting, but the
current discussion is about how we can run spindle synchronised machining.
Mach3 does this using a small number of pulses per revolution simply because
it can't get a faster encoder signal back through windows. This approach only
works if you can maintain a steady spindle speed, and it does work as long as
you remain within the limits.
The more accurate method is to use a high resolution encoder which requires a
controller that can handle the input and produce drive pulses to one or more
linear axis at a variable rate that can be controlled. Simple screw cutting
would just use a single rate reduction to a single axis, but the real target
is the ornamental turning market where you need to vary the rate and also the
cut depth depending on position along the work and around the work. Something
that a single pulse per rev would have even more difficulty with.
We have several options as HOW to do this from hard coded 'electronic
gearboxes' such as ELS provides, through the various real time modules - which
may or may not have suitable code yet - to the co-processor market such as
GREX and ARCNC100. None of those devices will be running windows, so the fact
that they MAY be running Linux is not really relevant. They need a real time
operating system that can handle the problem - Linux - as I had already said -
has the advantage that any of us who are capable can get involved, while the
likes of GREX, ncPod and USBCNC are restricted to those who have access to the
code.
Now the user interface TO the co-processor is a different problem and *YES*
windows is the preferred option, and probably running Mach3. But it does not
HAVE to be and if properly set up, a co-processor that accurately runs a set
of gCode downloaded to it does not NEED all the eye candy in order to work.
You just need messages when to change tools if you can't run to an automatic
tool changer. So I supply an ITX based computer with all the machines I sell -
currently just running Mach3, and nothing else, but if I want to supply a more
powerful solution Linux is an option rather than having to add the cost of
additional hardware and it actually costs somewhat less then the Mach3/XP
option simply by removing those licences ( and I could run a slower cheaper
ITX board). So if that is providing the co-processor can I really justify a
second computer just to provide a windows front end? I would rather make it a
slave of the design computer - and just download gCode direct from the design
programs. No need for Mach3 at all, and the nc-machine just runs stand alone?
So did your ranting have any connection with the points being discussed?
( Weather windows is going to survive is an argument I will not waste time on
here. Let me just say that my current business is based on supplying Linux
based information management systems to councils who are now actually
SPECIFYING them for their next upgrades - simply because they don't WANT
multimedia sound systems on staff desks :) But this *IS* off list )
--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Discussion Thread
John Stevenson
2007-05-24 00:10:06 UTC
USB and ncPOD system
Lester Caine
2007-05-24 01:01:44 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Tony Jeffree
2007-05-24 02:09:38 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Lester Caine
2007-05-24 02:42:10 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Tony Jeffree
2007-05-24 03:05:32 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Graham Stabler
2007-05-24 04:17:01 UTC
Re: USB and ncPOD system
Peter Homann
2007-05-24 04:28:49 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
atelierrobin
2007-05-24 08:08:35 UTC
Re: Was USB and ncPOD system, CNC appliance
Alan KM6VV
2007-05-24 08:13:57 UTC
RE: [CAD_CAM_EDM_DRO] USB and ncPOD system
Stephen Wille Padnos
2007-05-24 08:28:34 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Andy Wander
2007-05-24 08:47:25 UTC
RE: [CAD_CAM_EDM_DRO] USB and ncPOD system
Stephen Wille Padnos
2007-05-24 08:58:30 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Lester Caine
2007-05-24 09:04:43 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Lester Caine
2007-05-24 09:19:52 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Stephen Wille Padnos
2007-05-24 09:33:58 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Lester Caine
2007-05-24 10:05:17 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
R Rogers
2007-05-24 10:48:55 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
atelierrobin
2007-05-24 11:40:13 UTC
Re: USB and ncPOD system
David G. LeVine
2007-05-24 11:51:10 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Lester Caine
2007-05-24 12:51:36 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Steve Blackmore
2007-05-24 13:14:07 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Steve Blackmore
2007-05-24 13:17:28 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Fred Smith
2007-05-24 13:21:33 UTC
Re: USB and ncPOD system
John Dammeyer
2007-05-24 16:10:11 UTC
RE: [CAD_CAM_EDM_DRO] USB and ncPOD system
Steve Blackmore
2007-05-24 16:23:15 UTC
Re: [CAD_CAM_EDM_DRO] Re: USB and ncPOD system
John Dammeyer
2007-05-24 16:47:41 UTC
RE: [CAD_CAM_EDM_DRO] Re: USB and ncPOD system
jmkasunich
2007-05-24 17:14:04 UTC
Re: USB and ncPOD system
Jon Elson
2007-05-24 18:13:52 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Jon Elson
2007-05-24 18:18:04 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Jon Elson
2007-05-24 18:25:30 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
R Rogers
2007-05-24 19:42:40 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Lester Caine
2007-05-25 00:33:38 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Lester Caine
2007-05-25 00:39:09 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Tony Jeffree
2007-05-25 08:29:13 UTC
Re: [CAD_CAM_EDM_DRO] USB and ncPOD system