Re: [CAD_CAM_EDM_DRO] Mach3 & laptops

I don't think the stuff you're covering about USB is correct. USB has
several different classes that communication can take and are handled
slightly differently. USB does deal with time-critical, high bandwidth
peripherals like video capture. Some of the motion controllers Mach 3
supports *are* USB. But I assume the peripheral is "smart" on what it
needs to do, buffers the signal and handles the timing itself, which a
USB-to-parallel cable is most definitely not.

It sounds like the problem is where Mach 3 set out to be able to save
people quite a few bucks on motion controllers by controlling the
stepper drivers directly. And it succeeded at that mission (which is
pretty cool), but with caveats that mean only some hardware works. Heck
my "real" computer here that I actually use doesn't even have a parallel
port.

Is there a homebrewed a USB or ethernet driver? I should mention I'm
quite experienced at microcontroller projects and this is right up my
alley. In fact I'd like to get into more complicated CNC tasks and
working with hardware I know and designed would be "nice". It would be
nice to work with my laptop too rather than an old stripped-down system
that I can't put development software on. I see where Mach 3 has a
plugin for ext motion controllers, but is the standard proprietary?

Danny

David Speck wrote:

>
> Dan,
>
> There is a big difference between sending data to a printer and what
> Mach3 does with a parallel port.
>
> A printer doesn't have any time-critical features to its data stream.
> It just accumulates the received character data in its internal buffer
> memory until it has a full page's worth and then begins the print
> cycle. Small pauses and hiccups in the data stream have no effect on it.
>
> OTOH, Mach3 is actually putting out step and direction pulses that
> directly drive stepper motors. The uniformity of the pulse rate and
> synchronization between all 4 output axes is critical. If you have a
> disruption of the pulse stream, you will get a defect in the finished
> part, or worse, break your cutting tool.
>
> When a program prints to a printer under Windows, it sends a character
> to the printer driver, which in turn passes it on to the Windows kernel
> which sends it to the spooler which keeps it around till the printer is
> ready to accept it. This is a low priority process that happens
> eventually when Windows "gets around to it". Mach3, OTOH, writes
> directly and immediately to the chip register that controls the
> parallel output port wires, totally bypassing all of Windows' internal
> processing. This direct bit banging access is critical to keeping the
> timing of all the step and direction signals coordinated. On some
> machines, Mach3 can calculate and output 100K to 400K pulses per second
> with reliability. With its massive processing overhead burden, there's
> practically nothing that Windows can to reliably at 400K times per
> second, or even 40k times per second for that matter, even on the
> fastest machines available. Windows just plain wasn't designed to do
> that.
>
> USB stands for Universal SERIAL Bus. Even though it may look like a
> parallel output to the Windows driver, a data byte is received in a
> shift register at the computer end, and, when the USB bus is not busy,
> it is sent out in bit serial format onto a single wire in the USB cable,
> along with a bunch of addressing and checksum information to a receiving
> register at the end of the converter cable, where it is reassembled into
> a parallel format. This transmission also takes place on a "whenever we
> get around to it" schedule, that would be wholly unacceptable for the
> high speed timing that Mach3 requires. Thus, you cannot use a USB
> parallel port emulator.
>
> The fact that your laptop onboard serial interface was unreliable is a
> good indicator that the CPU was so busy doing "other things" that it
> didn't have time to properly read the input registers of the serial port
> chip on the motherboard before data was lost. Installing the USB SIO
> added additional layers of buffering that made the system more reliable.
>
> The need for precise timing also explains why you have to use a system
> with a separate video card, rather than an integrated video system on
> the motherboard. With motherboard video, the display generator and the
> CPU split access to the main system RAM. When the Video generator needs
> to display a line of video, it freezes the CPU, takes what it needs from
> memory, and then releases the CPU again. The sharing arrangement makes
> the CPU seem a bit slower than it could be to the user, but it is not
> critical to typical Windows program operation. However, Mach3 is
> definitely not a typical Windows program, and this operating mode would
> be entirely incompatible with the operation of Mach3. With a separate
> video card, the video card has its own private memory, so generating the
> display data doesn't require suspending the CPU operation.
>
> I'm not sure if Mach3 will run under Win NT or 2K, but you might want to
> check. These predecessors to XP don't require registration, and are
> fast and have very small footprints, and are available for next to
> nothing now. Better check with the Mach3 website for compatibility.
>
> Dave
>
> Danny Miller wrote:
> > Ha actually I do have a old machine... which I snagged off the curb at
> > heavy trash day. For this reason. BIOS shows a 4GB hard drive and
> > pretty old AMD processor. I would have liked to avoid trying to get it
> > working and all but it is an option. Might be a good idea to keep the
> > laptop out of the garage anyways. Does it run ok on old-ass systems?
> > I'd probably put a fresh install of XP on it, a wireless networking
> > card, and nothing else to clutter it.
> >
> > Well on the USB-to-serial cables, those use a virtual port driver that
> > makes a new COM port show up. Any program can use it just like any
> > other COM port they don't know the difference. I assume a
> > USB-to-parallel cable would work the same way but I certainly wouldn't
> > be surprised if Mach3 had a problem working through the virtual port
> > driver and physically being bridged through different hardware.
> >
> > On the other hand, I can say this- my laptop had mega problems running
> > through the built-in serial port at high speeds. Started dropping
> > characters, probably just overran some lousy slow part of the
> > southbridge design. Well, when I switched to the USB-to-serial and ran
> > the serial data through that, all those problems went away. So, it's
> > sort of "plausible" that a USB-to-"X" cable could perform better if the
> > motherboard had problems. I'm skeptical though. Andy Wander says "no
> > way" so it may be a waste of time to try.
> >
> > Danny
> >
> > David Speck wrote:
> >
> >> Danny,
> >>
> >> The problem is not with accessing the parallel port, but with the
> >> internal timing of the Mach3 program.
> >>
> >> Mach3 uses a special kernel mode software driver which is necessary to
> >> provide high precision timing required to get all the various step
> >> pulses out the door at the precise instant needed for a proper cut.
> >> Laptops have all sorts of integral proprietary hardware with special
> >> drivers that confuse the dickens out of Mach3.
> >>
> >> When you get down to it, it's pretty amazing that Mach3 works as
> well as
> >> it does, considering that even on a desktop, Windows is a highly
> >> non-deterministic operating system. It takes a lot of high power
> >> programming on Mach3's behalf to make sure Windows does not decide that
> >> NOW is the time it has to do a defrag, just as you are half way through
> >> the 4167th line of your G-code program. Laptops just add a whole
> >> 'nother layer of complexity to the issue.
> >>
> >> Since Mach3 will run just fine on an old Pentium 3 that you can
> snag for
> >> free at curbside on trash day, it's just not worth the developers'
> >> effort that would be required to make it compatible with laptops,
> >> particularly when nearly every laptop is a collection of custom parts.
> >> (Have you ever tried to buy a replacement keyboard or LCD for a laptop?
> >> -- essentially every model is unique, and the corresponding internal
> >> software drivers are similarly unique).
> >>
> >> I'm pretty sure that Mach3 directly writes to the parallel port I/O
> >> pins, and will not work on a USB to Parallel adapter, at least not in
> >> the versions that I was familiar with.
> >>
> >> HTH,
> >>
> >> Dave
> >
>