Messages

481

Mach4 General Discussion / Re: A Question.

« on: June 27, 2014, 12:49:58 PM »

Each plug-in or device must supply its own outputs including PWM and charge pump outputs.

For a parallel port, it is the Darwin driver that will generate the signals.

482

Mach4 General Discussion / Re: Mach missing steps on glass scales?

« on: June 24, 2014, 09:38:03 AM »

Doing some rough math, I come up with a requirement for about 50,000 samples per second needed to avoid aliasing if you are trying to read this scale moving at 100 inches per minute using software.

Are you connecting your scale to a parallel port supported in software, or is this configuration using an external hardware device? Does the Darwin parallel port driver even support encoders yet?

483

Mach4 General Discussion / Re: Comments about Mach4 in Demo

« on: April 29, 2014, 10:27:02 AM »

simpson36,

It is not a simple question of using a port address that Windows does not
normally treat as a printer port. The newer versions of Windows, especially
the 64 bit versions, control ALL access to ports and memory. The only way
to get data to a device is to ask Windows to do it for you. Unfortunately
Windows wants either certified device drivers, or devices that mimic the
standard printer, USB, or Ethernet that consumers use. Note that Windows
will allow you to write to a "printer" but not to the pins of a printer port.
The difference is how it gets done. Windows will deliver all the data, just
not with the timing that you are hoping to achieve. For this reason a
printer port under Windows 64 bit or any USB "printer" device will not
provide reliable timing for the step pulses used for CNC control.

Steve Stallings
www.PMDX.com

On the topic of 'to be or not to be'  LPT port, has anyone considered targeting an address configurable LPT card?

Let's say an LPT card costs about 10 bucks. This is not going to impact any rational decision to purchase MACH4. Most new computers don't have LPT ports anyway, so purchasing an add-in card is pretty much a given.

Would it be possible to have MACH4 talk to the UART on an LPT card thru a specific address which is not recognized (and blocked) by the OS. i.e. just use the hardware on an LPT card as an 'interface' between MACH4 and existing LPT based systems. If the OS does not see the UART functioning as an LPT, theoretically it would not interfere. Many moons ago I was trying different LPT cards and several did not register with Windows as LPT ports. They had drivers that emulated the LPT and passed the data stream to the hardware on the card. Absent that driver, the OS pretty much ignored the card.

Alternately, a USB device to simply mimic the simple on/off behavior of the handful of LPT pins would not be complicated or expensive to produce. MACH4 could then just send words to the device to be decoded into the pin array that matches the LPT layout.

There are a  lot of ways to skin this cat, but the overall idea would be to have an alternative to a full motion control solution (Kflop, Smoothstepper, etc) at a low cost that would simply mimic an LPT port. If outside the OS, the valid arguments about Microsoft unexpectedly mucking things up would be eliminated.

Just thinking out loud . . .  

484

Mach4 General Discussion / Re: Comments about Mach4 in Demo

« on: April 28, 2014, 10:59:09 PM »

The parallel port has enjoyed a long and successful
life as the hardware interface of choice for many
control systems (CNC and otherwise) because it
could be manipulated directly from the control
application without interference from the operating
system.

Unfortunately direct access to hardware is a major
risk to system security in this day and age of virus
and malware programs. Because of this Microsoft is
doing everything in its power to restrict direct
access to the hardware. Art may succeed in making it
possible to run a parallel port with current versions
of Windows, but it will be a moving target and
Microsoft has an army of programmers and an almost
unlimited budget available to develop ways to "protect"
the system from unwanted access to the parallel port.
Soon the 32 bit versions of Windows that are needed to
run with direct access to the hardware may be eliminated
entirely as the consumer market transitions to 64 bit
systems entirely. It is already difficult to get 32
bit software from many off the shelf computer vendors.

At some point it becomes impractical for vendors like
Artsoft to expend large amounts of effort to circumvent
the protection measures that Microsoft creates. Artsoft
can offer us more and better software if they do not
have to focus on doing something that Microsoft does
not want them to be able to do in the first place.

Yes, we (PMDX) have a profit motive in selling alternatives
to the parallel port, but we also currently survive by
selling hardware that depends on the parallel port. We
have reluctantly concluded that the time has finally come
to figure out how to live without it in the future.

Nothing prevents users who like and depend on the parallel
port from using it along with Mach 3 and older versions
of Windows software to run systems based on the parallel
port, but this should not become a barrier to progress
for systems that do not run using parallel ports.

Regards,
Steve Stallings
PMDX

485

Video P*r*o*b*i*n*g / Re: New 3d Video Probe

« on: October 06, 2009, 11:59:51 AM »

Hello,

I am Steve Stallings, a friend of Tom Hubin's and sometimes collaborator in his video probing and other CNC efforts.

Regretably my visit to this forum is to inform you that Tom passed away this morning. Some of you who may have met him in person realize that his health was a constant challenge. He made it into his 60s despite having cystic fibrosis, quite an accomplishment in itself.

Tom was working with his probing ideas almost until the end. While I lack his skills with optics, math, and programming, I will do what I can to see that his work continues. Fortunately he managed to put most of his ideas and software into this forum and provided GPL licenses for it.

Regards,
Steve Stallings
www.PMDX.com