Hi Eric.
Sounds like cool stuff you get to work on.
Incidentally, in response to an earlier post regarding BASE_PERIOD
settings, I have a celeron 500, using 100MHz SDRAM, and it's capable of
running with 0.000025 base period (possibly faster, but I haven't
checked lately). Something's definitely wrong if you can't get better
than 0.000080 with a 2.53GHz celeron.
Some responses mixed in. This is all relative to emc2, because I think
it would be a royal nightmare to get emc 1.x to do what you want.
(it'll still be - err - "interesting" in emc2 :) )
Eric H. Johnson wrote:
>Hi all,
>
>I have been digging my way through EMC and EMC2 and am ready to try a
>configuration. Below are some of the major things I have questions on as to
>how to implement. I am also not entirely clear on how to implement the
>things which are likely to be unique to my project but I suspect beyond a
>matter of configuration, and thus probably shouldn't go back into EMC
>itself. I would appreciate any suggestions as to the appropriate method of
>dealing with these types of things (see below).
>
>Basically what I have is a very typical servo controlled lead-screw type XYZ
>table, but instead or in addition to a router or similar device, I need to
>control a laser. Here are some of the issues as I see them:
>
>1> Thanks to Paul I have the Vigilant drivers for EMC1 which I expect I will
>need to port to EMC2 (HALify), as that is the motor / encoder module I am
>using. Which would be the best existing EMC2 driver on which to base it? The
>servo to go (stg) driver?
>
>
STG is probably as good as any. You should probably choose the one that
most closely matches the hardware features - number of encoder counters,
number of A/D, D/A, digital I/O, PWM etc. The bus type won't be as
important - you can base the actual read/write code from a different
driver that uses the right "I/O method" (parport multi-byte, ISA, PCI ...)
>2> The laser control signal is basically a PWM signal. It has a carrier
>frequency of 5 KHz and duty cycle ranging from 0.002 to 0.998 (0.2% to
>99.8%) representing 0-100% laser power. A trickle pulse of at least 0.2% is
>required to keep the laser from shutting down entirely, which then would
>require a 5 second warm-up before it can be used again. Currently I am
>planning to use a DC to frequency module from Acromag to convert a 0-10VDC
>analog to frequency, but would prefer to do this directly either through
>software or using a dedicated 8254 PIT. It looks like freqgen.c basically
>has this capability, and provided I have a fast enough machine, should be
>able to generate up to a 10KHz PWM signal.
>
>
err - I don't think that'll work. Consider the 5KHz signal, with 0.2%
resolution (500 steps). That means that you need 5 KHz * 500 = 2.5 MHz
"resolution" (or, a period that's 0.4 microseconds). That's even hard
on a microcontroller :) You'll need hardware PWM generation. One
possibility (if you have the latitude to add a second card) is the Mesa
M5i20. This has an FPGA that gets configured by emc, so you can add PWM
generators as you see fit (there may even be a few in the default config).
>I haven't entirely figured out the ini files. What determines the axis type,
>as in stepper or servo? In all of the ini files I examined, the "TYPE" is
>always set to "linear". Where is the type of axis, as in stepper or servo,
>defined?
>
>
With emc1, you'll be hard pressed to get more than one type of hardware
supported at the same time. With emc2, you can load multiple drivers,
and the .hal file(s) control what axis gets connected to which hardware.
For example, say you want to use two steppers, and 3 servos. You want
to use a PCI Vigilant card for the servos, and freqgen for the
steppers. You would put the following into your .hal file:
# load the stepgen component, set up two sets of step and direction outputs
loadrt stepgen step_type=0,0
# load the vigilant pci driver - this provides 4 analog servo outputs
loadrt hal_vigilantPCI
You now have two step/direction units to play with (which aren't
connected to any physical pins yet, so they won't do anything to the
motors), and the 4 analog outputs of the Vigilant card. You can now
connect any of the motion module axes to any of the stepper or analog
outputs (more .hal lines):
# create hal signals for X,Y,Z,A and B axes
newsig XPos float
newsig YPos float
...
# same for ZPos, APos, and BPos
# connect the X axis to a servo
linksp XPos axis.0.motor-pos-cmd
linksp XPos vigilant.motor.0 # <-- or whatever you called the servo
pins in the driver ;)
# connnect Y to a stepper
linksp YPos axis.1.motor-pos-cmd
linksp YPos stepgen.0.position-cmd
...
# connect other axes to the appropriate motors
# note that there will be one Vigilant output left unconnected - this is OK.
Just connect whatever you want to the axis outputs in the hal file, and
you're golden
>3> There are three basic ways I have to implement the laser.
>
>..i> Cutting, where the G-Code spindle (S) parameter specifies the laser
>power, and the one complexity is that for certain types of cutting, laser
>power applied to any given point must remain a constant for a given power
>setting. IOW, if the feed rate is 100 IPM but due to kinematics, the actual
>speed is only 50 IPM, then the laser power must be adjusted proportionately.
>
>
This would require you to route the S parameter (a float, I believe)
through a scale block (part of the blocks component). You'll need a
divider also, which doesn't exist at the moment. Take the spindle speed
output, multiply by (actual feed / programmed feed), run that into the
laser control hardware (this may just be a float pin that connects to
the PWM hardware, it's not important at the moment). This sounds
simple, but I'm not sure that the vector velocity is available on a HAL
pin at the moment.
>.ii> Z-Mode cutting. I use M codes to specify how Z values are interpreted,
>normally the mechanical Z axis is used for Z values, but following an M code
>(I semi arbitrarily chose M40 and M41) the laser is used for Z motion, where
>the laser power is in proportion to the Z dimension below the material
>surface (and where tool length specifies the focal point, and diameter
>specifies the spot size). Another M code (M41) returns to mechanical Z-mode.
>
>
OK, you're describing two modes here - normal machining with a
mechanical Z axis, and using Z as the laser power. Mechanical Z is easy
- that's the normal mode of operation. Using Z for the laser is pretty
easy as well - you just need to route the Z position commands to the
laser control hardware. Note that the hardest part of this will be
convincing the motion controller that you now have a Z axis that can
accelerate at 1000000 IPS^2 (since the mechanical limitations are read
by motion at startup, and aren't available for HAL to change on the fly).
>iii> Rastering. Rastering is very much like the 3D_Chips example except
>using a laser rather than a mechanical Z-Axis. The main difference is that
>to produce the highest quality image it is best to keep the speed constant
>and parallel to one axis (usually X) on each raster line, rather than try to
>adjust the laser power during accel and decel. The way I achieve this
>currently is to calculate the accel and decel distance needed for the
>specified feed rate, and then overrun the distances specified in the G-Code
>by the ramp distances at the beginning and end of each raster line. With my
>current system I can go up to about 200 IPM and still produce quite high
>quality raster images, but would like to shoot for 1000 IPM (the X axis is
>capable of 900 IPM).
>
>
Excellent - you've found a real-world case of a pathological trajectory
planner killer :)
If the image is turned into short segments that have 0 Y motion, a few
thousandths of X motion, and a whole lot of Z/laser changes, at 1000
IPM, this will be a real pisser. It's even hard when you have no Y or
Z, and lots of short collinear X segments. In this case, you'd need a
PC that can keep up with very fast servo rates - probably on the order
of 10 KHz at 1000 IPM. You essentially need to be sure that each motion
segment will be one servo period long, or the planner may starve There
is work being done in this area, but you'll definitely want to be
careful with a high speed machine. Conceptually, this is easy though.
You would either route Z to the laser as before, or you can have your
CAM package generate M codes to do analog output synchronized with
motion. I'm not sure how this is affected by exact stop vs. continuous
path mode.
It would be possible to write a HAL component that would take in a block
of data corresponding to the laser power settings along the raster path,
and feed them to the laser based on X motion. This block would have
inputs for X commanded position and position feedback, so it can figure
out how far along the path the laser has travelled, and it would also
have a pointer to the laser intensity data block. I'm not sure how to
get a block of this size transferred to the component - you'd have to
talk to someone who knows the shared memory stuff better than I do.
>Additional Note: There are times when I would like to have Z follow a
>contour while rastering, so I haven't figured out the perfect means of
>specifying laser power, while at the same time remaining consistent with the
>formats which CAD packages and other tool path rendering software can easily
>generate. In fact, some of the larger raster images we are working with
>either take a very long time in generating a tool path (sometimes 2 hours
>plus) or flat out blow up on memory. So I have also had to implement some
>direct picture to part capabilities, bypassing G-Code generation due to
>these problems.
>
>
Are you referring to a "normal" CNC raster engraving procedure, or
having Z run in tandem with laser power modulation?
>4> In addition to the laser, I also have to implement more typical CNC
>tools, like routers, glue guns, etc. I specify these by tool number where
>the laser is always tool #1, and expect the implementation for those to be
>otherwise pretty typical to any other CNC implementation.
>
>
It's possible that the M codes can "connect" to classic ladder, and have
a lot of the necessary HAL configurations change automagically when you
change a tool. I'm not sure how far it'll take you though. There's an
"analog mux" in the blocks component, which could be used to select a
signal to send to the laser, and to the Z axis. You'd basically be
calculating all the possible outputs all the time, but you'd select
which one goes to the Z mechanical axis or the laser (and the
appropriate feedback selections as well) under the control of M codes,
possibly even in the toolchange logic.
>5> I really like the mini.tcl user interface, and am amazed at what the tcl
>scripting language can do. While the code bears some passing resemblance to
>C, it is mostly Greek to me at this point. I suspect some of the things I
>would like to do would be pretty hard in tcl, like preprocessing G-Code
>files or directly importing images for direct "picture to part". I also
>would prefer to have the UI on a WinTel platform. My thought is to basically
>do a port (well rewrite it looks to me) to Java. I saw a reference to
>something called emcJavaGui, but didn't find any code matching that. Is
>there a Java GUI or aborted one out there to look at, or am I otherwise
>trying to reinvent the wheel when it isn't necessary? I do realize that tcl
>can be run on WinTel, but as powerful as it is, suspect I won't be able to
>do everything I want in a scripting language.
>
>
First - there is a Windows GUI for emc1. EMC will still be running on a
Linux machine, but emc is meant to be controllable over a network, so
this isn't a problem. I don't know when the last time someone actually
worked on it was though, and compiling emc1 in general can be
problematic, making the Windows hosted stuff work, I wouldn't even try.
One thing I sometimes do is to use a Windows hosted X server, and just
connect to the emc machine remotely. I put up a wiki page a while ago:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMCDisplayOnWindows
I see that it's a bit outdated, since it refers to emc1-type startup
commands (./generic.run), but the remote X info should still hold true.
It would be a life's work to get emc to actually run on Windows, but you
can have the GUI there if you like. Note that you don't have access to
HAL remotely, only to some emc machine functions.
As for scripting languages, that's a tough one. Tcl can run external
programs, so if you keep to the UNIX mantra (small programs that do a
specific task very well, and are "pipe-able"), you should be OK. If you
have a favorite scripting or programming language, then you just have to
weigh the benefits of using something you're familiar with against the
fact that mini, tkemc, and axis are already there, and only need
modification.
There's some test code for jmkasunich's newest thing - VCP, the "Virtual
Control Panel". This will be a program that creates GTK widgets that
have HAL connections - sliders and text (maybe eventually VU meters) for
analog, buttons and LEDs for bits, etc. The widgets are placed
according to a text file (something like the text representation of a
window in Borland C++ Builder), and no recompiling of the program is
needed to change the display configuration. This isn't ready for prime
time yet, but there is a demo in the configs/sim directory. Run
bin/halvcp configs/sim/test.vcp (from the emc2 dir, while emc is
running) for a small demo (not connected to anything by default, so it
doesn't do too much without some effort on your part)
>Apologies for the length.
>
>
length^2 :)
>Regards,
>Eric
>
Good luck
- Steve
|