[MacRuby-devel] CNC Machine control using USB to IEEE 1284 Parallel port adapter

Robert Rice rice.audio at pobox.com
Mon Jan 23 15:29:03 PST 2012 

Hi David,

Thanks for all the info.

I'm thinking that I can probably turn the Arduino nano into an inexpensive interpolation engine to smoothly support high micro-step rates. The Mac client would then be sending target position information and parameters for velocity, acceleration, backlash and path (if not linear) to the µP. With the motors stopped between interpolations, delays in setting up the next movement would not be a problem. It would become more complicated if trying to conserve motor momentum between interpolations, but few, if any, CNC controllers have that level of sophistication.

Thunderbolt may be very fast, but the lack of peripherals adopting it indicates that it would be difficult and expensive to use. Also, most very fast interfaces transfer data in large blocks and there could be delays in establishing each transfer. Someone could tell me if Thunderbolt is different.

Thanks,
Bob Rice


On Jan 23, 2012, at 8:04 AM, David Frantz wrote:

> 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.audio at 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 at lists.macosforge.org
>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>> 
>>>> _______________________________________________
>>>> MacRuby-devel mailing list
>>>> MacRuby-devel at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>> 
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>> 
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20120123/75f5bfaa/attachment.html>

More information about the MacRuby-devel mailing list