Hi Bob;
Interesting that you should ask this question. I just got back from Cabin Fever at which I attended a good course about CNC on PCs. At least in the context of USB there is a lot of negativity with trying to do CNC control over that port on Windows. Especially if you are attempting to do high performance as you will struggle to get consistent performance. There was also a lot of talk about a "SmoothStepper" board that is coming out in an Ethernet version. I'm not sure if it is completely out of beta but the reports are that it eliminates issues associated with USB. In any event it seems that CNC over USB is bad voodoo on Windows. The problem is I'm not sure if this is also a problem with the Mac. The Mac is a vastly different platform and Apple has implemented the USB stack differently than Microsoft under Windows. So I can't say how bad implementing CNC over USB on a Mac would be. There is a guy that has a bit of CNC software written that works under Linux and MacOS, unfortunately I don't have a link at the moment. You might want to search a bit for that software as it could use a good interface. On the Mac your best bet might be Thunderbolt. A parallel interface over that link shouldn't have any problems. Beyond that though you need real time control to drive the step and direction signals directly. I just not sure if Mac OS has the real time capabilities to do this. Best performance in CNC control comes from a minimum of jitter in pulse timings. This comes back to why things like Smooth Stepper have been developed, CNC is a hard real time problem as such it requires hardware that can operate in that realm. I would suggest looking at LinuxCNC.org on the net to get one perspective On the state of CNC control on PC hardware. LinuxCNC (formerly EMC) is nice software, it would be very nice to see it ported to the Mac. Even if you just ran the GUI on the Mac you could bring a very useful capability to the Mac. Sent from my iPad On Jan 17, 2012, at 9:11 PM, Robert Rice <rice.au...@pobox.com> wrote: > Hi, > > I've become interested in Computer Numeric Control (CNC) machine control. I > find there is very little support for the Macintosh platform and many PC > programs for the task have a crude user interface so I would like to create a > Macintosh CNC application using MacRuby. > > CNC programs and motor drivers generally use the LPT parallel port output > from a PC in the basic unidirectional mode. Most PC CNC apps do not support > PC laptops due to processor sleep logic interfering with stepper motor > timing. I would need a similar fast interface on the Mac. > > I have a Prolific 2305 based USB to IEEE 1284 adapter cable that I would like > to use. Mac OS recognizes the device as an "IEEE-1284 Controller" in the USB > device tree and I can add a generic print queue for the device, but I don't > know how to connect to the device at high speed as the printer controller > does. > > Prolific provides documentation for the simple report protocol for the > device. I suspect that an appropriate driver already exists for this device > but how would I find it? > > Thanks, > Bob Rice > > > On Jan 17, 2012, at 2:27 PM, Alan Skipp wrote: > >> Hi folks, >> just a quick note (followed by a question) to let you know that my GCD >> rendition of ruby 1.9's most used feature – Fibers, is nearing completion. >> Code here: >> >> https://github.com/alskipp/MacrubyFibers >> >> Currently passes 51 expectations from the fiber spec. 3 failures, all >> related to raising exceptions, 2 of which can't be solved just yet as >> Macruby doesn't raise LocalJumpError for errant procs. The final test >> failure I'd like to fix, so here's the question… >> >> When executing code on a serial dispatch queue, how can I raise an exception >> on the main queue? The following works in an Xcode project: >> >> Dispatch::Queue.new('serial_queue').async do >> Dispatch::Queue.main.sync do >> raise "Exception from #{Dispatch::Queue.current}" >> end >> end >> #> Exception from com.apple.main-thread (RuntimeError) >> >> My assumption is that this works because it is executed within an >> application run loop. The same code does not work if invoked directly by >> Macruby, presumably due to the lack of an application run loop, Macruby >> exits before the Exception can be raised on the main queue, sometimes >> resulting in a EXC_BAD_ACCESS crash. >> >> Is there an alternative approach? >> >> Cheers, >> Al >> >> >> On 10 Jan 2012, at 18:44, Joshua Ballanco wrote: >> >>> Hey Alan, >>> >>> Awesome! I haven't had a chance to go through the code in detail, but I >>> like the general approach. I'll definitely be looking into this in more >>> detail later, but for now I just wanted to let you know that there are >>> specs for Ruby 1.9's fibers in the MacRuby repo at >>> 'spec/frozen/library/fiber'. It would be interesting to see how many of >>> them pass with your implementation. >>> >>> Cheers, >>> >>> Josh >>> On Thursday, January 5, 2012 at 10:36 AM, Alan Skipp wrote: >>> >>>> Hi everyone, >>>> I've had a go at implementing Fibers using dispatch queues. The code can >>>> be found here: >>>> >>>> https://gist.github.com/1565393 >>>> >>>> Inspiration was taken from the following ruby 1.8 Fibers implementation: >>>> https://gist.github.com/4631 >>>> >>>> The implementation of Fiber.yield currently relies upon a hash stored as a >>>> class variable. This is hopefully just a temporary solution to get things >>>> started. The hash is always accessed through a serial queue (so it should >>>> be thread safe) and dead fibers are removed after use. There are a couple >>>> of GCD functions that look like they could be used to solve this problem: >>>> 'dispatch_queue_set_specific' and 'dispatch_set_context'. Though I'm not >>>> sure how to use these from Macruby. If anyone has any experience using >>>> either of those GCD functions I'd be interested in learning more. >>>> >>>> The major omission currently is the lack of a 'transfer' method. I've >>>> pondered this quite a bit, but I've yet to come up with a solution. It is >>>> quite possible that the way I've written the Fiber class prevents a >>>> successful implementation of a 'transfer' method - but I've not given up >>>> just yet. If anyone has a cunning plan on how to achieve it, that would be >>>> great. >>>> >>>> I've tested all the examples here: >>>> http://pragdave.blogs.pragprog.com/pragdave/2007/12/pipelines-using.html >>>> >>>> and they all seem to work, plus I've included a few tests in the gist. >>>> The test which creates a fiber from Fiber.current, causes macruby to >>>> crash, but I don't know why - it doesn't cause a crash when invoked >>>> normally outside of minitest. >>>> >>>> From my limited tests, everything other than the 'transfer' method appears >>>> to be working, but feedback would be welcome if you discover any problems. >>>> >>>> Al >>>> _______________________________________________ >>>> MacRuby-devel mailing list >>>> MacRuby-devel@lists.macosforge.org >>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> >>> _______________________________________________ >>> MacRuby-devel mailing list >>> MacRuby-devel@lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> _______________________________________________ >> MacRuby-devel mailing list >> MacRuby-devel@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > _______________________________________________ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
