Fanning the flames...


Thread Starter

Ron Gage

Hi folks.

After much deep thought, I decided to throw a little gasoline (petrol for you non-USA types) onto the fire - per se.

I am tossed up between writing a logic engine in either LISP, APL, or RPG-1.
ADA and PL/I are still possibilities as well as Prolog and TCL/TK.
Anyone have any opinions on this? :)

Tongue planted firmly into cheek!

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

P.S. I am thinking of changing the development environment to a Kaypro2 running
CPM... :)

LinuxPLC mailing list
[email protected]

As an old-time Ada'er (well, as old time as anyone can get<g>), I'd suggest you code in Ada, and not ADA. ADA is either the American Dental Association, or the Americans with Disabilities Act. Neither one is applicaable worldwide -- but the LinuxPLC needs to be applicable worldwide.


Mark -- or, if you insist, C/C++ _might_ be acceptable.

LinuxPLC mailing list
[email protected]

Curt Wuollet

Dog gone it, Ron

I had just switched on the PDP11/23 in my basement and tomorrow when it is finished booting I'm gonna crank out some DIBOL for the project. No networking on this beast so I'll have to ship a disk pack, or I can send paper tape. :^) I was thinking of Turbo Pascal 1 on my CP/M machine, but the memory map is already over 64k.



LinuxPLC mailing list
[email protected]
man, that's a facinating idea. My humble guess is using a good scripting widget for frontends (tcl/tk) and the heavier prolog and LISP for the logic recursions you need to implement. Interesting approach, prolog and lisp are used primarily for AI recursive searches...may be i need to read some more into this.

Johan Bengtsson

Since everyone is digging out their old computers for this I just might start looking for my commodore VIC 20 (Just kidding I know exactly where it is), basic might be a little slow for the I/O operations and logic engine, but for HMI it will work just fine. I have to post my contributions as sound files sampled from the
tapes however (I can compress them to .mp3 files if necessary).

This IS fun...

/Johan Bengtsson

P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]

LinuxPLC mailing list
[email protected]

Harald Albrecht

VIC 20's i/o and cycle speed is just enough for the average industrial chemical process. So let's clone the VIC (gene manipulation, anyone?) and sell it in large quantities to industy. However, change the name to "e-VIC", so controllers will like it.

Harald Albrecht

Harald Albrecht
Chair of Process Control Engineering
Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238
email: [email protected]

LinuxPLC mailing list
[email protected]
Ron Gage:
> I am tossed up between writing a logic engine in either LISP, APL, or RPG-1.
> ADA and PL/I are still possibilities as well as Prolog and TCL/TK.
> Anyone have any opinions on this? :)


That said, though, Prolog may well be a very sensible option. Or pick one of the modern logic / constraint-solving languages - Prolog is still
significantly procedural, which defeats the point of using it. Programming a machine in one of those babies would be cool.

Lisp would have the advantage of familiarity to anyone that uses AutoCAD (or emacs), and Tcl/Tk or Perl/Tk may be good for quick'n'dirty HMI.

INTERCAL, though, is king. We *must* have INTERCAL as one of the programming languages. At the very least, provide the operators.

Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

LinuxPLC mailing list
[email protected]

Ralph G. McDonald, P.E.

May I recomend forth with a TRS-80 color computer (2MHz 6809) as the development environment. I think I can find some old TRS-80CCs in the attic somewhere. Many years ago we actualy used them in small electical demand control systems with Opto22 16 point parallel racks connected to the rompack port( a MC6821 I think ).

Actually a forth type kernal running an intermediate code may work well at the heart of the PLC portion. Then the compiler(s) could be optimized for Ladder Logic, etc.

Any standard forth is easy to extend with secondary words, and after testing, any code required to optimize speed can be rewritten as a primary.

If you keep the number of custom primary words at a minimum then the code will eazy to port to any system that has a standard forth available.

Then drivers, HMI, etc may be written in what ever lanquage makes the most sense.

The compilers should also output names to a defined database that the HMI compiler interfaces with. I dislike manualy reloading point and address names and locations to an HMI.

Keep up the good work