开云体育

Just a quick link to an interesting resource:



Matt

In a message dated 05/10/2000 10:28:17 PM Hawaiian Standard Time,
fom@... writes:

<< I have tried different feed rates (slow to ultra slow) faster speeds,
light cuts, different mills, drowning it in lube--in short everything I can
think of and still get mill marks in the cuts >>

Many will tumble the part or process with a vibratory mill after machining.
This will remove sharp edges, machine marks and surface imperfections in the
original rolled surface wherever it remains. You can use ceramics, metal
shot, plastic, and many other media's to get different results.

Peter
THRD, Inc.

Paul Devey wrote:

Guys,

I am all for porting this puppy over to my fav. OS LINUX. However, I
am
concerned that if people have to purchase new controllers, expensive
ones at
that, we may slow down the "market" acceptance of this product.

What about designing a parallel port controller that has an external
interrupt to clock activities. Greg Nuspel and Hans Weidermeyer have
designed such controllers. They could be made easily by hobbyists, Dan

Maunch etc.

I'm doing this, in coordination with Matt Shaver. The general concept
is to use the
facilities of RS-1284 (a parallel-port standard for improved throughput)
to control
a flexible array of boards, including D/A converters, encoder counters
and digital
input and output. I am designing a 4-channel, 16-bit DAC board and a
4-channel
quadrature encoder counter. The DAC board should be well under $100
(parts cost is looking like $50 - $60 right now) and the encoder counter
looks like
one $18 chip on a board (unless you need differential inputs, which adds
3 more
$2 chips). I haven't really defined the digital I/O yet, but something
like 24 bits of
input on one board, and maybe up to 16-bits output on another (the Solid
State
relays are bigger than the input optocouplers). These boards should be
VERY
cheap, with one $6 CPLD and the optocouplers or SSRs, and not much else.

I am planning on putting the optocouplers and SSRs right on the control
boards,
eliminating separate opto boards and associated wiring. All the boards
would
be connected to a 37-conductor ribbon cable by standard IDC connectors.
This cable would be the parallel port signals plus some additional wires
for
power supply and communication between boards.
The boards would have address switches on them, so you could set the
addresses
depending on how much of each type you needed. Of course, the simple
machines
would only need one of each.

Jon

From: Ron Ginger <ginger@...>
Thanks Fred and Matt for the fast action on this. I will admit that I
know a lot more about Perl than tcl, so Im biased to think I can do a
better job with Perl.

I Perl for Windows is just as readily available as Tcl/Tk. The
www.perl.org site has lots of pointers, and there is considerable perl
on Win activity. There are some differenecs, but they seem to mostly
have to do with unix like stuff, like getting file permissions, and
such.

I thought I'd try to get Perl/Tk going on my Win95 machine and run a simple
"Hello World" script just to see what was involved. I searched around a bit
and found this page:



which pointed me to:



Apparently this is a popular binary Perl distribution for Windows, but before
I downloaded it I looked at the installation information page for Windows:



which said that I'd need to update a few things on my Win95 machine which
were no big deal except I also had to install IE5 and I'm not going to do
that, uh uh, nope, no way...

I searched around some more and found this page:



where they highly recommend building Perl from its source. As I don't have
Visual C++, I need a precompiled binary distribution. In this category they
recommend the aforementioned ActiveState version and:



This looked like just what I needed, so I got this file:



and installed it without a hitch! Great! Now I needed the Tk part of Perl/Tk
so I got this file:



unpacked it, ran the Perl script that makes the Makefile, and then I needed
Visual C++ to compile it...

I couldn't find a precompiled Tk module for Perl, so I'm stuck. If Perl is a
"must have" I think the most rational thing to do would be to get Visual C++
(or something else that will work) and compile Perl and the Tk module from
their source. Once we have that we can figure out how to pack it up for
distribution with the CPNC program.

Some other options:

1. I'd seriously look into this:

| From: paul@... (and echoed by psp@...)
| Have you looked into [incr Tcl]? It adds an object view to the essentially
| flat Tcl variable space and it's supported as a standard extension
| by Scriptics.
|
| See for an overview.

2. I might look into this, or at least try to install it on Win95:

| From: Phil Wilshire <philw@...>
| Perl is good.
| but ..
| Python is My favorite.

Note, that if we use perl, or whatever we use, EMC wont be part of the
picture on Win or Mac systems. The only way to support a CPNC on them
would be to use one of the serial line devices like FlashCut or Simple
Step, or a driver like INDEXER.LPT. Then all the perl code has to do is
read/write to a serial port.

I'm also hoping to be able to use CPNC for lightweight offline programming on
Win95 by just saving the G-code files to disk. That's why I'm concerned about
the difficulty of Perl/Tk installation for Windows. It's worthwhile to note
that Tcl/Tk installation on my Win95 machine consists of getting this file:



and running it (Next, Next, Next... Finish!). I haven't gotten incrTcl yet,
but I'm assuming it's the same deal.

I have been slowed on writing the CPNC product requirements doc as I
studied a bit of tcl, but I am still on it.

I was also hoping to sketch up some screen layout ideas and program
architecture diagrams that are sort of floating around in my brain. I'll post
something if it ever materializes.

Matt

Carlos Guillermo wrote:

I remember several people mentioning they're using old laptops to
control their machines. I thought most step/dir systems needed one
parallel port for every two axes. What do you do for three? Or, can
you somehow reconfigure the output pins for another step/dir channel by
forfeiting some of the extra I/O pins?

There are three main ways to drive steppers off a parallel port.

Keep in mind there are 12 outputs and 5 inputs in a standard
parallel port (although Expanded parallel ports EPP can have their
17 pins configured differently).

Step & Direction
There being 12 output bits, you can have a maximum of 6 axes
driven, each axes having one step, and one direction bit. Can be
unipolar or bipolar (bipolar is better IMHO).


Two bit Direction
Related to the above, each axis has two bits, but this time a
"move CW" bit and a "move CCW" bit. Obviously both
bits are never active at the same time, but can be inactive at
the same time. This also gives a possibility
of 6 axes from one parallel port. Can be unipolar or bipolar.


Direct Phase Drive (ie poor mans stepper driver IMHO)
The software drives 4 pins per axis, and cycles through
a move CW and move CCW sequence to usually drive
4 transistors in a unipolar arrangement (ie non-4 wire steppers).
I suppose this could drive 3 axes (using 12 bits), but I only
recall seeing 1 and 2 axis hardware.

- -

All this assumes stepper motor drive circuits. However, some
new servo designs (ie
& others) drive feedback and non-feedback ac/dc motors
from the parallel port. If there is feedback, it is usually to the
hardware to keep it tracking where it is supposed to be, not back
to the computer to tell it where it is (due to the limited number of
input pins back to the computer, usually reserved for Limit switches).

Doug Fortune
pentam@...

Guys,

I am all for porting this puppy over to my fav. OS LINUX. However, I am
concerned that if people have to purchase new controllers, expensive ones at
that, we may slow down the "market" acceptance of this product.

What about designing a parallel port controller that has an external
interrupt to clock activities. Greg Nuspel and Hans Weidermeyer have
designed such controllers. They could be made easily by hobbyists, Dan
Maunch etc.

and



Paul

Thanks Fred and Matt for the fast action on this. I will admit that I
know a lot more about Perl than tcl, so Im biased to think I can do a
better job with Perl.

I Perl for Windows is just as readily available as Tcl/Tk. The
www.perl.org site has lots of pointers, and there is considerable perl
on Win activity. There are some differenecs, but they seem to mostly
have to do with unix like stuff, like getting file permissions, and
such.

Note, that if we use perl, or whatever we use, EMC wont be part of the
picture on Win or Mac systems. The only way to support a CPNC on them
would be to use one of the serial line devices like FlashCut or Simple
Step, or a driver like INDEXER.LPT. Then all the perl code has to do is
read/write to a serial port.

Even under unix we will only need a small subset of the emc functions in
perl. I expect CPNC to have very few calls to its driver level- not much
more than move((X,Y,Z) or feed(X,Y,Z) or get(X,Y,Z), maybe an abort and
init. It would be nice of course to have the entire range of emc
function available to perl, but to do CPNC I dont expect to need them.

I have been slowed on writing the CPNC product requirements doc as I
studied a bit of tcl, but I am still on it.

ron

Ron Ginger expressed some doubts about the suitability of Tcl for an EMC
GUI, mainly about its ability to support his foundation data structs: object
orientation, modules, and variable namespace. In fact, Tcl does support these.

1) Object Orientation - the widely-used [incr Tcl] will give you a C++ like
class system. See the new book "[incr Tcl] from the ground up" by Chad
Smith that describes this nice addition to the Tcl toolkit.

2) Modules - use the Tcl package mechanism for cleanly loading either binary
extensions or script libraries.

3) Globals/locals - use Tcl namespaces to organize your module procedures
and variables.

I've used perl for many years and still do. It's a great tool for many jobs.
But it seems hasty to switch to a perl horse in mid-stream in this case. I
don't see any compelling reason.

As Matt Shaver noted, there is a significant body of EMC GUI work already in
existence. The NIST TkEMC GUI that Ray Henry modified and had on display at
NAMES is very well done and would be an excellent base for CPNC extensions.

Phil Plumbo

Maxnc( pro deluxe), cncpro and DeskNC all use single ports.
Pin 2 x step, Pin 3 X Dir etc.

Message: 1[CAD_CAM_EDM_DRO] Digest Number 487
Date: Wed, 10 May 2000 06:48:18 -0400
From: "Carlos Guillermo" <carlos@...>

I remember several people mentioning they're using old laptops to
control their machines. I thought most step/dir systems needed one
parallel port for every two axes. What do you do for three? Or, can
you somehow reconfigure the output pins for another step/dir channel by
forfeiting some of the extra I/O pins?

Babyhex ran six motors from a single port with emc. Dave put pullup
resistors on a couple of the extra pins that were used.

Ray

Look at CNCPro it uses one port for four axis. My setup is very different and uses a custom software for it's application. My system is a hot wire cutting system for making foam parts so it works more like a wire EDM with four axis all controlled from one port. The software runs on windows 95 using a clock interrupt signal to maintain real time.

What's your setup? Software, # axes, etc.? I think I heard MaxNC requires 2
ports for 4 axes, and I-LPT says the same.

I remember several people mentioning they're using old laptops to
control their machines. I thought most step/dir systems needed one
parallel port for every two axes. What do you do for three? Or, can
you somehow reconfigure the output pins for another step/dir channel by
forfeiting some of the extra I/O pins?

Some of the cheap laptops at

started me thinking. I was trying to find room in my basement shop to
setup my future CNC, but I can't find a spot for the CRT monitor! The
wall is the best place. I'd be happy saving space with a flatscreen LCD
display, but they're twice the cost of a used laptop.

Carlos Guillermo
VERVE Engineering & Design

I know my system uses one parallel port for four axis. I thought most did.

From: Fred Proctor <frederick.proctor@...>
Something equivalent can be done in Perl. I have never done this, but I
see from the O'Reilly Perl book, 2nd Edition, on page 371 that there are
references to man pages for perlxstut, perlxs, perlguts, and perlcall
that describe this. XS is a preprocessor that spits out the glue
routines that tie C++ into Perl.

Rather than waiting for me to never get around to it, this could be a
plan for Perl-ifying the EMC:

1. Someone with Perl experience extends Perl with a C++ function that
just increments its argument, e.g.,

int myfunc(int arg)
{
return arg + 1;
}

and then does the gluing to the string "myfunc" so if you do this in a
Perl script:

print myfunc(2)

it prints 3. Forgive my Perl syntax.

2. Once this is done...

OK, it's done.

1. I found that how to do this is described in simple enough terms (even for
me!) in the perlxstut manpage which is available at:



and by typing 'man perlxstut' at any convenient linux command prompt.

2. I made a scratch directory to work in and then followed the directions in
the manpage, mainly examples 1 and 2. I edited two of the files created by
the h2xs program:

Filename: Mytest.xs

<SOF>
#ifdef __cplusplus
extern "C" {
#endif
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#ifdef __cplusplus
}
#endif


MODULE = Mytest PACKAGE = Mytest

<NOTE> I added the stuff between here and EOF </NOTE>
int
myfunc(arg)
int arg
CODE:
RETVAL = arg +1;
OUTPUT:
RETVAL
<EOF>

Filename: test.pl

<SOF>
# Before `make install' is performed this script should be runnable with
# `make test'. After `make install' it should work as `perl test.pl'

######################### We start with some black magic to print on failure.

# Change 1..1 below to 1..last_test_to_print .
# (It may become useful if the test is moved to ./t subdirectory.)

BEGIN { $| = 1; print "1..1&#92;n"; }
END {print "not ok 1&#92;n" unless $loaded;}
use Mytest;
$loaded = 1;
print "ok 1&#92;n";

######################### End of black magic.

# Insert your test code below (better if it prints "ok 13"
# (correspondingly "not ok 13") depending on the success of chunk 13
# of the test code):

<NOTE> I added the one line between here and EOF </NOTE>
print "myfunc(2) = ", &Mytest::myfunc(2), "&#92;n";
<EOF>

Running the test per the instructions produced the following output:

<OUTPUT>
[root@LINUX Mytest]# make test
PERL_DL_NONLAZY=1 /usr/bin/perl -I./blib/arch -I./blib/lib
-I/usr/lib/perl5/i386-linux/5.00405 -I/usr/lib/perl5 test.pl
1..1
ok 1
myfunc(2) = 3
</OUTPUT>

So, it works. Now what?

Matt

P.S. You have to wonder if this is going to work for Perl under Windows!
make...?

I would much prefer to write in Perl/Tk. All the data handing could then
be object oriented and much more robust. We could also use the Perl
module mechanisms to add code. To use a controller like Simple Step or
FLashCut this would be fine, but to interface to EMC it will be
necessary to do the same kind of work that was done to tie Tcl to EMC.
It is not hard, but it does require some C work, and its not something
Im ready to take on. Who did the emc-tcl work, and can we encourage him
to do it for Perl?

Im very sure that the success of CPNC will depend heavily on the data
structure under it. I dont think Tcl will give us the structure we need.

Have you looked into [incr Tcl]? It adds an object view to the essentially
flat Tcl variable space and it's supported as a standard extension
by Scriptics.

See for an overview.

I know lots of people like Perl, but I personally find Tcl more readable.

Paul

--
Paul Amaranth | Rochester MI, USA
Aurora Group, Inc. | Systems & Software
paul@... | Unix / Windows / NT

Ray Henry wrote:

BTW - The 2.0.36 "cinco de mayo version of the EMC" loaded and ran
here
without a hitch.

Did you try the 15-mar-2000 version? Did you have the problem with the
GUI hanging up occasionally on that one? I thought it was pretty good
in
respect to several improvements, but after the GUI hung up twice, I had
to go back to 20-Dec-1999. I'll have to try this new one soon, but I
was
hoping to find out if this problem was solved first.

Thanks,

Jon

Ron Ginger wrote about wanting to write a conversational programming
interface in Perl. He wrote that the Visual Basic and Tcl/Tk data types
are too limiting:

One of the major reasons Im stopping the work on my VB program is that
the underlying data structure is not good. I cannot use the VB Object
stuff, since my .dll limits me to the 16bit VB, so that forces just
about everything to be global variables, since procedures can only
return a single value. I have done some reading on Tcl/tk and find the
same problems.

...

Im very sure that the success of CPNC [Conversational Programming for NC]
will depend heavily on the data structure under it. I dont think Tcl will
give us the structure we need.

Could be. The Tcl/Tk GUI for the EMC doesn't require too much in the way
of data structures. It uses strings for some of the return values, and
the usual scalar data types (ints, doubles) for the rest. Perl could be
much better:

I would much prefer to write in Perl/Tk. All the data handing could then
be object oriented and much more robust. We could also use the Perl
module mechanisms to add code. To use a controller like Simple Step or
FLashCut this would be fine, but to interface to EMC it will be
necessary to do the same kind of work that was done to tie Tcl to EMC.
It is not hard, but it does require some C work, and its not something
Im ready to take on. Who did the emc-tcl work, and can we encourage him
to do it for Perl?

I wrote the Tcl/Tk interface to the EMC. It's C++, in
emc/src/emctask/emcsh.cc, and does the so-called "impedance matching"
that maps strings encountered in a Tcl/Tk script (e.g., "emc_estop on")
to some C++ code that composes and writes the corresponding message to
the EMC command buffer. emcsh.cc starts by connecting to the EMC, then
calls a C++ function in the Tcl/Tk library that enters a main loop that
prints a prompt, reads input, parses it, and interprets it according to
the Tcl/Tk syntax and whatever you added to it in string-function pairs.

Something equivalent can be done in Perl. I have never done this, but I
see from the O'Reilly Perl book, 2nd Edition, on page 371 that there are
references to man pages for perlxstut, perlxs, perlguts, and perlcall
that describe this. XS is a preprocessor that spits out the glue
routines that tie C++ into Perl.

Rather than waiting for me to never get around to it, this could be a
plan for Perl-ifying the EMC:

1. Someone with Perl experience extends Perl with a C++ function that
just increments its argument, e.g.,

int myfunc(int arg)
{
return arg + 1;
}

and then does the gluing to the string "myfunc" so if you do this in a
Perl script:

print myfunc(2)

it prints 3. Forgive my Perl syntax.

2. Once this is done, get it to the emc@... list with notes on what
you did, and we'll clone the glue code to handle comm channels, etc. and
populate it with a representative set of EMC functions.

3. You add the rest that you want, following the template we set up.

--Fred

Andrew Werby wrote:

This is a muddle. leave out the "output my G-code as step and
direction
through the serial port" part, and it makes a lot more sense.

[Actually, that was my assumption, not what the Milltronics guy told
me. So
I just have to send it regular G-code, as ascii characters, and let
the
mill control do the translation itself?]

Essentially right. Some CNC's take ASCII, some take EIA character
codes. My
AB will take either, and it needs a particular character first so it can
decide what
code format is being used. You'd need to check the Milltronics
documentation
for that.

[But since RS-232 is a serial communications link, I have to go
through the
serial port, no?]

Well, if that is the only interface provided, yes. But, almost all the
older controls had the
paperr tape reader standard, and everything else was an option.

A CAD/CAM package (or other machine control) will work a lot better
than an
off-the-shelf comm program. Especially, in some cases, the CNC
requires the
tape to be read backwards (to back up a few program steps when a tool
breaks, for instance).

[You don't get that with DNC, though- it seems like a one-way street.
As I
understand it, all I get to do is feed it a set of instructions- no
backing
up. But I suppose I might be able to edit the program to resume
cutting at
a given place, if I knew where that was.]

Again, depends on the CNC. Some CNC's have a lot of memory available to
hold the
program, and expect to be able to hold the entire program in memory.
This is a limitation,
as very large programs may not fit.

Backing up is a very important feature, and knowing the last line that
was processed
before stopping or having a fault is really important. EMC is still a
little weak on this,
but one can live with it. The AB had incredible features, so that you
could stop a
program at the end of a move, do manual moves and MDI commands to your
heart's
content, and then resume the program at the next block with two
buttons. There was
even a feature so you could interrupt a move, retract one axis to check,
clean or change
a tool, and then resume the move from where it was interrupted!

[According to the Centurion guy, it's software handshaking: x-on,
x-off. ]

Unusual, but at least you now know what the flow control is.

[This would come back up the serial port? And the PC would have to
recognize it? Is this part of the standard null-modem stuff, or
something I
have to put in there?]

Well, you will have to wire transmit data to receive data, and
vice-versa, so that is
essentially a null-modem. But, X-on/X-off are characters sent through
the normal
data lines, not on other wires. Most PC comm programs handle X-on/X-off
protocols
just fine. There will be a software handshake or software flow control
option to
be set.

[I'm not expecting that- all I want is to be able to run a big program
once.]

Well, real DNC would be quite nice, but if the PC is next to the CNC
control, that should
be fine. That's how mine was set up. I would enter a line like :
READPAPR BORE123.CAM
on the PC, and then hit the AUTO then CYCLE START buttons on the CNC,
and it would
start pulling characters from the simulated paper tape. Each time the
CNC read one
character, the PC would supply the next one.

[Can you recommend a DNC program to do this? At this point, I'm not
sure
the CNC control that's on the machine is capable of asking for
programs by
name- there seem to be mostly numbers on its keypad, with only a few
letters, like "G" and "M". Could I call a program by a numerical
"name",
like "123" ? Anyway, thanks for the help, I really appreciate it. As
you
can probably tell, I'm fumbling around in the dark here, although
there
seems to be some light at the end of the tunnel...]

Yes, many of the old controls requires part programs to be called by
number.
If you don't have at least operator manuals for the Centurion, forget
DNC, because
you'll never get it working without those manuals. I can't recommend
any DNC
programs, as I only know they exist, but have never used one. The most
important
detail is that they support your Centurion control. Since I didn't have
DNC hardware
or software for my CNC, I went with the paper tape reader interface.

Jon

Andrew Werby wrote:

Re: PROJECTS STILL ON THE BURNER?

It now appears I can get my Beast (the 1984 Leadwell-Ramco) of a
milling
machine to accept drip-feed input through its RS-232 port. I tracked
down
the people who made the old Centurion IV control (they are called
Milltronics now, and are located in the Minneapolis area) ,

I thought I should add a bit more commentary about this. I got an old
Allen-Bradley
7320, one of the most sophisticated CNC controls of its time. It is
from the late
1970's, proprietary 16-bit minicomputer, racks of I/O cards, solid state
memory
up to 64 K Bytes. I managed to get it running, but it was not reliable,
and thankfully,
EMC got to be usable just about the time I was getting worried about the
downtime
on the AB. But, aside from that, it had a 100 Hz servo update rate,
which caused it to
be a very sluggish control. Probably no problem on a 50-ton bed mill,
but just
too slow for a Bridgeport. Also, the block processing time was real
slow, so that
some engraving work I did that consisted of thousands of tiny vectors
took over
an hour to engrave two words on a piece of plastic. Well, at least it
seemed like
over an hour, certainly way over a minute for each letter!

Now, I'm an Electrical Engineer who grew up fiddling with and fixing
16-bit minis
and related gear, and I did have the schematics, theory, etc. for the
AB. Still,
it was a pain. Maybe your Centurion IV control is more reliable, but if
it is from
the same vintage, I doubt it.

So, you might want to think carefully about whether the Centurion will
do what
you want to do, and remain operational. If you want to replace it, you
could
keep your servo amps, and switch over to using EMC to run the servo
motors.
That is basically what I did, although I had to make my own servo amps,
as my
control didn't come with them. If the Centurion/Ramco has shaft
encoders or
linear encoders for position feedback, you would be pretty well set for
the
upgrade to EMC with either the Servo-to-Go card or the flexible
parallel-port
interface I am designing now. If the machine has resolvers or
Inductosyns, then
you would have an additional conversion to make.

Just something to think about, before spending big money on a DNC setup.

Jon