Gentlemen,
Forgive my verbosity.
I don't understand the point needing/wanting to use a scripting
language instead of G code. The part I don't understand is the
'instead' of. Symbolic control, usually called G CODE, can coexist
with other symbolic machine control protocols. Other symbolic
expressions can be used.
I understand the readability issue. It can be difficult to
visualize what a G code program will do. It is not hard to visualize
the next few moves but to picture the overall result is very, very
difficult without a preview on a viewer of some kind.
A little side note - in a negotiation where you must not tell the
other party NO, then 'very, very difficult, is the phrase you use to
say 'NO! That is impossible'.
With the speed of today's processors it should be possible to run
a script and post process the output of the script to run a machine
tool.
In the end, though, won't it take symbols sent to the machine to
tell the machine what the program wants it to do? Turn on the spindle,
turn on the coolant, move an X (another symbol) position....
The machine must do discrete things in discrete fashions. It must
move to positions within the movement limits of each axis (another
symbol albeit descriptive). How would the machine follow the script
output if not by some symbol sent to the machine by the script? What
kind of feedback can the script see that a machine running a G code
symbol program not see?
If you are looking for more feedback from the machine I think you
can get it by adding more I/O's to the control. You can then put all
the decision gates in your script (and/or G code) and use the results
of the decisions to output further control symbols. If you don't see
the I/O's in the EMC control it should be a very, very easy thing (see
the previous definition for very very difficult) for someone who
understands the scripting languages EMC is written in. In my case, I
don't understand the scripting languages enough to ENHANCE the MACHINE
CONTROL or I would have already ENHANCED the MACHINE CONTROL a few
times. The developers will tell you, you DON'T want me to try. :)
An analogy. Feel free to correct me.
I see the G code (or any other symbolic) language as assembly
programming. The machine control/machine tool is the processor. The
output is the part you hold in your hand. A post processor is a
compiler. Catia, NCL Mastercam... is Python, C, TCL....
You can use any language you want to generate positions and
commands. You then will need to post process it into a machine
tool/control specific format.
This is why I believe that.
I have two machine shops. I have four types of 5 axis mills.
The first type is a two gimbal head. The gimbals are mounted on
the Z axis. The Z axis does not rotate with the rotary heads. The
rotary heads ride up and down on the Z axis. The axis of the A axis
rotation is parallel to the X axis. The axis of the B axis rotation is
parallel to the Y axis.
The second type is a tilting rotary table (another two gimbal
head) mounted on the table of an otherwise 3 axis mill. Depending on
how you commission the machine the rotary axes can be A, B, or C axes.
We have this machine set up with A and B axes. Axis rotation defined
the same as the first machine.
The third type is a three axis mill with a two gimbal head mounted
on the end of the Z axis ram. Like the second type, commissioning
determines the axis designation. The Z axis does not rotate with the
rotary movement. The head rides up and down on the Z axis. The B axis
rotates around the Y axis. The C axis rotates around the Z axis.
The fourth type is horizontal 5 axis. This machine is a four axis
horizontal with a single gimbal head mounted on the end of the spindle
mount and the spindle mounted in the gimbal. The Z axis does not
rotate with the rotary motion. The B axis rides on the Z axis slide.
As commissioned this is an A axis. The axis of the A axis rotation is
parallel to the X axis.
In my two companies we have Catia V5, NCL, Unigraphics and
Mastercam 5 axis for generating G code programs. I personally use NCL.
Starting in 1979 using a calculator and a pencil and paper I prepared
punch tape with a Flexowriter. In 1987, I learned APT programming on
Elcam APT. I have used NCL since 1989. I have programmed parts for
each type of machine. In no case have I programmed the same part for
each machine type but several times I have programmed the same part
for two types.
NCL is an human language based programming language. I can NOT use
the program posted for one of my type 1 machines on one of my type 2
machines. I can NOT post the exact same NCL program using the machine
specific post for each machine. I must change the NCL program and then
post it for a specific machine. Each machine's dynamic motion causes
the resulting cut from the axis motion to be different in form. For 2,
2 1/2, and 3 axis motion there is usually not much difference but for
4 and 5 axis motion the difference can be quite substantial. This same
scenario exists for each and every NC programming language I own.
One simple example. Cutting a cone with the side of a milling cutter.
Imagine one of my type 1 machines cutting the cone. All five axes
will have to move in concert to keep the side of the cutter tangent to
the side of the cone at all times during the cut. The pivot point of
the two gimbal head and the tip of the cutter must stay a cutter
radius away from the side of the cone. This is very fun to watch the
machine as the motion seems like a dance.
Next, imagine one of my type 2 tilting rotary table machines
cutting the cone. When I first got a tilting rotary machine I
programmed a cone to watch this same dance on the tilting rotary
table. I was very surprised when I saw the motion. The machine
positioned one rotary axis at the angle of the cone. The cutter
positioned beside the cone. Only one axis moved to cut the cone - the
other rotary axis spun 360 degrees. How boring and yet how
enlightening.
It takes different positions and tool axis commands to cut the
same parts with different types of machines. I haven't talked about
multi axis lathes. I have one but I have never programmed anything for
it.
I believe the opportunity and ability to script motion is good. As
I understand the conversation I don't believe the output will be
universal. I believe it will tend to be very machine tool specific.
Thanks for listening to my rant.
Stuart
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
