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

Wed Jan 18 01:53:09 PST 2012

Indeed, I can only agree that USB based parallel port adapters have
very shitty timing, in no small part due to USB itself. You cannot do
motion control over USB->PP like you could straight to the parallel
port on Windows (which wasn't that great to begin with), the motion
control part needs to be located at the other end of the USB
connection. The PC should only supply "high level commands", like it
does for the controllers Dave linked.

On 18 January 2012 10:10, Dave Baldwin <dave.baldwin at dsl.pipex.com> wrote:
> Hi Bob,
>
> You don't really say what your final goal is so this may not suit your
> purpose.
>
> PC based CNC controllers are suck in the dark ages - not only for the GUI
> they present but in how they control the steppers via the printer port.
>  They rely on low level Window's drivers to generate accurate timing pulses
> (on the parallel port pins) and this process is easily disrupted by other
> system activity.  On a dedicated controller you can disable many of the
> system activities (network wifi, virus scanning, etc.) that will loose you
> accuracy, but even so the number of steps per second you can reliably
> generate is limited.
>
> If you don't have to go down that route then using a USB pulse generator
> will be a far superior solution.  Example of such a products can be found at
> http://www.planet-cnc.com/ and http://www.warp9td.com/.  In this the timing
> pulses are generated by hardware and you just supply the 4 axis motion
> vector you want over the USB bus and it generates the appropriate pulse
> trains to control the steppers.
>
> Dave.
>
>
> On 18 Jan 2012, at 02:11, Robert Rice 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
>