Re: [CAD_CAM_EDM_DRO] USB and ncPOD system
Posted by
R Rogers
on 2007-05-24 10:48:55 UTC
Selling machines, there is a learning curve with new users and the software. Mach3 has an easy to learn and use interface, huge priority and consideration in regards to support. With almost zero problems in normal usage. When I mention to a customer the machine will run on EMC, they ask "does that run on Windows?" And when I inform that it does not, they go right back to Mach3. Folks in general want no part of Linux or learn a new OS in general as well as tackle new to them CNC. Although, I do have one customer running on a Linux system, and he reports the machine performs satisfactorily. However, that is the only equipment failure I've had in the field as well, a drive blew myseriously while running for no reason.
I keep reading these references to XP and Mach3 being potentially problematic by design. This is just not the case. Everyone I've dealt with has not had the first issue using WindowsXP with Mach3. Even have quite a few running from laptops. I have it on 4 Windows boxes here and no issues. Use it daily, no issues. And the claim that Mach's threading ability is suspect, is simply not the case either. Mach has a very large user base. Follow the support closely. If there is an issue, it's resolved quickly or more often it's generally the user themselves just learning CNC. The only big issue with Lathe right now is feedback pertaining to the stand alone controllers.
My own opinion, this is going to be a huge hurdle to clear if even possible, here's why I say this:
First, from what I understand, the problem isn't in the standalone device, the firmware or Mach3. It's Windows based communication protocol and their characteristics. They are what they are.
Secondly, Some very competent folks have been working with it for a good number of years and it has not been resolved. What it's going to take, I have no idea, but I can safely say the solution is more than a few strings of code. If it was easy, I thnk it would have already happened.
Thirdly, As long as someone can connect a parallel port to to an inexpensive breakout board and take advantage of all that MAch and a PC has to offer, there isn't going to be much support or interest for anything else. And Parallel ports will be around for a long time. Someone somewhere will offer a motherboard with PCI slots. Too much equipment out there that uses it. And trying to increase computing power on a stand alone device is nothing more than creating another computer. Which incidently reflects billions of dollars in development. As Art recently stated "the math doesn''t lie" On programs consisting of multi segment lines with thousands of lines of code, these devices just can't keep up with the PC and Mach3. One stand alone can read 100 lines of code per sec, another reads 1000 lines per sec, and the parallel port can read and issue 25,000 lines of code per second. It's going to boil down to the standalones will be cleaner and much faster on some apps, and not
do as well as the Pport on others. Which does well on all apps with reasonable resolution.
Disclaimer:
Some info, a few facts and mostly opinion which "may" or "may not" be accurate :-)
Ron
Lester Caine <lsces@...> wrote:
Stephen Wille Padnos wrote:
1024 slot encoder with the current build of EMC2 to provide the sort of
control we were discussing. It's already been done :)
--
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
[Non-text portions of this message have been removed]
I keep reading these references to XP and Mach3 being potentially problematic by design. This is just not the case. Everyone I've dealt with has not had the first issue using WindowsXP with Mach3. Even have quite a few running from laptops. I have it on 4 Windows boxes here and no issues. Use it daily, no issues. And the claim that Mach's threading ability is suspect, is simply not the case either. Mach has a very large user base. Follow the support closely. If there is an issue, it's resolved quickly or more often it's generally the user themselves just learning CNC. The only big issue with Lathe right now is feedback pertaining to the stand alone controllers.
My own opinion, this is going to be a huge hurdle to clear if even possible, here's why I say this:
First, from what I understand, the problem isn't in the standalone device, the firmware or Mach3. It's Windows based communication protocol and their characteristics. They are what they are.
Secondly, Some very competent folks have been working with it for a good number of years and it has not been resolved. What it's going to take, I have no idea, but I can safely say the solution is more than a few strings of code. If it was easy, I thnk it would have already happened.
Thirdly, As long as someone can connect a parallel port to to an inexpensive breakout board and take advantage of all that MAch and a PC has to offer, there isn't going to be much support or interest for anything else. And Parallel ports will be around for a long time. Someone somewhere will offer a motherboard with PCI slots. Too much equipment out there that uses it. And trying to increase computing power on a stand alone device is nothing more than creating another computer. Which incidently reflects billions of dollars in development. As Art recently stated "the math doesn''t lie" On programs consisting of multi segment lines with thousands of lines of code, these devices just can't keep up with the PC and Mach3. One stand alone can read 100 lines of code per sec, another reads 1000 lines per sec, and the parallel port can read and issue 25,000 lines of code per second. It's going to boil down to the standalones will be cleaner and much faster on some apps, and not
do as well as the Pport on others. Which does well on all apps with reasonable resolution.
Disclaimer:
Some info, a few facts and mostly opinion which "may" or "may not" be accurate :-)
Ron
Lester Caine <lsces@...> wrote:
Stephen Wille Padnos wrote:
> Tony Jeffree wrote:Actually Tony there has just been a nice thread on the EMC list about using a
>>> The ability to download gCode DIRECTLY
>>> to ncPod and run it from there may well provide a solution to the lathe
>>> problem since it would not require a return path to the host computer.
>>>
>> That would only provide a solution if the ncPod firmware is able to
>> handle inputs from the encoder and modify its step rates accordingly.
>> If that was possible it would significantly increase the appeal of
>> the 'pod - right now I am looking for a solution to the lathe problem
>> for my ongoing of Myford conversion.
>>
>>
> Tony, meet EMC2. EMC2, meet Tony. :)
> <http://www.linuxcnc.org/>
1024 slot encoder with the current build of EMC2 to provide the sort of
control we were discussing. It's already been done :)
--
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
[Non-text portions of this message have been removed]
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