<rant> On Thu, Feb 24, 2011 at 1:35 PM, Phillip Hallam-Baker <hal...@gmail.com>wrote: <snip>
> Windows is not built to support real time. Although rather ironically the > original kernel was. It is pretty difficult to timeshare a machine between > real time tasks and supporting a GUI with real-time response. One or the > other is going to end up taking precedence. > Lucky for us all that hard work was already done and we get it for free :) > The problem with USB is that it is a contended bus. So even if your host is > running in real time there is no guarantee that signals get out to the end > points in real time. That is why there is still a demand for MIDI > interfaces > despite them being much slower than USB. > Good thing we can still buy brand new, cheap motherboards with an even better real-time port on them :) Everyone says the parallel port is legacy and could disappear any day, but when they still put them on dirt-cheap boards like the D510MO, it suggests to me that the parallel port and the x86 PC architecture will likely die a shared death. IMHO the *only* reason to build an outboard step generator (read: parallel port alternative) is to support connection via USB, which is found on almost every PC-like device under the sun. > I would really prefer to have separate CPUs dedicated to scheduling and > GUI. > That way I don't have to worry about keeping the timing clean over the data > wires, the only timing sensitive wires are carrying the signal. > Again, the Linux RT patches make this problem largely moot. You test your machine's jitter, and if it passes, then it will work. > If I could eliminate the parallel port requirement, I can eliminate the > need > for a separate controller box entirely and just bring down one of the > laptops when necessary. > That would be nice but when a good control PC can be had for $0-$200 it seems like penny wise and dollar foolish. In my view, you're not really simplifying the system, you're dispersing the same starting amount of complexity which by definition makes the overall system more complex. That alone strikes me as a real liability. I get why Mach users want these things, they are chained to an OS that is fundamentally mis-specified for this purpose. There's an old saying about tools, "buy the best and only cry once." That is how I feel about EMC and the parallel port. You gain a lot of benefits by staying within a large, well-tested, widely-used stack of tools. If someone wants to build a USB step generator for EMC because the problem fascinates them, then more power to them. If you can make them for $100 or less MSRP, you could probably sell quite a few. Heck, I've thought about taking this on for just that reason. But, even if you succeed, at the end of it all, all you have is a machine that sends step/dir signals over a cord with 4 wires instead of 25. Your machine won't do anything mine can't. In my view, this is a very expensive solution to a fairly easily-solved problem that doesn't really advance the state of the art in a hugely useful way. IMHO, there is perhaps a place for this type of thing for use on toy CNC machines like the desktop Dremel routers and such that people build for a couple hundred bucks. In these cases the cost of a control PC is significant and the machine is built more for the "cool look at it go!" factor than anything else. For this, several people have built complete controllers on Arduino boards that can interpret G-code and generate control signals directly (e.g. rStep and GRBL). The PC just drip feeds G-code and provides a GUI for manual control. These don't implement trajectory planning, coordinate systems, tool comp, home switches, etc. but for a machine that likely will spend its life cutting peoples' names into balsa (or maybe engraving PCBs at the high end), none of these are needed. And I don't mean to denigrate these as they are a gateway for newbies, a few of whom, like me, will get hooked and move up the ladder to more powerful systems. And if people want to contribute to open source tools in this, there are areas of great need--we could still use a lot of work around GUIs and related tools, and the open source CAD/CAM stack is still *very* thin and user-unfriendly. None of this is meant as a slam against Dan Heeks or any of the folks here who've contributed so much and helped us get to where we are, but these are truly large challenges and they could certainly use more hands :) </rant> ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
