FAQ Archive

Below is an archive of the FAQ as it existed before we set up the EMCKnowledgeBase WiKi and established the simplified FAQ.

A.1 What is EMC ?

EMC stands for Enhanced Machine Controller. It's free
Open Source software for controlling CNC machines and
robotics. It's run on Linux-operating system with
certain "real-time-modifications" applied.

A.2 How do I set the steps per unit for each axis?

This is done in the ".ini" file at your installation
directory. INPUT_SCALE and OUTPUT_SCALE are the number
of pulses for each unit as defined in the
UNITS-parameter. UNITS should be "1" if you are operating
with millimeter as your unit and " 0.03937007874016" for inch.

You can calculate needed INPUT_SCALE and OUTPUT_SCALE
with following equation:

INPUT_SCALE = STEPS_NEEDED_TO_GO_ONE_REVOLUTION /
LENGTH_OF_TRAVEL_IN_ONE_REVOLUTION.

So, for example if you have setup where milling head
travels 1.5mm per one whole revolution, and your
steppers require 400 pulses to go one revolution:

INPUT_SCALE = 400 / 1.5

so, in ".ini"-file we would write

INPUT_SCALE = 266.66666666667 0.000

If you are using "freqmod.o" as your motion module (eq.
if you are using servos instead of steppers), you
should write same number to INPUT_SCALE and OUTPUT_SCALE:

INPUT_SCALE = 266.66666666667 0.000

OUTPUT_SCALE = 266.66666666667 0.000

(I'm not sure where the second number "0.000" is used)

Appropriate way to think of these is that the input
scale represents how many pulses you need to input to
the motor amp to get one unit of motion. Output scale
is the number of pulses the encoder will send for one
unit of motion. Motor or axis in and out rather than PC
in or out.

You can also calculate necessary values with a [http://206.19.206.56/StepPerIn.asp||calculator].

A.3 How does EMC handle home and limit switches ?

EMC provides inputs for Home, Low limit and High limit
switches. These are fed into pins 12, 13 and 15
respectively of the principal parallel port. Because
there is only one input for each purpose and yet we
have at least two or three axes of motion, similar
switches for all axes must be ganged together, i.e. all
the Home switches are grouped together and fed into pin
12 etc.

It is normal for limit switches to be connected in the
'normally closed' mode so that, if the switch fails, it
will do so in a safe manner (and warn you that
something is wrong). There is no definite convention
for Home switches but, here again, it would make sense
to connect this in the normally closed mode so that
failure will be obvious. In this mode, the switches
from all the axes should be connected in Series (i.e.
in a chain with one terminal of one switch connecting
to one of the next switch and the second terminal of
this switch connecting to the next switch), thus, when
any switch is activated it will open and break the chain.

If the switches are connected in the Normally Open
mode, they will have to be connected in Parallel (i.e.
the two terminals of one switch connecting directly to
both the corresponding terminals of the next switch).
When any of the switches are activated in this mode,
they will close and provide a current path directly to
the port pin. Depending on which mode is chosen, the
relevant entry in the INI file will have to be set
accordingly. To ensure positive operation of the
switches, it is a good idea to provide a 'Pull-up'
voltage onto the port to make sure it defaults to a
definite state. This voltage can conveniently be
derived from any 5 volt supply, perhaps on the motor
drive circuitry, or it can be provided separately from
a small transformer and regulator (6 volt AC
transformer feeding a small bridge rectifier and then
to a 78L05 regulator with a 0.1uf capacitor across the
input terminals and a 22uf tantalum capacitor across
the output terminals.) Whatever voltage source is used
it should be fed direct to pins 12, 13 and 15 via 5K6
resistors to limit the current to about 1mA. Do not
forget to connect the negative side of the supply to
the ground line of the parallel port (pins 18-25). The
limit switches are then wired between pins 12, 13, 15
and the ground pins. Make sure that the cable you are
using to connect from the equipment to the computer's
parallel port has all the relevant pins connected -
don't make the same mistake as I did at first and
assume that a cable having 25 pin 'D' plugs on each end
will have all pins connected, it is quite likely that
this type of cable will be designed for serial use and
will only have about half a dozen wires connected. It
will drive the three axes OK but will not work with any
limit switches. Where switches are connected in the
Normally Closed mode (series), the settings in the INI
file should be as follows:

MIN_LIMIT_SWITCH_POLARITY = 1

MAX_LIMIT_SWITCH_POLARITY = 1

HOME_SWITCH_POLARITY = 1

Where the switches are connected in Normally Open mode
(parallel), the settings should be:

MIN_LIMIT_SWITCH_POLARITY = 0

MAX_LIMIT_SWITCH_POLARITY = 0

HOME_SWITCH_POLARITY = 0

The other settings which needs checking are the
HOMING_POLARITY to send the axes in the right direction
and the FAULT_POLARITY which will be 0 for Normally
Closed switches and 1 for Normally Open switches. These
settings need to be altered for all the axes of course.

To use the Home Switches with a stepper motor setup it
will be necessary to make an entry in the INI file
under HOME_OFFSET. This needs to be only a large enough
distance to move the axis off the home switch (say 0.1"
or 1mm). In use, one would select one of the axes and
press the HOME button on the EMC screen (only in MANUAL
mode). This will send that axis in the direction preset
in the INI file as above and, when the Home switch is
activated, the axis will stop, then move by the
distance in HOME_OFFSET (the direction of which can be
changed by altering the sign if needed) and will then
stop and reset the axis display to 0.0000, changing the
figures to green at the same time. Then another axis
can be selected and Homed in a similar manner.

When any of the limit switches are activated, EMC will
stop the machine and go into an ESTOP RESET state and
also bring up an 'Error Box'. This tells you that a
high or low limit has been activated and requires you
to acknowledge the message before you can again turn
the 'MACHINE ON'.

Types of switch: The most common type of switch for
limit switch use is probably the mechanical
microswitch. This is normally made as a single-pole
change-over switch and can thus be used as either a
normally open or normally closed switch. For machine
environments, particularly on larger machines, it is
probably a good idea to use the type which has a sealed
protective enclosure. The microswitch should not be
mounted directly in line with the carriage of the
machine as any failure will cause the machine to crush
the switch. Instead, it should be mounted to one side
and activated by some form of arm which slides over the
switch operating button, pressing it as it passes. This
will prevent damage to the switch and allow you to
mount the Home switch anywhere you wish on the axes (do
remember, however, that you have only preset the axis
to travel in one direction to seek the Home switch!).
An alternative to the mechanical microswitch is the
optical 'vane in a slot' type of switch which is found
in many types of equipment. In this, a small plastic
'U'-shaped molding has an infra-red LED in one leg
facing a photocell in the other. Passing a small opaque
vane between the legs of the sensor interrupts the beam
and this can be used as a non-contact type of limit or
home switch. Power needs to be supplied continuously to
the LED and a little electronic circuitry is required
to amplify the signal from the photocell but this does
provide a rugged and very accurate means of detecting
limits etc.

To make the Home switch even more accurate it is
possible to 'gate' the switch with either the power to
one pole of a stepper motor or with a signal produced
by a simple, one-hole encoder on the motor shaft. By
passing both these signals through an 'AND' gate (or
'NAND' gate) before feeding the result into the 'Home'
pin of the parallel port, the motor can be made to
always stop on exactly the same step. so guaranteeing
the best accuracy possible.

Ian W. Wright

A.4 What do I need to do to run EMC as a user?

In a recent post, Jan raised the issue of security
concerning the EMC software on a shop floor machine.
IMO this issue is common to all PC based systems but
since parts of the EMC must run as root, and now all of
it runs as root in a standard setup, the system is
extra vulnerable.

If you need to protect the system against inadvertent
changing or removal of files, it's fairly easy.
Protecting against determined hackers is more of a
problem. Easy way is to set up a normal Linux user
account, say "ray", with a home directory, say
/home/ray. Ray won't be able to run the EMC for three reasons:

1. it requires running the /sbin/insmod, /sbin/rmmod,
and /sbin/lsmod programs to install/remove/list the
EMC motion controller

2. it requires accessing /dev/mem to use the shared
memory interface

3. it requires running privileged inb/outb instructions
for the parallel port IO.

4. it requires privileges to mbuff-device

You can get around the first problem by changing the
permissions on /sbin/insmod and /sbin/rmmod so that
they are "setuid root". This means that they run as if
root is running them. Set this up, as root, by doing:

chmod u+s /sbin/insmod /sbin/rmmod /sbin/lsmod

Now, anyone can run insmod. So, for example, a talented
programmer could write his own kernel module that ran
through the file system looking for protected user
files; remove files; etc. Writing a kernel module is
not something you do inadvertently.

You can do the same sort of thing with /dev/mem, by
making it read-write for everyone. As root, do:

chmod a+rw /dev/mem

Now, anyone can access /dev/mem and access Linux memory
directly. This isn't something that can be done
inadvertently. You can set up Unix pipes to write 0's
into memory and clobber Linux, but you can also flip
the power switch on the front.

You can change the permission on
emc/plat/whatever/bin/bridgeportio so that it runs
setuid root also. As root, do:

chmod u+s /usr/local/nist/emc/plat/whatever/bin/bridgeportio

You can then change permissions to mbuff-device:

chmod a+rw /dev/mbuff

Now it runs as root and can execute the privileged
inb/outb instructions. There are better ways to set
things up using groups of semi-trusted users so not
everyone can run the EMC, and so those who can still
aren't root. If anyone has any other ideas let me know.

Will's response

Would another possibility be to run the rtlinux stuff
and the modules that directly connect to them in some
.rc file at startup and then let "ray" run only the
user interface? I think that this would mean "ray"
would have to completely reboot the machine to restart
the main controller, but not have access to the
/dev/mem or insmod" Of course if "ray" is truly evil
and talented and knows how to reboot in single-user
mode with a floppy. The only thing that might prevent
tampering would be to lock the PC with the EMC
controller on it in a box and force "ray" to use a user
interface connected remotely to the EMC controller.

-- Will






______________________________________________________________________

Fred's post

Date: Mon, 17 Jul 2000 11:39:31 -0400 (EDT)

From: Fred Proctor frederick.proctor@nist.gov

Subject: Re: Secure EMC Run - 2

Ray,

You get this error: "not privileged to access IO--
disabling IO" because the user is not root. To make
this work, you can make the iosh program "setuid root"
so that whoever runs the program effectively runs it as
root. To do this, do (as root):

root> chown root emc/plat/linux_2_2_14/bin/iosh

root> chmod u+s emc/plat/linux_2_2_14/bin/iosh

This makes root the owner of the program (it should
already be owned by root), and sets the "setuid" bit so
that whoever runs the program has the identity of the
program's owner, in this case root. If the program is
recompiled, I think the setuid bit is cleared so you

have to do it again.






______________________________________________________________________

New Problem

Today Sept 25, 2000 I found an additional file that you
will have to set to root in order to make the latest
stuff run as a common user. That file is .bin/ls and it
has to do with passing the value of the running ini
file to scripts that run from tkemc. The message that I
got when I tried to start the new version was:

running EMC DISPLAY PROGRAM -- tkemc...

Error in startup script: /bin/ls: tcl/scripts:
Permission denied

while executing "exec /bin/ls $scriptdir"

(file "plat/linux_2_2_14/bin/tkemc" line 570)

To fix this I ran the following command as root.

root> chmod u+s /bin/ls

That took care of it. You will need to add this file
permission for new releases after the Aug release.

Ian's comment

Will Shackleford wrote:

> The only thing that might prevent tampering would be
to lock the PC with the EMC controller on it in a box
and force "ray"

> to use a user interface connected remotely to the EMC
controller.

It must be something to do with the name - I had two
'Rays' work for me and I couldn't trust either if them
not to fiddle with anything they could get their hands
on! One was a positive Jonah but, fortunately,
retirement has left the problem of controlling him to
my successor!

Ian






______________________________________________________________________

Jon's response

> If you need to protect the system against inadvertent
changing or removal of files, it's fairly easy.
Protecting against determined hackers is more of a
problem. Easy way:

Well, I actually think it can be pretty secure,
assuming no gaping holes are found in Linux, itself.
You can set the system up so root accepts no remote
logins, period, and the only thing you can do remotely
is ftp or telnet to one or two accounts, and then only
from one of your own, local, machines. Set networking
so that no connects are accepted except from that local
machine, period. that should make it fairly hard for
hackers to get in.

Now, if you only have outside network access on your
other machines by dialup, and don't have a gateway on
that machine, the Linux machine is pretty safe without
much change. If you have a gateway, or keep one of your
machines connected to the net all the time, you have to
take some precautions. You can also set up your gateway
to prohibit any remote access to the Linux machine. If
you want to make EMC-related files available outside,
you would need to move them to the 'public' machine.
This makes sense anyway, as you wouldn't want outside
demand for a file mentioned on your web page to bog
down the CNC control machine while you were making parts.

Jon

A.5 How can I get EMC out of E-Stop?

This page is the result of a thread initiated by Max
Heise on emc@nist.gov. It includes the relevant messages.

_________________________________________________________________

From: Max Heise mahemt01@fht-esslingen.de

Hi Everybody,

My Machine is now running fine for about 2 weeks. The
problem was a incorrect connected amp fault. What
finally did help me was Fred's "Why can't I come out of
estop? and, parallel port debugger, Fri Mar 3 16:07:13
2000" .. just how many things affect estop. Aside from
stupid things like wrong parallel port or motion board
addresses, they are:

input from amp fault

input from positive hardware limit switch

input from negative hardware limit switch

positive software limit

negative software limit

input from estop sense



Only the pos/neg hard/soft limits turn the position
digits red. Amp fault never shows up anywhere, so if
you have this set wrong in your .ini file, you'll never
know it.

And the following part from Will Shackleford's "Re:
Several questions

(Will Shackleford, Mon Mar 13 19:29:36 2000)"



Unfortunately there are a lot of reasons for not being
able to come out of estop. Usually I start to look for
the reason by running

plat/linux_2_2_13/bin/usrmot -ini mymachine.ini

And entering "show flags" to see most of the flags that
might prevent you from coming out of estop.

_________________________________________________________________

Date: Wed, 12 Apr 2000 12:20:26 -0400 (EDT)

From: Max Heise mahemt01@fht-esslingen.de

To: Multiple recipients of list emc@nist.gov

Subject: Not getting out of estop



Hi,

I not getting out of estop. No matter what I try. My
setup looks as follows.



Hardware:

AMD K6-2 at 300MHz

64 MB RAM

Only one (built in) par. port

STG Ver.1 Board - 4 Axis

2 Axis table plotter (x,y), with one rotary axis (z)
for the 5 tools

(tool offset via G54-G58). Home and limit switches
connected to STG board, estop connected to par. port. X
and Y Axis connected to STG board too.



Software:

Redhat 6.1

linux 2.2.14

rtlinux-2.0

EMC-15-Mar



Some patches: ac patches and a patch for my ali 15xx
IDE driver to do UDMA33. Everything compiles and runs
fine. The simulation runs just great. Encoder feedback
is working for all 3 axis. (what is the plural of axis
?) I am using ioshow.tcl to monitor the par. port. If I
tell tkemc to get out of estop I cannot see anything
happen on digital out 10. If I switch digital out 10
using testppt tkemc goes into estop reset - but still
not out of estop even if I switch digital in 1 using
the estop button.

Or is the bridgeport PLC logic so different from my
machine setup that I have to write my own one. Can I
take tkio.tcl as an example ?

How can I see what's the reason for not getting out of
estop ? Does anyone has a clue ?

Thanks for your help.

Max Heise

_________________________________________________________________

Date: Wed, 12 Apr 2000 15:44:37 -0400 (EDT)

From: Jon Elson jmelson@artsci.wustl.edu

To: Multiple recipients of list emc@nist.gov

Subject: Re: Not getting out of estop



The first thing to check is the address of the parallel
port. If you do "more /proc/ioports" it will show the
physical I/O address that is set for your parallel
port. Make sure that corresponds with the one in the
.ini file. OK, there are 2 things needed to get the
machine 'running'. First, you need to get E-stop reset,
which you have apparently done with testppt. If the
external circuitry was set up to pull pin 13 to +5
Volts on the 25-pin parallel port connector, and to
pull pin 16 to ground, then hitting the F1 key should
do the same. Once in e-stop reset, you should be able
to hit F2 to go to "machine on". But, that may require
the limit switches to all show "not at limit" status.
You can either override this (a screen button, I think)
or change the polarity of the sense lines for the limit
switches in the .ini file.

> Or is the bridgeport PLC logic so different from my
machine setup that I have to write my own one. Can I
take tkio.tcl as an example ?

I think you want to use the script that has minimill.io
rather than Bridgeport.io. That should also use
minimilltask rather than bridgeporttask. I think you
HAVE gotten out of estop, but it is a 2-stage process.
First you have to clear estop, then set machine on. I'm
not sure of the reasons for this, and it has some
drawbacks, but I have gotten it working, and am used to
it. There are some diagnostic uses for the state
between estop and machine on, like servo alignment.

Jon

_________________________________________________________________

Date: Fri, 3 Mar 2000 10:07:14 -0500 (EST)

From: Fred Proctor proctor@cme.nist.gov

To: Multiple recipients of list emc@nist.gov

Subject: Why can't I come out of estop? and, parallel
port debugger



EMC users,



I had that frustrating "why can't I come out of estop" problem

yesterday, and after I ran through all permutions of

ESTOP_SENSE_POLARITY and ESTOP_WRITE_POLARITY I
discovered that I had

the wrong address for the parallel port (I clobbered my
.ini file and

had to redo it from scratch). In doing this I
rediscovered just how

many things affect estop. Aside from stupid things like
wrong parallel

port or motion board addresses, they are:

* input from amp fault

* input from positive hardware limit switch

* input from negative hardware limit switch

* positive software limit

* negative software limit

* input from estop sense



Only the pos/neg hard/soft limits turn the position
digits red. Amp

fault never shows up anywhere, so if you have this set
wrong in your

.ini file, you'll never know it.



The tcl interface to the EMC (emc/src/emctask/emcsh.cc)
has a status

command, "emc_joint_limit", that returns "ok",
"minsoft", "minhard",

"maxsoft", or "maxhard". Currently the digits are
colored red only

when it's not "ok". It would be better if there were
some indication

of what wasn't "ok". On the fossilized
terminal-graphics GUI

"keystick", the axis labels were bracketed by
characters, like this:



-*X-- --Y*- --Z**



where "*" meant "limit exceeded," and the characters indicated

negative-hard, negative-soft, axis, positive-soft,
positive-hard. In

the above example, X is at a negative soft limit, Y is
at a positive

soft limit, and Z is at both positive soft and hard limits.



On the TkEMC it could be done similarly.



Anyone on the GUI committee want to try this? You
simply need to use

the "minsoft", etc. values explicitly to get the status.



Amp fault is not part of the emcsh.cc Tcl interface to
the EMC. I will

add this.



Regarding estop sense, the "ESTOP" label will still
show "ESTOP" when

you release the physical estop, since the controller
has to

acknowledge this. It would be nice if there were a
label or light or

something that showed the raw estop sense value
directly. Then, when

you reset the estop (pulled up on the estop button),
the "ESTOP" label

would still show "ESTOP", but the raw label or light
would show that

the button was released. This would be nice for debugging.



Right now the raw estop isn't part of the status
anywhere: not in NML,

not in the Tcl interface. I will add this.



Regarding parallel port debugging, there is a
text-based utility for

this in the EMC distribution, called "testppt". It's
compiled from

emc/src/emcnml/parport.c, when MAIN is defined. Use it
like this:



testppt -addr 0x378



Then type:



help/? print this help

s [#] set bit #

c [#] clear bit #

k Check outputs

ENTER print inputs

q quit





I also wrote a little Tk script that uses iosh to pop
up green or red

circles for the inputs. It's not in the EMC
distribution yet, but it's

appended here. (related version ioshow.tcl available
from the dropbox)



--Fred

_________________________________________________________________



Date: Mon, 13 Mar 2000 13:29:37 -0500 (EST)

From: Will Shackleford shackle@cme.nist.gov

To: Multiple recipients of list emc@nist.gov

Subject: Re: Several questions



> Date: Mon, 13 Mar 2000 13:01:25 -0500 (EST)

> Originator: emc@nist.gov

> From: "Joel Jacobs" jj@netexp.net

>

>

> Hi all,

> I finally got EMC up and running on a Pentium 100mhz computer

running

> 2.2.13/rtlinux-2.0. The computer seems grossly
underpowered as I can

not

> get the motors to run smoothly. I had to set 'PERIOD'
in freqmot to

100

> before I got the GUI working. I'm trying to decide
what to do,

whether or

> not to try a faster computer. It seems like a really
nice program if

I

> could get it working but I noticed some peculiar
behavior that I'm

not sure

> is related to cpu speed.

>

> 1. Sometimes I start it and it won't come out of
estop, I shut it

down and

> restart it and it may come out of estop but can't
turn the machine

on.

> Restart again and everything turns on and I can move
motors but

after a

> while it may stop responding to any input. When I
first installed

it, it

> wouldn't work at all and the coordinates display was
red - I changed

the

> polarity of the limit and home inputs and it started
to work but the

input

> pins on the printer port are 'open' maybe I need to
tie them low?

>



Unfortunately there are a lot of reasons for not being
able to come

out of

estop. Ussually I start to look for the reason by running

plat/linux_2_2_13/bin/usrmot -ini mymachine.ini



And entering "show flags" to see most of the flags that
might prevent

you from

coming out of estop.





> 2. Everytime I start the program the default jog
speed is 300 imp no

matter

> what I put in the ini file for max velocity.

>

> 3. I can't edit the settings in the calibration
dialog. I click on a

> setting and then try left and right arrows to see if
the carrot

moves and it

> may move on another field.

>

> 4. I wanted to try emcmot but I get an un-resolved
'hrgettime'. Any

clue?

> It doesn't seem to be in the system.map that was
created when I

compiled the

> rt kernel.



Did you run the install_rtlinux_base script? It should
have insmoded

rtl_time.o

which has gethrtime. (I assume hrgettime is a typo.)



>

> Thanks for any help.

>

> Joel

>

>

>

>

>



---------------------------------------------------------------

William Penn Shackleford III shackle@nist.gov

National Institute of Standards Technology Tel: (301) 975-4286

100 Bureau Drive Stop 8230 FAX: (301) 990-9688

Gaithersburg MD 20899 USA

http://www.isd.mel.nist.gov/personnel/shackleford/

Office Location: Bldg. 220 Rm A253

A.6 How can I set up auxiliary inputs and outputs?

Date: Fri, 22 Sep 2000 11:43:10 -0400 (EDT)

From: Fred Proctor frederick.proctor@nist.gov

To: Multiple recipients of list emc@nist.gov



Luc Vercruysse wrote:



> [http://www.linuxplc.org||http://www.linuxplc.org] has a public domain plc emulation on a (real
time)linuxbox of a siemens compatible plc.I wonder if
it is posible to implement it in the EMC project a a
replacement for the IO machine depended stuf (such as
minimilio ..). Doing this makes it possible to the end
user to write the machine interface in a PLC-language.

Has somebody experience with the linuxplc ??



I don't have experience with the linuxplc, other than
by clicking around the linuxplc.org web site and
wondering what it actually is. You say it's a
Siemens-compatible PLC. Does this means it's
programmable using IEC-1131 languages? I'm very curious
about this. It may be just what I'm looking for.

The PLC is possibly the weakest part of the EMC. Right
now, there are two supplied "PLCs" that control the
discrete I/O (estop, lube, coolant, spindle):
bridgeportio and minimillio. minimillio just controls
our NIST desktop minimill that doesn't have coolant or
lube, so it's a stripped-down version of bridgeportio.
bridgeportion is written in C++, not a very common PLC
programming language. We did this since we have
in-house tools for programming hierarchical control
systems using C++, which we have used for many other
projects, so it made sense for us. For EMC users, it's
not a very popular choice.

Bridgeportio and minimillio are slightly customizable
(without resorting to C++ programming) via the .ini
file, by setting the location and polarity of
input/output bits and some other parameters like delays
for spindle brake engage/release. Adapting them for
anything else, like an automatic tool changer, means
coding in C++ or replacing them with something else.

Looking at the EMC I/O controller as a black box, there
are three things it must do:

1. [TOP] Create NML buffers for commands to it from the
EMC task controller and status from it to the EMC
task controller. This is what connects it to the EMC.

2. [MIDDLE] Read NML commands that come in from the EMC
task controller (e.g., coolant on, etc.), do what's
requested, and write status back (done, executing,
error, and values like coolant is on/off, etc.)

3. [BOTTOM] Talk to real-world I/O points.

As an alternative to the C++-based bridgeportio, we
wrote a Tcl/Tk-based PLC. Here's what we did:

1. Extended the Tcl/Tk windowing shell "wish" with
EMC-specific commands, creating the "IO shell" iosh.
This was done similarly to how we built the EMC shell
emcsh, used for building Tcl/Tk GUIs like tkemc.tcl.
iosh creates NML buffers (requirement (1) above, the
TOP), and adds Tcl words "inb" and "outb" for doing
PC-bus byte I/O (requirement (3) above, the BOTTOM).
iosh can be thought of as the PLC engine, that can be
programmed in Tcl/Tk to implement any arbitrary PLC.
It doesn't have any particular PLC logic program, for
say the Bridgeport. You have to write this yourself,
in Tcl/Tk, as you would write a ladder logic program
for another PLC.

2. Wrote a Tcl/Tk script that does the actual PLC logic
(requirement (2) above, the MIDDLE). This is
tkio.tcl. It implements the Bridgeport I/O
controller, just like bridgeportio. It's
plug-compatible with bridgeportio: you can specify
"tkio" instead of "bridgeportio" in the .ini file, e.g.,

[EMCIO]

EMCIO = tkio

I tried it out a while ago and it looked like it
worked, but the "plug compatibility" might not be 100%
due to bugs. I'll have to check it out on our machine.

Note that since we're extending wish to build iosh, we
get some GUI stuff automatically. That is, in tkio.tcl,
there's some script code for popping up a window with
some red and green LEDs that show IO status. So, iosh
lets you program both the PLC logic and the GUI
appearance in the same script. So, unlike bridgeportio,
which doesn't pop anything up, iosh pops up a blank
canvas that your script can populate with whatever you
program. If you choose to write just a straight PLC
program, the canvas is just a little annoying blank square.

If you want to use a PC as a PLC without running the
EMC, you can still use iosh and your own script. The
NML buffers will be created and simply ignored, and you
can write your PLC and accompanying GUI for any purpose
whatsoever. Or, you can take iosh.cc, strip out all the
NML stuff, and just leave the inb/outb commands there
for your own stripped-down shell.

Or, you can use wish out of the box, write two short C
programs that create "inb" and "outb" (we did this),
put the in /bin, and call these within wish. This shows
how a Linux box can be converted into a PLC in about 10
minutes. Of course, you program in Tcl/Tk, not ladder logic.

Now, I like Tcl/Tk and if I had to write a PLC with a
gun to my head I'd use wish and the /bin/{inb,outb}
programs real quick-like. My opinion on the end-all,
be-all Linux PLC is something better:

1. It uses the Linux box for program development and
actual PLC execution. So, you don't use the Linux PC
for programming, then download the program to a
commercial PLC through a serial port. It's the whole
shebang. A PC can be overkill for simple PLC tasks,
but in my case the PC is also running a CNC and I
want to use the extra CPU cycles for a soft PLC.

2. It should be able to be programmed in any of the
IEC-1131 languages (ladder logic, structured text,
function blocks, instruction lists, and Grafcet),
just like a commercial PLC. So, it should have a
graphical programming environment, at least for
ladder, function blocks, and Grafcet, where you can
drag-and-drop icons for ladder symbols, logic blocks,
etc. to build your PLC. Structured text and
instruction list programmers could use plain old text editors.

3. It should support I/O board and I/O point
configuration. You'd be able to associate logical
inputs 0-4 with parallel port input bits 0x379/0-4,
logical inputs 5-12 with 8 bits of input on your
Keithley Metrabyte I/O board at 0x300/0-7, logical
outputs 0-7 at 0x301/0-7, etc.

4. At least three options for program execution:

* a. Programs are executed directly via interpreters
specifically written for each one.

* b. Programs are converted into some binary format,
like Siemens proprietary format, and run on an
emulator. This lets you write programs that could be
downloaded to a commercial PLC, or run existing PLC
programs from commercial PLCs on your PC in the emulator.

* c. Programs are converted from the IEC language into
an intermediate form, compiled using native compilers
for Linux, and then run as Linux executables.

I lean toward (c). (a) requires coding and maintaining
five interpreters, and interpretation is slow. (b)
requires building a PLC emulator, which means picking
one, reverse engineering it, and suffering emulation
overhead, although it does have the advantage of being
able to run legacy PLC programs on a PC. Not a selling
point for my needs.

With (c), I'd pick conversion to C for maximum
portability. That is, I could write in any of the
IEC-1131 languages, generate C code, compile for my
Linux box or move the C code to another system and
compile for other processors. With RT-Linux, the code
could run in the restricted RT space and be
deterministically real-time. Or, I could run the PLC as
a user-level Linux process if strict determinism is not
a requirement. I/O boards typically come with some
C-language driver or interface code on DOS floppies, so
this is easy to handle. It's also possible to link in
arbitrary C libraries in order to deal with things like
serial ports, custom boards, TCP/IP sockets, the EMC
NML communication buffers, etc.

If the C code generator includes creation of NML and
handling it in the read-execute-write PLC cycle, then
we could write EMC I/O controllers in say ladder logic
and plug them right into the EMC. The sequence would be
read inputs, read NML commands, run logic, write
outputs, write NML status, wait until next cycle...

The graphical console interface could be attached a
variety of ways, many of which work with method (a).
They could be written in X, Motif, Win32 (for C code
compiled on a Windows box), and linked directly into
the PLC code. I prefer separating the two as we did
with the EMC, and having a separate process. In my
case, I'd write something equivalent to emcsh,
effectively iosh upside-down, for writing commands to
the PLC, reading status from it, and displaying it
nicely. This would let you build standalone PLCs. If
you're plugging into the EMC, there need not be a
separate GUI for the IO controller, since it could be
part of the tkemc or a popup script.

The development cycle would begin with the programmer
designing the PLC. Then, he'd bring up the programming
tool, which might just be a text editor for structured
text or instruction lists. Once the program is written,
he'd run the code generation tool and get C code. Then,
a make to build the executable. The GUI would be
written separately, if it's needed at all.

As part of the development environment, we could write
a GUI with buttons for each part of the cycle, e.g.,
[EDIT] [GENERATE] [COMPILE] [RUN]. If the skeleton were
sophisticated enough, it could mark execution points so
you could [PAUSE] [STEP] [EXAMINE] and [RESUME]
execution. This is a separate thing from the PLC
console GUI, which might just have LEDs showing I/O
points, execution time health bars, etc. and would run
for the tens of thousands of hours the PLC is alive.

First I want to find out what linuxplc.org has. It may
be just what we want, except for the NML connectivity,
which we could add. If we have to start from scratch,
here's what I think needs to be done:

1. Decide on the structure of the C code skeleton that
implements the read-execute-write-wait cycle, and
handles NML.

2. Design the programming tool, the thing that lets you
lay out ladder rungs or logic blocks. I would start
with structured text or instruction lists, so a text
editor would suffice for this. Later would come the
integrated development environment with the [RUN] button.

3. Write the converters. We need one for each language,
converting programs written in each to the flesh on
the C skeleton. I'd start first with structured text
or instruction lists. Will Shackleford has written
code generation tools in Java. I don't know what to
use here. I'd do it in C.

4. Lastly is just compilation using the Gnu compilers,
which we get for free.

(1) is moderately hard, (2) is done if we start with
the text languages, hard for the integrated development
environment, (3) is hard, (4) is easy makefile stuff.

--Fred

A.7 Does EMC support probe digitizing?

Yes the EMC does support probing. There is a working
probe routine under the tkemc scripts menu. If you are
using steppers, you can access the probe pins on the
parallel port. They are settable in the script.

A.8 How to alter the direction of axis ?

You can just swap the leads on your axis (stepper or
servo) motor. You do it in the software by putting a
negative (-) in front of your inputscale value. You may
have to do the same to the outputscale if you are using
some of the motion modules.

A.9 What happens when you press the home button ?

Numbers turn from yellow to green when each axis is
homed. Assuming you can jog, when you select an axis
and hit the home button, that axis should start seeking
slowly towards the home switch (speed and direction are
configurable), and should stop (or reverse, or continue
a little further depending on the configuration in the
.ini file) when the switch is activated. At that point
the numbers turn green. If you set the home switch
polarity such that it matches the state that the input
bit naturally floats toward, then the axis should home
immediately when you push the home button.

A.10 I'm wondering if there is an official pinout for
EMC in six axes mode (hexapods)?

If there is no official assignment yet, could we agree
on one?

Existing DB25 EMC pins:

2 - X dir

3 - X clk

4 - Y dir

5 - Y clk

6 - Z dir

7 - Z clk

Proposed 3 more axes:

8 - A dir

9 - A clk

16 - B dir

17 - B clk

1 - C dir

14 - C clk

(or should we be calling the axes: X, Y, Z, U, V, W ?)
Another assignment goes like this:

Pin 1: Motor 4 DIR

Pin 2: Motor 0 DIR

Pin 3: Motor 0 STEP

Pin 4: Motor 1 DIR

Pin 5: Motor 1 STEP

Pin 6: Motor 2 DIR

Pin 7: Motor 2 STEP

Pin 8: Motor 3 DIR

Pin 9: Motor 3 STEP

Pin 10: (unused)

Pin 11: (unused)

Pin 12: ALL Motors REFERENCE SWITCH

Pin 13: ALL Motors NEG. LIMIT SWITCH

Pin 14: Motor 4 STEP

Pin 15: ALL Motors POS. LIMIT SWITCH

Pin 16: Motor 5 DIR

Pin 17: Motor 5 STEP

Pin 18-Pin 25: GND

A.11 Is there an easy way to change the accuracy used
in EMC?

It seems that the g-code writer (Enrout) doesn't want
to write distance and arc values to four decimal places.
Is there an easy way to downdrade the accuracy
required by the EMC interpreter to .001 from .0001.
This is mostly a problem when trying to match radii to
begin and end points. The easiest way is if you can use
the R word (radius) instead of I and J. This gets rid
of most of the problem. If not, there are parameters
that are compiled into the code.

/* numerical constants */

#define TOLERANCE_INCH 0.0002

#define TOLERANCE_MM 0.002

#define TOLERANCE_CONCAVE_CORNER 0.01

in emc/src/rs274ngc_new/rs274ngc.hh

Change these to what you need and recompile. This did
solve most of the problem of using the EMC with Enrout
files although Enrout still ocasionally throws in a
line with g1 and nothing else.

A.12 How does autotune work ?

Max wrote:

On the EMC Handbook on [http://www.linuxcnc.org||http://www.linuxcnc.org] under PID Tuning I found some
lines of text from "Fred's PID Report":

"The student, Kees ("Case") Stolk, from the University
of Twente in the Netherlands, wrote a Tcl/Tk script
that automates much of the process, including going
into machine-off, opening the log, running the DAC out
command, saving the log, storing multiple runs, and
popping up PID gains. It's pretty slick. I'll put this
up on the FTP site once I verify that it works with the
new release."

That sounds interesting, where can I find it? I found
the pidtune zip files on the nist ftp server but not
this Tcl/Tk script.

Some of Kees' Tk scripts have disappeared, I think
since they were on a local disk instead of our file
server. I've tried to track them down but can't find
them. What we have is the analysis, and a TkEMC button
to generate the logs used as input to the analysis.
I'll try to resurrect Kees' Tk code. Here's a
description of what we did.

The anaylysis presumes amplifiers in current mode. If
you're in velocity mode, you'll have a tach fed into
the amplifier, and tuning means setting the velocity
feedforward gain to match the volts per units per
second you get (e.g., you may measure 1 volt = 1.7
inches/sec, so FF1 = 1/1.7). Then you crank the P gain
up to clean up the residual error.

In current mode things are a little different. For a
given DAC voltage, the velocity v. time plot starts at
zero and follows a curve that looks like capacitor
charging, eventually attaining a steady-state velocity.
The steady-state velocity is a function of the DAC
voltage, and the time constant is about the same for
all DAC voltages. If you plot the steady state velocity
v. DAC voltage for several tests (1V, 2V, 3V, ...,
10V), you'll get a linear plot with an X offset. This
offset is the threshold voltage, below which the axis
doesn't move. The slope of the plot is the volts per
units per second, as above.

So, you'll now have the slope "k" and the time constant
"t" for your system. You then pick a design parameter,
lambda, which basically means the crispness of your
control. You can't choose this arbitrarily high since
the resulting output voltages exceed your DAC limits.
Given k, t, and lambda, then

P = 2 lambda + t / k lambda^2

I = 1 / k lambda^s

D = 2 t / k lambda

The "pidtune.zip" file is a ZIP archive of 6 MS-Word
documents describing the analysis. I made little
posters of these that we keep down by the Bridgeport
for demos. There are some literature references provided.

To generate the logs in TkEMC, go into
Settings-Logging..., select a log type of "Pos and
Voltage", and start the log. The actual data logging
won't begin until a DAC output command is received. Do
this in the Settings-Testing... dialog. When you reach
steady state, stop the log and zero the DAC.

Kees' Tk script basically did this for you.

--Fred

A.13 What is BDI ?

It is a CD on which Paul Corner has placed all of the
Linux, Real Time Linux, and the EMC (Enhanced Machine
Controller). It is called the Brain Dead Install, hence
BDI. With this CD and a reasonable standard pentium,
cyrix, or K6 computer, you can control machines. All
kinds of machines from common mills and lathes to robot
arms and hexapods. You can find BDI distribution places
from from [http://www.linuxcnc.org/bdi/||http://www.linuxcnc.org/bdi/]

A.14 What is the minimum specification of the computer required?

An old P133 with 16-32Mb RAM, a 500Mb IDE hard drive,
and a CDROM drive that can be booted from. If you want
good performance from stepper motors, a Pentium 233 or
better is recommended.

A.15 Can I use a laptop computer

This is allways a difficult question to answer. Most of
the laptop computers use non-standard hardware for the
LCD screen, some of which are supported under Linux.
The CDROM drive can also be a major source of trouble
especially if it can be swapped out of the same bay as
the floppy drive.

In short, unless you are experienced in installing
linux on a laptop, buy a cheap desktop computer. This
is not to say it is impossible, rather it is outside
the scope of this FAQ.

A.16 Do I need to install Linux first ?

No - The BDI automatically installs and configures
linux along with EMC.

A.17 Will it run under Windows 98 ?

No. The install will remove the Microsoft virus for
you. :)

A.18 Can I run a hexapod with it ?

Yes you can.

A.19 I get a screen full of error messages, but no
graphical install screen when I try to install the
BDI ?

The install CD is not recognizing some of your
hardware. Try to change your display card to some other
listed in [http://www.redhat.com/support/hardware/||http://www.redhat.com/support/hardware/] "supported-hardware"-list. You could also
ask if there is version of BDI-CD that can handle your
hardware. You can also look for answer from BDI's pages
at [http://www.linuxcnc.org/bdi/ ||http://www.linuxcnc.org/bdi/ ]

A.20 I can't access the floppy drive with the Floppy icon.

The floppy icon on the KDE desktop need to point to the
correct device/directory. Right click on the icon -
Properties - Device.Set both 'Device' and 'Mount Point'
to /mnt/floppy.

A.21 The computer crashes when I try to make a move in EMC

Try to edit your .ini file. Problem propably lies in
there. Try to run sim.run script and if that's ok, use
that .ini file as base for your own ini-file. Later on
we'll put couple of working ini-files here. For now,
you can find them from [http://www.linuxcnc.org/dropbox||http://www.linuxcnc.org/dropbox]

A.22 Can I print from the BDI linux ?

Yes - But to configure the print driver, you will need
two files found on the Programs page. Install
control-panel followed by printtool then open up a
console window and run printtool (you'll need to be
root to do this).

A.23 How do I burn a CD from the downloaded image ?

You have downloaded the ISO image of the BDI from the
web now want to burn a CD on a Windows box....

The following note was received from Mark Nudelman -

1) Download BDI .img file from [http://www.yty.net/cnc||www.yty.net/cnc]

2) Change the .img extension to a .iso extension

3) From a CD burning program (I used CD Creator 4.0)
create a CD using the "Create CD from CD Image" option
(do not try and create a regular data CD) and make sure
that the file type is "ISO Image Files:.

4) Insert this CD and a Linux boot floppy in the
computer that is to be loaded. ( I already had a boot
floppy from my previous install, but I think that
windows users can use a program called rawrite.exe to
help them create this boot disk. There was information
available on this process on the Linux site)

5) Reboot the computer and follow the BDI instructions.

A couple of extra notes from correspondence with other
people that have had trouble with the downloaded image.

It would appear that one or more files can be corrupted
during downloading or burning. Henkka has included a
checksum so that the disk can be verifyed. Please
follow the instructions before using the CD as a beer mat.

Step 4 should not normally be necessary unless the
computer will not boot directly from the CDROM drive.

A.24 What are all these error messages when I try to compile?

Date: Fri, 15 Sep 2000 10:13:06 -0400 (EDT)

From: Fred Proctor frederick.proctor@nist.gov

To: Multiple recipients of list emc@nist.gov

Subject: Re: Steppermod.o problem



David Johnson wrote:



> I have just downloaded the 11 Aug Release and have
installed it. My

problem

> is that when I run emc.run it returns with a message that

steppermod.o

> cannot be found.

> I've checked and it hasn't been compiled.

>

> Question is how or where do I set the

> -DSTEPPERMOTORS flag to make it compile correctly.



It should have been compiled, and since it wasn't there
may be some

Linux configuration problem.



I recompile using the makefiles, like this:



cd /usr/local/nist/emc/src

make PLAT=rtlinux_2_2 all



This should recompile everything needed for the
rtlinux_2_2 platform.

I

don't know which one you're using; it could be
rtlinux_09J, or

rtlinux_2_0.



You can trap the output of this by running "script",
which captures

terminal IO. Then, you can do a postmortem and figure
out what error

aborted the compile. Stick the script at the end of an
email and we

can

look it over. To script the above commands, do this:



you> script

Script started, file is typescript

you> make PLAT-rtlinux_2_2 all

..bunch of output...

you> exit

exit

Script done, file is typescript



The file "typescript" is created.



--Fred





A.25 Why does my PC slow down after running EMC?

This faq does not deal with EMC gui's being slow while
EMC is running. If you are using freqmod.o that problem
is most likely a PERIOD-parameter problem in your ini
file. If EMC has been running okay and now it seems to
be slow while running you may have a module problem.

EMC loads modules into the kernel whenever it runs.
There will be a different set of modules running
depending on which rtlinux kernel you are using.
Sometimes these modules do not get removed or idled
properly when EMC shuts down. The following post from
Will may help you understand and solve the problem.



The rtlinux-2.2 version of EMC uses these realtime modules:



mbuff

rtl_fifo

rtl_posixio

rtl_sched

rtl_time



The rtlinux-09J uses this realtime module.



rtl_sched



If you encounter a problem with modules please post
your comments and

results to emc@nist.gov



From: shackle shackle@cme.nist.gov

To: Multiple recipients of list emc@nist.gov

Subject: Re: mbuff in 2.2.14 rtlinux-2.2



On Mon, 11 Sep 2000 11:13:19 -0400 (EDT), Ray said:



>

>

> Folk

>

> This should only be a problem with rtlinux-2.0 or later.

>

> I've been running the EMC as a user rather than root
for some time

and

> have found an interesting problem that crops up now
and again.

>

> After exiting the EMC, mbuff seems to get captured by another

> process. Then when I start EMC again it seems to
share mbuff and

after

> a few starts and stops it doesn't run properly at all.
The

sysmptoms are

> a very slow start of emc and there are big delays in
the mouse

functions

> when using tkemc.

>

> In order to run as a user, one thing I had to do is:

>

> chmod a=rw /dev/mbuff

>

> It would appear from xosview that when this problem
occurrs, mbuff

is

> causing my system to use 100% of the processor's
power. (perhaps

this is

> related to the problem noted in a recent post by Jan)

>

> After this error has occurred I get this report from lsmod:

>

> Module Size Used by

> mbuff 5356 3

>

> And when I run the EMC I get delayed responses from
tkemc and the

> following report from lsmod.

>

> Module Size Used by

> steppermod 152652 0 (unused)

> rtl_fifo 7336 0 (unused)

> rtl_posixio 6684 0 [rtl_fifo]

> rtl_sched 36756 0 [steppermod]

> rtl_time 14080 0 [steppermod rtl_posixio

rtl_sched]

> mbuff 5356 7 [steppermod]

>

> The only way I seem to be able to fix the problem is
to reboot.

Any hints

>

> Ray

>

>

>

>

>



The next time this happens try some/all of the following.



It's a good idea to save any files your editing, exit
the editor and

run sync a

couple of times first since there is a fair chance we
are going to

hang the

system completely.



Run top to see which processs are taking the most cpu time.



If the highest process on the list is not idle, top, or init.



Try killing it with killall



killall processname



If it doesn't disappear off the top list, try the same
as root and/or

try:



killall -9 processname

(Warning killing some system processes will hang your system)



Run ipcs to see what shared memory segments and
semaphores were left

around



Use "ipcrm" to delete them.



ipcrm -shm id



ipdrm -sem id



Try removing the modules one at a time.



rmmod steppermod

rmmod mbuff

. . .

---Will





--

-------------------------------------------------

William Penn Shackleford III shackle@nist.gov

National Institute of Standards Technology Tel: (301) 975-4286

100 Bureau Drive Stop 8230 FAX: (301) 990-9688

Gaithersburg MD 20899 USA

http://www.isd.mel.nist.gov/personnel/shackleford/

Office Location: Bldg. 220 Rm A253





A.26 What can I do to remove mbuff from the kernel
after running EMC.

Sometimes when EMC shuts down, it does not clear out
all of the sectors in mbuff and running the command
(rmmod mbuff) gets a "device or resource busy" response.
You can see what modules are loaded using the command

lsmod

or

/sbin/lsmod.

The problem is that when the EMC starts up, it attempts
to install mbuff and then uses mbuff to allocate a
block of SHMEM under the name emcmotStruct. Sometimes
it creates several of these and does not remove them all.

Solution: Find the mbuff directory in the realtime
stuff. For the box that I'm writing this on it is
/usr/src/rtlinux-2.2/drivers/mbuff/. Change into that
directory and issue the command

make test

This will compile some executable files that exercise
mbuff. It also runs one of them and attempts to use
mbuff. You will probably get a core dump but it will
not stop your PC. Just delete the file named core. You
will see the test program adding and deleting spaces
using mbuff. After a bit the test program will just
quit. Pressing enter will get you your terminal prompt again.
Now enter the command

./mbuff_dealloc emcmotStruct

Below is a sample of what the command and response
might look like:

[root@localhost mbuff]# ./mbuff_dealloc emcmotStruct

emcmotStruct shared memory area was 0 bytes long

The zero answer means that it found a block and removed
it. If you get a "-1" answer it means that dealloc did
not find the named block.

Most of the time, there will only be one emcmotStruct
left laying around and you can issue the command

rmmod mbuff

or

/sbin/rmmod mbuff

and you should get a terminal prompt with no messsage.
If you get the "0 bytes long" response and still rmmod
says device or resource busy repeat the dealloc command
until you get a "-1" response and try again. If you are
not able to remove mbuff, you will need to reboot your computer.

A.27 emctaskmain.cc 2322: can't initialize interpreter

Check your .var file (The name of the .var file is in
the .ini file) and see if

5220 0.0000

Should probably be

5220 1.0000

What is 5220? 5220 is the coordinate system number used
by EMC. If it's "0", EMC doesn't know what coordinate
system to use.

A.28 emctask.cc 245: rs274gnc_error: Radius to end of
arc differs from radius to start

I had the same problem a while ago. Look at
src/rs274ngc_new/rs274ngc.hh at the beginning an
decrease these values.

/* numerical constants */

#define TOLERANCE_INCH 0.0002

#define TOLERANCE_MM 0.002

Once you have changed them => recompile.

Max

A.29 <fsck>While booting the computer following error comes
up: /dev/hda2 :unexpected inconsistency; run fsck
manually (i.e, without -a or-p options.

You should give your root password and issue following command:

fsck /dev/hda2

Notice space between the command and the parameter.
"fsck" is short for File System ChecK, it's quite same
as scandisk in Microsoft-world. It's generally good
idea to check all filesystems after crash. You can do
that by checking what filesystem you have and them
checking them all. First check what you have by issuing

cat /etc/fstab

[henkka@kilpikonna henkka]$ cat /etc/fstab

/dev/hda1 / ext2
defaults 1 1

/dev/hdg5 /varmistus ext2
defaults 1 2

/dev/hdg6 /home ext2
defaults 1 2

/dev/hda5 /usr ext2
defaults 1 2

We are looking for entries where 3rd item is "ext2"
(filesystem type) and we should check them all by
issuing fsck to them one by one. In my example,
commands would be like this:

fsck /dev/hda1 [enter]

fsck /dev/hdg5 [enter]

fsck /dev/hdg6 [enter]

Replace those with your own partitions. You will be
asked if you want to repair/fix the filesystem. You can
almost allways answer "Y". The "fsck -a /dev/hda2"
command would answer "Y" automatically, but it's not
recommended in this situation as there could be some
filesystem damage that is better to leave unrepaired.
After you have run all the "fsck" commands, issue
"reboot [enter]" command for rebooting your machine.

A.30 What to do when the system crashes and there's no
choise but "cold boot" it ?

Here is my long list of things to try when the system
crashes, although after you read it you might decide
reinstalling the BDI is the best alternative after all.

After it crashes but before you hit the reboot/power
switch you can try these:

CTRL + ALT and one of the keys F1 through F7

All pressed simultaneously are used to switch between 7
virtual screens. Usually X windows runs on 7 and text
only consoles run on the rest, so for example
CTRL+ALT+F1 should switch to a text console.

* If you can't get a text console skip to "[Notextconsoleavailable]"

* If you can get to a text console it may be that X
windows is hung.

* If X starts at bootup and you normally use a
graphical login You can kill X and all of the
programs running on it by switching run levels:

Log into the text console as root and run

init 3

to switch to run-level 3 and therefore kill X

init 5

to switch back to run-level 5 and therefore restart X.
If you normally use

startx

from a text console to start X, you can try using

CTRL+ALT+BACKSPACE

to kill X or the command

killall xinit

or

killall -KILL xinit

A.30.1 <Notextconsoleavailable>No text console available

If you can't get a text console you can probably still
do a softer reboot using the "magic sys request keys".
These have to be enabled beforehand both in the kernel
configuration and in /etc/sysctl.conf. The entry in
sysctl.conf to add is

kernel.sysrq=1

You also need to run "sysctl -p" or reboot after
modifying sysclt.conf. To actually use "magic sys request"
, you should press following keys:

ALT + SysRQ + S

ALT + SysRQ + U

ALT + SysRQ + B

Keys on the same line are pressed at the same time. The
SysRQ key is ussualy the same as the "Print Screen" key.

If you have to hit power button without doing a
controlled shut down, it is likely your harddrive will
be left in an inconsistant state. If you boot linux
with an out of sync harddrive it should automatically
run fsck. fsck is similar to scandisk it can take a
long time and prints lots of cryptic messages, but the
great majority of the time it cleans everything up and
will eventually boot linux and everything will be ok.
If not, see previous [fsck].

On the hopefully very rare occasions that all of the
above has failed. You can try using the install disk as
a rescue disk. I belive the command is "rescue" typed
at the first redhat install screen. This ussually dumps
you in a text console. You could try running fsck with
a variety of different options to fix problems fsck
doesn't fix in automatic mode. You can also use fdisk
to check the partition table. Another thing that has
happened to me a couple of times was to modify the
kernel and reboot without having run "lilo" or properly
edited lilo.conf. You can run lilo from the rescue
environment, just be sure to find the copy of lilo.conf
that was on the harddrive and use

lilo -C /mountpoint/etc/lilo.conf

You can use the "mount" command to help figure out what
mountpoint is. Look for something like /dev/hd?? or
/dev/sd?? on /mountpoint

-- Will

A.31 Is there any "commandline" version of EMC for
debugging or error finding ?

Some long time ago I had a problem setting up EMC. I
then read about usrmot in the NIST docs.

usrmot A terminal-based diagnostics program that
connects to the EMC motion controller, not the
top-level EMC, and lets you type in motion commands
and view status. It only requires that the motion
controller be running.

You can even move your machine with usrmot. help or ?
will give you a summary of what is available. For
running usrmot you do not have to run all modules or
the gui, but see below. <shameless quote from
http://www.isd.mel.nist.gov/projects/emc/emcsoft.html#USRMOT>

Using the USRMOT Motion Utility

USRMOT is an interactive text-based utility that is
used to set and test motion parameters for the EMCMOT
motion controller. To use

USRMOT, first run EMCMOT standalone (yourprompt>
represents whatever your system prompt is):

yourprompt> emcmot

In another window, run the USRMOT utility:

yourprompt> usrmot

motion>

The motion> prompt is displayed by USRMOT when it runs.
Entering a blank line lets you see the status:

motion>

mode: free

cmd echo: 0

split: 0

heartbeat: 605

compute time: 0.014992

traj time: 0.200000

servo time: 0.020000

interp rate: 10

axes enabled: 0 0 0

cmd pos: 0.000000 0.000000 0.000000

act pos: 0.000000 0.000000 0.000000

velocity: 10.000000

accel: 100.000000

id: 0

depth: 0

active depth: 0

inpos: 1

vscales: Q: 1.00 X: 1.00 Y: 1.00 Z: 1.00

logging: closed and stopped, size 0, skipping 0,
type 0

homing: ---

enabled: DISABLED

</quote> and another quote, again by Will, from this
list from 13 March 2000 <quote>

Unfortunately there are a lot of reasons for not being
able to come out of estop. Ussually I start to look for
the reason by running plat/linux_2_2_13/bin/usrmot -ini
mymachine.ini And entering "show flags" to see most of
the flags that might prevent you from coming out of
estop. </quote>

and yet another quote from Fred from 17 March 2000
<quote> You can run the "usrmot" motion controller
utility when the whole controller is up, or just if the
motion controller is loaded. If you just load the
motion controller, you can send its .ini file
parameters down to it using the "inimot" utility, like this:

you> cd /usr/local/nist/emc

you> insmod plat/rtlinux_09J/lib/stg2mod.o

you> plat/linux_2_0_36/bin/inimot -ini yourfile.ini

(some messages saying initing axis #...done, or
something like that)

you> plat/linux_2_0_36/bin/usrmot -ini yourfile.ini

motion> help

(shows terse help list)

motion> [ENTER] shows status

motion> enable

motion> show pids

motion> [ENTER] shows just the PIDs

motion> show times

motion> [ENTER] shows the min/max/average compute times

motion> show

motion> [ENTER] shows full status

--Fred

</quote>

Max

A.32 How does EMC's copyright work ?

This page is compiled from responses to the first post
requesting information about the EMC copyright.



_________________________________________________________________



Cheng-Chang Wu chengchangwu@yahoo.com

To: Multiple recipients of list emc@nist.gov

Subject: Copyright

X-To: emc@nist.gov



Hello,



I see from the home page linuxcnc.org that EMC is a

open source project. But I can't find the copyright of

it.

It seems to me that EMC is a product of the

government, so it is only for american firms? If it is

really so, it can not

a open source project according to the definition.

"Open Source" is already a trademark in USA with a

good definition.



I'm writing this e-mail because I like the idea of

EMC, but I want to respect the copyright law of USA.

I'm

considering to start a CNC project if EMC is not a

really open source project.



Best regards



Cheng-Chang Wu

_________________________________________________________________



Ray Henry rehenry@up.net



Cheng-Chang Wu

Interesting questions!



I am an EMC user here and don't pretend to represent NIST

or the US government. My comments are mixed into your post.



At 10:38 AM 5/24/2000 -0400, Cheng-Chang Wu wrote:

>

>Hello,

>

> I see from the home page linuxcnc.org that EMC is a

>open source project. But I can't find the copyright of

>it.



The EMC files themselves are all public domain and may be

used in any manner you choose.



> It seems to me that EMC is a product of the

>government, so it is only for american firms? If it is

>really so, it can not



No. The public NIST work on EMC is available to anyone

for any purpose whatever. There are users scattered all over

and there are almost as many ways of using parts of EMC
as there

are users.



> a open source project according to the definition.

>"Open Source" is already a trademark in USA with a

>good definition.



You are correct that there are a number of valid
definitions of

open source projects in the USA. NIST itself has not applied

any one of the "copyleft" definitions to EMC.



I reserved copyright on tkbackplot in it's original
form but opened

the tkemc popup version as public domain. The scripts
that I've

written have no explicit copyright.



Dan Falck, Matt Shaver, and I have talked a bit about
this problem.

I think that Dan will soon place the contents of
linuxcnc.org under

some copyleft definition so that it will be easier for
others to

contribute to it without feeling that some big company
can borrow

it for their own inordinate profit.



I personally would like to see you contribute to EMC
rather that

spend a lot of time writing your own machine control.
But you should

feel free to use any part of the current EMC in any way
that you want.



Do you feel that you need gpl or some other copyleft
protection for

the work that you want to do? Public domain is no
protection at all!



I'd like to hear some serious discussion of this issue?
Is public

domain holding us back from serious collaborative work
on EMC?



Ray

_________________________________________________________________



Cheng-Chang Wu chengchangwu@yahoo.com

To: Multiple recipients of list emc@nist.gov

Subject: Copyright

X-To: EMC emc@nist.gov



Hi, Ray,



I'd like to contribute to EMC, that's why I wrote the

e-mail:-)



>Do you feel that you need gpl or some other copyleft

>protection for

>the work that you want to do? Public domain is no

>protection at all!



Public domain is OK with me. I like GPL very much, but

I don't think it is the best copyright for a project

like EMC. Six years ago I worked for a small machine

tool company for four years. They needed a NC

controller for their special machine. The controller

had to work with their technologies. I couldn't have

opened ALL the source code, because that would have

revealed their secrets. There are many such small

companies. They have technologies and special

machines, but they have very few programmers. An

open-source solution is great for them, but they need

to keep their technolgies in secret in order to be

able to compete with large companies. A large company

don't need open source.



I have just read FSF's comments about various licenses

at [http://www.fsf.org/philosophy/license-list.html||http://www.fsf.org/philosophy/license-list.html].

But I can still not decide which license is good for

EMC. Perhaps pulbic domain is already good enough for

me.



Best Regards



Cheng-Chang Wu

_________________________________________________________________



Will Shackleford shackle@cme.nist.gov

To: Multiple recipients of list emc@nist.gov

Subject: Re: Copyright

X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6
sun4u sparc

X-To: emc@nist.gov



EMC is "public domain". Since it was produced primarily
by the US

government

by law it can't be copyrighted.



It can be used by non-US firms.



In fact unlike most GPL copyrighted code, it can be
used as part of a

commercial

application and there is no requirement that such an application

release its

source code.



BTW. The term "Open Source" is not copyrighted anymore. See





In short, You can safely use EMC without fear of
violating a

copyright.



However, EMC is not OSI certified, and probably won't
be anytime soon.



-- Will

_________________________________________________________________



Chris Stratton stratton@mdc.net

To: Multiple recipients of list emc@nist.gov

Subject: Re: Copyright

X-Mailer: ELM [version 2.4ME+ PL54 (25)]

X-To: emc@nist.gov



Because the core EMC code is in the public domain, you
can release

your extensions to it under any license you choose -
from public

domain, to open source, to fully proprietary.



If you use some of the extensions others have written
which are not

public domain, you will need to use a license
compatibly with the

terms already applied to those extensions.



Otherwise, it would be nice if you release as much of
your work as you

can under as open a license as your are comfortable
with, but you are

under no obligation to do so.



Perhaps the best thing to do would be to separate any
work you do into

different modules. Everything that is of general
interest gets

released under your favorite open source license.
Anything specific

to proprietary technology in a particular machine
wouldn't be as

useful to others anyway, so don't release that part at all.



Just some thoughts from someone who's played with EMC
but is not

currently running it.



Chris

_________________________________________________________________



Jon Elson's reply to James Owens



Date: Thu, 13 Jul 2000 16:03:18 -0400 (EDT)

Subject: Re: EMC - a practical implementation?



james owens wrote:

> Hi All,

>

> I have got to add my tuppence worth. Don't get
carried away with

> indignity that someone who is looking to hi-jack the
whole project

for

> commercial gain. These people wish to put it in a
pretty package on

> one CD where the end user inserts and presses go.
They are not in

the

> business of doing the hard work by writing the
software then proving

> it, they are marketing salesmen and as such when and
if the software

> gets to the stage of insert and go the likes of you
and me will be

cut

> out by copy-write law suits as they claim it all as
their own idea.

> EMC will no longer be FREE.



This cannot happen. The software may NOT be copyrighted by

a 3rd party, and anyone attempting to do so may become
a violator

of federal law. The can sell it as part of a package.
But, they

probably can't sell it (the software) standalone for
more than a

reasonable cost of media and production. And, they absolutely,

certainly cannot prevent anyone else from using it, distributing

it or selling it. This would be almost like somebody coming

in the night, stealing your car and then leasing it
back to you.

Property they CLEARLY DO NOT OWN cannot become theirs,

just because they say so. I'm sure NIST knows how to
deal with

this sort of thing, it must have come up before.



Jon






______________________________________________________________________



Fred Proctor



Date: Fri, 14 Jul 2000 15:58:47 -0400 (EDT)

From: Fred Proctor frederick.proctor@nist.gov

Subject: EMC software copyright, etc.



EMC folks,



The EMC software was written by us U.S. government
employees, and is

not

subject to copyright. It's public domain. If we tried
to keep it out

of

your hands we couldn't, because of the Freedom of
Information Act.



You can do anything you want with it, like give it
away, sell it,

whatever. You can't copyright it yourself.



You can put an EMC on a machine tool and resell it, as
some of you

have

done. This is great. You can make an easy-install CD
and sell this for

big bucks, no problem.



We wrote this to support our work testing plug-and-play
standards for

machine tools and robots. There's no warrantee,
support, or anything

like that. The emc@nist.gov mailing list is the
support, and it's

working great.



--Fred






______________________________________________________________________



Jon Elson's reply to Brian Bartholemew



Date: Fri, 14 Jul 2000 15:34:07 -0400 (EDT)

From: Jon Elson jmelson@artsci.wustl.edu

Subject: Re: EMC - a practical implementation?



Brian Bartholomew wrote:



> I'm confused. I thought EMC, as required for
tax-funded government-

> developed software, was public domain. The design
goal of such

terms

> is that companies commercialize it, because this is
thought to

> distribute the created value back to taxpayers the best.



Yes, clearly a company can take advantage of the code,
use it

in a product, and sell that product. Indeed, that's the idea.

But, that company CAN NOT claim they now OWN the code, and

no one else may use it! That is entirely OPPOSITE of
the idea!



And, that is what someone was bemoaning as the fate of EMC,

that some company would "take it over", start selling
it on a CD,

and everyone would have to buy the right to use it from that

company. That WILL not happen!



Jon

A.33 How do I use Windows software with Linux (in case
I need it for some reason) ?

There are couple of options for using Windows software
at linux. First, and in my opinion most working
solution, is to use [http://www.vmware.com||VMWare] software. It allows user to
install w95/w98/nt4/w2k/linux etc. "client" machines on
top of "host" system, in this case linux. I'm using
this every day in my work. It seems rock solid and with
196Mb memory I'm running NT 4 server on top of linux
happily. Only thing about this solution is the price.
But there is an free alternative, [http://www.plex86.org||Plex86]. It's evolving and
it's getting better and better all the time. It
operates on similar priciples as VMWare. Third solution
is to use [http://www.winehq.com||Wine]. It operates with slightly different manner,
you can just run one application at the time. But even
this is sometimes enough. Fourth solution is to use [http://www.uk.research.att.com/vnc/||VNCViewer/VNCServer]
combination. It allows user to use -remote-
Windows-machine from linux machine and vice versa. It's
also free. It operates quite nicely over network, and
it saves the "state" of desktop between sessions. So
you can continue your work where it was left, even if
you are continuining the work in another computer.

A.34 I'm new to Linux, could you explain it a bit to
Windows-user who has been using "point and click"
-method ?

Point and click is a common affliction. Command lines
do not take much more effort at the level we need you
to use them.

Click on the little house icon on the bottom bar or
panel. It will bring up an instance of kfm, the file
manager. I assume that you are running as root and you
will be in the /root directory. You can always see
where you are in the file window. Press the up arrow
near the top bar of kfm and it will move you to /. Now
click on the usr directory icon then the emc directory
icon. Now you will display the correct directory for
running the emc. It should show you a bunch of files
like TkEemc and such. Hey, that's not so different.

Clicking on a text based file icon should show its
contents in a window. Right clicking on a terminal or
executable file and selecting open with should let you
look at those as well. Sometimes clicking on an unknown
file type will get you an open with window much like
you see in MS windows. At that point you can always
type kwrite and it will show you the file, even if it
is a binary.

A file named *.run, where the star has the usual
definition of any or all, is a start the emc file. In
one of these files about line 27 should be a variable
which points that run file at an .ini file. It will say
something like

INIFILE=ppmc.ini

except the file pointed to is the name of your ini
file. Perhaps it will be emc.ini. This information is
critical because that is the specific .ini file that
you will need to edit to work with that .run file. I've
made this mistake before, changing one ini while
running another. I kept wondering why my changes
weren't doing anything.

Now let's take one more little step away from the icons
to running from a terminal because that way you can
view the startup feedback and some of the run stuff.
The Kfm window that you got to this directory with
needs to have the focus. Kfm is the file browser and
focus means that the top line is a different color than
the background. (Click on the top line to change focus
to that window) Now press and hold [control] and press
t on the keyboard. This opens a new terminal so that
you can enter text commands. This keystroke, [control]t
, opens that terminal in the directory shown in the kfm
window. This means that you should be ready to go to
work entering text.

In the terminal window you will see something like

[ray@localhost emc]$

The $ means that it is ready to accept a command. the
emc] just before it is the name of the directory the
terminal is working in. Type in

./emc.run

(dot slash) and it should immediately say something
like file not found. This is a good thing if it goes on
with other stuff. It is this other stuff that will
allow you to begin to debug your setup.

With the mouse, you can click and drag across the lines
of the terminal window to highlight what you want. But
you can't press [control]c to capture them. Just leave
them highlighted and start kwrite, advanced editor, or
text editor from the K-menu in the bottom left corner
and select copy from the menu or press [control]v in
the editor and you should have a copy of the
highlighted text from the terminal. Copy that into your
favorite email program and we can comment on what we
see there.

Another option is to use "script"-program, if you manage
to get into a shell. You can issue the command

script

and all input and output in the shell's window will be
saved in a file named

typescript

After you are done running EMC you can enter the
command

exit

and a history of the complete session should be in
typescript-file. Emailing the complete file may be
better than trying to paste pieces of it together.

A.35 What are the files that are needed with EMC ?

The REQUIRENAME header from emc.i586.rpm:

rtlinux

rcslib

ld-linux.so.2

libICE.so.6

libSM.so.6

libX11.so.6

libXaw.so.6

libXext.so.6

libXmu.so.6

libXt.so.6

libc.so.6

libdl.so.2

libm.so.6

librcs.so

libstdc++-libc6.1-1.so.2

libtcl.so

libtclx.so

libtk.so

/bin/bash

/bin/sh

libc.so.6(GLIBC_2.0)

libc.so.6(GLIBC_2.1)

libm.so.6(GLIBC_2.0)

libm.so.6(GLIBC_2.1)

And the same header from rcslib.1586.rpm:

rtlinux

ld-linux.so.2

libc.so.6

libdl.so.2

libm.so.6

librcs.so

libstdc++-libc6.1-1.so.2

libc.so.6(GLIBC_2.0)

libc.so.6(GLIBC_2.1)

libm.so.6(GLIBC_2.1)

If you do an rpm -q on the above libraries, rtlinux,
rcslib and librcs.so will not be found - They are just
references to the realtime kernel and rcslib that comes
with EMC.

A.36 How do I put EMC on floppies with ???.aaa, ???.aab
... files ?

Probably just put them all on the hard disk and go:

cat fname.[a-z][a-z][a-z] > fname.tgz

to aggregate them all into a single file, where fname
is the filename you have (want) and the .tgz is the
extension you expect (ie might be .tar.gz or .tar or .Z
or???). If it is an executable, you'll need to set the
executable bit with something like:

split -b 1440000 bigfile

which will make as many as necessary 1,440,000 byte
smaller files named: xaa, xab, xac .... The last file
will probably be shorter.

A.37 What is CVS and how it's related to EMC ?

CVS is Concurrent Versions System, used to maintain
easily different copies of evolving software. More
information from [http://cvshome.org/||http://cvshome.org/]. You can use CVS to fetch the
"bleeding edge" version of EMC. These versions are the
one's that are developed most actively so they can
easily be much more difficult to install than
(standard) versions (like BDI). Neverthless, the CVS is
there for you to fetch the sources for EMC and if you
are interested in using it, just visit the [http://cvshome.org/||http://cvshome.org/] and grab a
basic knoledge of the CVS system.

A.38 Programming in "TCL/Tk"-language, for example: "How
can I get the ESTOP-button to be red when the estop
is on?"

You can do it using a process, something like the
toggleEstop process but for the standard tkemc,
modifying the updateStatus process and adding the
configure commands to make changes to the estop button.
But there is a caution here that I will add after I go
through the code.

-----snip of updateStatus process-----

# now update labels

if {[emc_estop] == "on"} {

set estoplabel "ESTOP"

} elseif {[emc_machine] == "on"} {

set estoplabel "ON"

} else {

set estoplabel "ESTOP RESET"

}

-----end of snip -> suggested new-----

# now update labels

global estopbutton

if {[emc_estop] == "on"} {

set estoplabel "ESTOP" $estopbutton configure -bg
darkgray -fg white -relief sunken

} elseif {[emc_machine] == "on"} {

set estoplabel "ON" $estopbutton configure -bg red -fg
white -relief raised

} else {

set estoplabel "ESTOP RESET" $estopbutton configure -bg
green -fg black -relief raised

} -----end of modifications-----

The caution is that NIST has a philosophy concerning
their motion software. They are building their API so
that multiple HMI's and GUI's can connect to and take
control of a running motion control system. I walked
into Fred's office a couple years ago with some
beautiful and functional drawings of a control panel,
the logic of which lasted a few seconds because I was
using hard wired switches and HMI software that limited
the control of the EMC to only that panel.

Now you can do that for your machine and no one will
really care but it will be more difficult to get help
because most of us here are working with the standard
EMC running within the NIST philosophy. Those of us
that build custom stuff to go with it accept the fact
that we are out on a limb by ourselves.

Let me apply this back to the code that I wrote for you
above and see if we can understand the difference
between updateStatus and toggleEstop. Since
updateStatus executes several times a second as a loop,
putting something in it that references the running EMC
"emc_estop" the values of the button will always be
reasonably current regardless of what has caused a
change to estop condition.

If I were to make those changes only to a process
called toggleEstop and then ran that process when I
pressed the estopbutton, I would have created a bit of
code that does okay as long as it is the only process
that has access to estop. If estop changes state for
some other reason, the gui will not reflect the current
state of the EMC accurately.

The down side of doing this kind of stuff in a loop
process is that it stretches the time required for the
loop to complete or demands more speed in the processor
to run the program.

Ray

A.39 Another example of "TCL/Tk": Could someone please
send me a quick .tcl that will write a number to
variable # 1000? I just can't seem to get it.

The most basic way to set a variable is g-code

n10 #1000 = 50

or you can iterate it using

n140 #1000 = #1000 + 0.050

Then you can command an axis using the variable

n150 X#1000

See [http://linuxcnc.org.handbook/gcode/variables.html||http://linuxcnc.org.handbook/gcode/variables.html] for more.

Both genedit and Set_Coordinates.tcl show examples of
how to control a parameter value from Tcl. You should
note that you will need to re-read the var file after
the set using emc_task_plan_init if you are running
emcsh. And there are other effects of that command as
well that will have to be restored after the read.

For questions about EMC and integration with Linux, please see our mailing lists

For comments or questions about this web site, please see our contact info

[ Return to Home ]