Ideal PLC Programming Language and Software

  • Thread starter Bill Lydon, PLCopen North America
  • Start date
C
Python has a few issues as a PLC programming language, but if it can be used to, for example provide an instruction list to a bit faster and more predictable executive on the PLC hardware it would be attractive as an all in one solution. It can produce rather interesting graphics with relatively little code. Trying to run Python fast is a good way to benchmark hardware. I'd like to see what they've done as well. I never thought Java could run well on embedded processors, but look at Android.

Regards
cww
 
T

Tallak Tveide

Some thoughts:

The file format should be in text (utf-8) and as human redable as possible. The main goal should be to work well with text based version controll systems. Duplication in the file should be avoided wherever possible. Also, values generated by the PLC system should not be in the file, eg. When Step 7 places temporary variables on the stack these are placed at offsets on the stack. If you add a temp variable, all offsets are updated, causing a text diff to generate many different lines for effectively the same FBD code.

There should be some macro functionality that is run at some point during/after download. This way you could have for loops and 'real programming' for large systems without having to have a dynamic runtime system. The Elixir language wold be a nice starting point, but also Ruby I guess.

Object orientation would be nice as well, passing an object with data and methods as an input to a function block.
 
R

Rufus V. Smith

> I think that working with PLCs in python is a fantastic idea; python is a computer industry standard language that
> is nowhere as esoteric as the current PLC programming architecture.
>
> I've seen that somebody has created a python module for this; however, I've yet to try it.

I use Python nearly every day. I love it. But I would NOT use it for industrial control! (At least the Pythons I use) My main issue with it: It is interpreted, and does not know of an error in a section of code until it is actually executing it. So a lot of special case code, or error handling, may actually have undiscovered bugs or even simply typos.

With proper disciplines and unit testing and skillful exception handling, you could gain confidence in it, I supposed. But there's nothing like good old ladder logic (with function blocks, perhaps) to be sure a button is acted upon when its pressed, or the braking profile is put on a servomotor at the correct time, reliably.
 
> I use Python nearly every day. I love it. But I would NOT use it for industrial control!
----- snipped by moderator -----

Your comments are very interesting. I've used Python a little in the past. A few months back one of the engineering magazines I get did a large amount of coverage of Ada. It used to be very expensive but that is no longer true. I hope to spend more time looking at Ada since it is still a very good language for use in critical situations.

www.CtrlTerm.com - free open source communication tools
 
C

Curt Wuollet

> I use Python nearly every day. I love it. But I would NOT use it for industrial control! (At least the Pythons I use) My main issue with it: It is interpreted, and does not know of an error in a section of code until it is actually executing it. So a lot of special case code, or error handling, may actually have undiscovered bugs or even simply typos. <

That and taking a break for garbage collection at irregular intervals could be an issue.

But I am liking it better than I thought I would. Today's powerful machines make interpretation feasible for many uses.

Regards

cww
 
Top