RE: [CAD_CAM_EDM_DRO] Re: CAM Software Advice for Shopmaster CNC

Hi Dennis,

OK. Nuff said. Clean slate.

But maybe we need to push for an open source CNC flavoured USB
interface. Here's my idea on how to do it. Hopefully I won't leave the
non-electronic/software types behind.

The biggest problem with USB is there is no guarantee when the data sent
by the application will arrive at the destination. IEEE1394 Firewire
used for Video Cameras is a bit better and faster I believe but still
suffers from the same problem.

So The EMC and MACH group have device drivers to make sure the timing
was spot on. And a 1GHz Pentium can do a lot as is demonstrated by
MACH3 or EMC2 with the Real Time Software kernel.

The alternative with the USB or Ethernet type devices is to send it
information and let the unit out there create the step/direction signals
without being bothered by Windows or Linux. (The ncPOD from oemtech.com
is one of those as is yours I'm guessing). So then the question becomes
what gets sent out?

Buy an OTS (Off The Shelf) board that has a motion controller (PMD for
example or Delta Tau) and just give it motion commands. That's done by
breaking each move into a whole bunch of smaller synchronized moves with
speed/distance parameters. Build a USB POD type device with a fast
processor like a RABBIT or DSP or even like the G100 do it all as a FPGA
(Field Programmable Gate Array).

Or, and this idea is by no means unique or mine, send out a parallel
port register image. Say for example, MACH3 or EMC is set up with a
50kHz maximum step rate. That means at worst case, every 1/50kHz or 20
micro-seconds, the PC has to update the step and direction pins on the
parallel port. What if MACH/EMC/SuperCAMXP just sent out a big block of
data every 10 milli-seconds. (0.01 seconds). That would be a maximum of
500 port images (packages) at the fastest step rate. But it could also
send out 2000 packages in that time since USB is very fast. And the USB
dongle has 4 times as much data as it needs buffered ready to go.

The USB dongle has an internal clock that runs at 50kHz. It just needs
to take the data as it comes in, grab the next package of 2 to 6 bytes
and write them ASAP out to the hardware ports with DB 25 connectors. If
an ESTOP or limit switch occurs, the USB dongle know exactly which
package # of bytes was being sent out and can send that back to the host
machine running our CAM software.

It's like staring at one of those large wall clocks during school. The
one where the second hand makes distinct ticks from second to second.
Each tick signifies a new set of step/dir/plasma torch/spindle speed
values. If something happens, the USB dongle knows when and can report
that.

If the host software wants to stop the process, the problem becomes more
difficult. In MACH type software, pressing feed hold causes the machine
to stop at the end of a movement and properly decelerate to a clean
stop. I'd suggest that the CNC software therefore not only send out
each parallel port image but also indicators representing the start/end
of each axis motion in between the packages of port information.

Now it's pretty easy (I think). A feed hold from the CAM software tells
the USB dongle to start a new sequence of step/dir motion from the
nearest motion point. I picture the Dongle constantly reporting back to
the PC CAM package telling it which set of step direction pulses it's
currently imaging out so the CAM software knows which motion point it's
at. There's definitely a delay possible but it may well be workable.

And what of the ESTOP from the CAM software? Same as the mechanical
one. The CAM software tells the USB pod to stop NOW! Once again, it
could be a "No more Steps" NOW or decelerate at maximum rate NOW. No
more steps is easy and the pod can report which step package it was
doing when it stopped so the CAM software has an idea of where the tool
might be assuming the mechanics didn't overshoot.

A decelerate now can involve minor intelligence in the pod that tracks
the current step rate for each axis and when told to decelerate now
executes a pre-programmed sequence to decelerate from that rate to zero.
It keeps track of the number of step done to accomplish that and reports
it back to the CAM software which then knows exactly where the tool is.


Soap box time.

I've over simplified this I'm sure. But take a good look around at the
number of different parallel port interface boards and I think the
industry is better served with an open model.

There are disadvantages. I've been involved with the Controller Area
Network (CAN bus) since 1992. The license agreement from Bosch is such
that if you make an enhancement to the protocol, it instantly becomes
the property of Bosch and is made available royalty free to all other
stake holders (Intel, Motorola, Microchip, TI, Siemens, Philips etc.).
Not much incentive to do creative upgrades when the competition gets to
have it for free.

What this _has_ done is held the CAN bus protocol stable for almost 20
years. From initially just Intel and Philips we now have lots of
suppliers with unique CAN ports and extra options that work around the
basic structure. A moving target with no compatibility would have hurt
that industry.

I feel the same thing will happen as the parallel ports (the common
factor) vanishes from the PC.

Perhaps a discussion like this is better served on the DIY_CNC group
since it's more DIY rather than this group which I think is more about
help with implementing existing solutions. I'm in favour of one dongle
that serves multiple CAM applications so that I don't have to access the
back of the machine to start swapping cables N times per day.

If history is something we should learn from, then even though Beta Max
may have been a better format, VHS won through sheer volume of support.
If you're wondering why your PC uses Ethernet rather than Token Ring
look at stiff licensing from IBM as the reason Token Ring wasn’t
adopted.

I'll be quiet now.

John


Automation Artisans Inc.
http://www.autoartisans.com