Re: [CAD_CAM_EDM_DRO] Mach3 & laptops

Well - it´s always good to think and look for solutions..

Artsoft does not rely on "some specific behavior of the parallel port ".
It writes directly to the port outside windows control at ring 0 on the
processor.
There is *no driver* in use.
There are not any windows-specific "virtual ports" in use.

This is an elegent solution since it solves the windows-created problem
of non-specific timing.

Thats why a usb solution must be either a smart solution like the SS
(and the gecko g-rex) or absolutely transparent hardware solution.
And also why you cannot use a "usb endpoint with timing" as there is no
virtual driver.
There is no windows involved it the driver - none. The data is pumped to
the parallel port, and sync is maintained by the driver itself. No
windows services are available at ring 0, nor are they used. The driver
then gives temporary control back to windows on the 40 us ticks.

Just thought I´d mention it.
Grin ;)

Danny Miller wrote:

>
> Well, I'm more thinking along the lines of a "smart" USB endpoint rather
> than a USB endpoint that bridges to parallel output without maintaining
> the original timing.
>
> The way I interpret this, ArtSoft relies on some specific behavior of
> the parallel port which is not guaranteed by the port's specification
> and thus only works on some hardware not others. This does tend to be
> troubling since it is difficult to guarantee it will work the way it
> does without glitches or changes in the system. But hey apparently it
> does work if you get the right hardware.
>
> With a smart endpoint (custom microcontroller- not particularly
> expensive), I don't see any reason the USB link would be unable to send
> the data with timing. The question's whether a virtual parallel port
> driver would be able to preserve the timing content Mach3 intended for
> its signals when it dumps it to the virtual port. For an generic
> virtual port driver, chances are very unlikely. For a port driver made
> to consider the timing of the signals sent to it... maybe. Not only is
> it uncertain if this could work but virtual port drivers need to be
> redesigned for different systems (XP vs Vista) which creates
> unreasonable maintenance problems. A Service Pack update could break it.
>
> Stepping back though, this seems silly to try to do this anyways what we
> need is a plugin that just talks to the USB endpoint directly, knowing
> it's a USB device rather than a USB device secretly pretending to be a
> parallel port through a virtual port driver. For that matter the
> stepper driver hardware should take in the USB cable and not route
> through a parallel port, though for existing controller hardware it
> might remain cost effective to go from USB to the parallel port on the
> controller since it'd mean replacing it otherwise.
>
> Danny
>
>
>