Control Systems using Linux

H

Thread Starter

Hills,Henry

I have been developing software for PLC systems for over 20 years. Designed drivers for Modicon, Allen Bradley and misc other devices. Built MMI and MES, trending and SPC systems from the ground up. Designed systems that totally run on the PC using the OPTO product line. Built a Modicon 484 emulator for Virtech DCS. Have worked with Unix for the past 15 years and VMS for the past 10 years. Expert programmer in C, Fortran, Basic and Assembler languages. Expert programer with XLib primatives and Motif widgets. Have ported much of
my code over to Linux. We are currently running control systems off of Linux computers. Have done a lot of work with Oracle and Lotus Notes. Probably a lot more I could say but;

Is the mandate of the LinuxPLC only to develop PLC emulation to I/O ? There is a large need for the graphical interface.

Emulating a PLC is great but is there any activity to move ahead and develop more advanced capabilities? Would like to see graphical function block development tools with auto-tune algorithms for PID control loops.



thanks

Henry Hills PEng


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Henry,

The mandate is to graciously accept and attempt to integrate whatever someone will contribute. There was a _lot_ of interest and discussion on
languages and GUIs. It's just at this point we don't have the basics yet. Put another way, there's endless opportunity for someone like yourself ;^). Welcome! What shall we put you down for? :^).

Curt Wuollet,
Wide Open Technologies.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> Is the mandate of the LinuxPLC only to develop PLC emulation to I/O ? There is a large need for the graphical interface.
>
> Emulating a PLC is great but is there any activity to move ahead and develop more advanced capabilities? Would like to see graphical function block development tools with auto-tune algorithms for PID control loops.

I Would have to say that developing a PLC that is capable of driving i/o is the focus we are trying to obtain. Or am I reading your question wrong?

Ron Gage - Saginaw, MI
([email protected])


_______________________________________________
> LinuxPLC mailing list
> [email protected]
> http://linuxplc.org/mailman/listinfo/linuxplc
 
W

William L. Baker

>
>Is the mandate of the LinuxPLC only to develop
>PLC emulation to I/O ? There is a large need
>for the graphical interface.
>
>Emulating a PLC is great but is there any
>activity to move ahead and develop more advanced
>capabilities? Would like to see graphical
>function block development tools with auto-tune
>algorithms for PID control loops.

I've been putting a lot of thought into the
GUI for the past year. My approach has been
to develop the run-time display, creating the
display through any possible means, other than
direct C programming. The run-time display
works a lot like a conventional web browser,
with a few critical differences.

I put together a list of requirements for
such a system, the most important being:

- Text based mark-up language (HTML/XML/VRML/?)
- Reliable recreation of desired format:
this is the reason ref books are online in PDF,
not HTML.
- Interaction with a "real-time database" of
external data collection points.
- Cross platform.
- Network enabled...the "database" can be
anywhere, or even distributed.
- Support for both event-driven and polled
architectures. (Control systems such as FIX/
AB/W-WARE are typically polled, this creates
more problems than it fixes in the long run.)
- Eventual goal of running the GUI straight off
the frame buffer interface.

I investigated and prototyped several methods
including:

- HTML with java widgets...standard browser
- XML with Gtk and OpenGL...write browser
- VRML...standard browser

HTML turned out to be unreliable and complicated.

C+ XML + (your favorite cross-platform GUI
toolkit) is a workable solution, but perhaps a
little complicated. I would pick a toolkit
which had the possibility of running straight
off the frame-buffer interface...no X Windows.

VRML is still under investigation. It has a lot
of nice features, but is really focused toward
3D, while control systems are traditionally 2D.
There is no need for the "walk-through" enabled
browser in the control system.

Particularly nice in VRML is the ability to
interface with external I/O data points.

I had no idea so many other capable programmers
were interested in the same thing.
 
Top