Re: PLC

[Fred Proctor <frederick.proctor-at-nist.gov>]

Luc Vercruysse wrote:

> 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