> >Someone quite famous programmer (could be Larry Wall but I am not
> >sure) said something like "A programming language not changing the
> >way you think is not worth learning"

Bill Sturm:
> Yes, I agree with this. For an example, try learning FORTH. It is
> like no other language.

The other two would be a logical language and a functional language.

With logical languages, watch out for Prolog - it's the classical one, but it has an annoying left-to-right top-to-bottom thing; something more modern would be better (mercury?). Similarly for functional languages and LISP.

(Well, it's annoying if you're trying to change the way you think, anyway.)


> I am currently working on TCL/TK. It is a very impressive language
> for building graphical programs. TK is very clever.

You can get Tk for various other languages, too.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

Hi Bill

Agree on both of those. Forth is where you start with a tiny language and build it yourself, ideal for embedded and TCL/Tk is a very elegant solution to GUI's. It's so elegant it just keeps surprising you. Check out VTCL also, it's a shame that development isn't happening.

Regards

cww

 

Hello Curt, Bill and Dan.

So, would you like to say, what is the helpful _programming_ practice I get when I learn the LD?

...and I see no much connection between the learning of the FORTH and learning of the reusable code idea.

Thanks. Vladimir.

 

>Hello Curt, Bill and Dan.
>
>So, would you like to say, what is the helpful _programming_ practice I
>get when I learn the LD?

Lots of logic and interlocking practice, I guess.


>...and I see no much connection between the learning of the FORTH and
>learning of the reusable code idea.

In Forth, you must learn to wisely factor code so that the application specific code is left out of the new words (functions). Factoring is very useful in writing functions in most languages.

You also learn the benefit of programming from the bottom up and incremental testing. Again, very useful stuff.

Bill Sturm

 

Our approach has generally been the same, except more oriented towards manufacturing assembly operations. We put a great deal of emphasis on describing all the operating modes and operator interaction with the machine. When a machine has an operator interface display and keyboard panel (and most of ours do) we also want the screens and keys described with their associated modes. This is a document which the machine designer writes out, and we review.

I'm not really satisfied with it though. The degree of detail is up to the person writing it, so we often are left with screen layouts, but little information of what the machine really does in the mode associated with that screen. Many people seem to have difficulty in distinguishing between what the machine does (which is what we want to review), and what the program looks like (we issue guidelines, but don't do a formal review of the finished product).

I am going through a rather difficult project right now with a very large equipment builder who prefers to do all their engineering by the seat of their pants. They seem to have a great deal of difficulty in understand the concept of "planning". Their idea of a functional specification is to give a customer the same dozen pages of useless generic drivel which they give to all their customers (where they describe things like the difference between a "cell" and a "station"), with a one page appendix giving a very general operating sequence of all the machines. This is on a million dollar project!
So far they aren't writing anything down unless I stand over them and make them do it. This is despite the fact that we were careful enough to specify exactly what was involved in the review process as part of the contract.
My experience of dealing with other companies (smaller ones) has been that they are willing to co-operate in this sort of process, or will indeed insist on it. I use it myself for my own projects, even for cases in which I am the only person who will see the document.

> Walt Boyes - if you're out there, perhaps ISA can put together a standard
> on this topic!
<clip>
I think a really useful document would need to be oriented towards particular classes of equipment or industries. What might be suitable for a large process project would not be what someone building manufacturing assembly systems might want to see.
A standard or set of standards though would be very useful. If everyone is familiar with a method of documentation, it make things go more smoothly with less effort since all parties would understand what is intended. It also makes it easier for people to re-use parts of existing documentation on similar projects.

As part of this, I have been hoping to find some sort of formal method which can been used to determine that the described behaviour of a machine is logically complete and consistent. "Correctness" (whether the described
behaviour actually desirable), would of course still be up to the designers.
After having previously dismissed state diagrams and other similar formal methods as useless academic nonsense as far as automation systems are concerned, I found myself resorting to them recently to describe the required operating mode transfers in the project mentioned above. I've come to the conclusion that maybe there is something to this "academic nonsense" after all.
The written word is subject to interpretation. It is also easy to write something which is incomplete or inconsistent. I would like to have a means of completely and unambiguously describing what a machine will do (including all modes and states), along with how the operator interacts with it. It should not only be complete, it should be easy to *prove* that it is complete.

I am beginning to have a few ideas of what might work (this letter has helped to focus my thoughts), and I will write back in a few days asking for your opinion. It involves using state diagrams (and possibly sequential function charts) to describe machine behaviour and associating operator controls and messages with various parts of the diagrams.
However I would appreciate any comments you (or anyone else) might have on this subject. There are many methods used in the computer science field, but it is difficult to see how to actually apply them to automation projects. I think this would indeed be a very fruitful area for an ISA standard.


--
************************
Michael Griffin
London, Ont. Canada
************************

 

Hello Bill,

On Friday, January 18, 2002, 6:27:24 AM, Bill Sturm <[email protected]> wrote:

BS> Lots of logic and interlocking practice, I guess.

I guess, I aware of logic and interlocking...

See the logic:
I can get (learn) logic via learning the LD... and as well as via learning the RLL, and C, Fortran and via thousand of other languages... If my target is purpose is to learn logic, Why must I learn the LD? I must find the easiest way to learn logic. Is learning of the LD easiest way? No? - Goodbye. Yes?
- Sorry, I see no reason.

>>...and I see no much connection between the learning of the FORTH and
>>learning of the reusable code idea.

BS> In Forth, you must learn to wisely factor code so that the application
BS> specific code is left out of the new words (functions). Factoring is very
BS> useful in writing functions in most languages.

BS> You also learn the benefit of programming from the bottom up and
BS> incremental testing. Again, very useful stuff.

It looks like the suggestion to learn _BOTH_ the FORTH _AND_ the several concepts (bottom up programming, incremental testing, factoring).. Is there other method to learn the concepts without learning of the FORTH?

1. I do not know the FORTH, but I have a suspicion.. the FORTH is weakly connected to the concepts as well as C is weakly connected to the structured programming, and C++ is weakly connected to the OO programming.

2. There are a lot of buzz words in the world. And only a few concepts. So, the method (to learn a concept and a tool) is very dangerous (timeconsuming).

IMO.

--
Best regards,
Vladimir mailto:[email protected]

 

<p>
If you have been drinking water your entire life you might not see any reason to start drinking beer either. Water serves it's purpose (makes you unthirsty) so does beer. The taste is different and some other effects. Once tried some people don't like beer, some people stop drinking water, some do both at different occasions.</p>
<p>
There isn't much programs you can't do in C, but that does not make it the best tool for all programming. For example interlocking and logic in great quantities is easier done in ladder than in C.</p>

<p>consider this:</p>
<pre>
a=((b||a)&&c&&d&&e&&f||k&&!f)&&g&&!h&&!i&&!j;
</pre>
<p>and this:</p>
<pre>
! !
! b c d e f g h i j a !
+-< >-+-< >---< >---< >---< >-+-< >---</>---</>---</>-----( )--+
! ! ! !
! a ! ! !
+-< >-+ ! !
! ! !
! k f ! !
+-< >---</>-------------------+ !
! !
</pre>
<p>If I typed it correctly they should both be describing the same thing in C and ladder. You are of course entiteld to think whatever you like is easiest to do but I think most people handling logic in great quantities would prefere the ladder version over the C version.</p>

<p>The above is a real example, but of course with the real tags stripped and - there was a LOT of similar (and a lot of not similar of course) rungs in the program where this was found. I guess looking at some 300+ lines C code like the one above would make it quite hard to quickly find an error somewhere.</p>

<p>If someone used to C should write a program solving the same thing the program where this was found it would most probably not be logic lines
like the one above but rather a lot of</p>
<pre>
if (h||i||j)
{
a=0;
}
else if (g)
{
if (f)
{
if (b)
a=1;
if (!c||!d||!e||!f)
a=0;
}
else
{
a=k;
}
}
else
a=0;
</pre>
<p>and so on. </p>
<p>It would perhaps work, but would probably miss some important cases, or at least would the risk be greater.</p>

<p>Writing it in ladder help you think logic - not that you can't do it in C also, and not that you can't do it in a "bad" way in ladder but if you learn the tool properly it forces you to think in a new way - that is the important point in this thread.</p>

<p>/Johan Bengtsson</p>

<p>Do you need education in the area of automation?<br>
----------------------------------------<br>
P&L, Innovation in training<br>
Box 252, S-281 23 H{ssleholm SWEDEN<br>
Tel: +46 451 49 460, Fax: +46 451 89 833<br>
E-mail: [email protected]<br>
Internet: http://www.pol.se/<br>
----------------------------------------</p>

 

Is there a program that converts C to ladder and the reverse? Is there a program to convert both to flow logic diagrams??

Bob Pawley
250-493-6146

 

Hi Johan

If you think C is tough to follow, you oughta see what your ladder compiler puts out :^) Seriously, you can use C with equal ease if you do the same thing. Use a graphical editor that transliterates to C. Or a ladder to C compiler depending on the situation. Just because it all ends up as machine code doesn't mean you have to code or view it that way. Just didn't want anyone getting the wrong idea.

Regards

cww

 

<p>Hello List, </p>

<p>LM> If you have been drinking water your entire life you might not see any reason to start drinking beer either. Water serves it's purpose (makes you unthirsty) so does beer. The taste is different and some other effects. Once tried some people don't like beer, some people stop drinking water, some do both at different occasions. <LM</p>

<p>LM> There isn't much programs you can't do in C, but that does not make it the best tool for all programming. For example interlocking and logic in great quantities is easier done in ladder than in C.<LM</p>

<p>LM> consider this:</p>

<p>LM> a=((b||a)&&c&&d&&e&&f||k&&!f)&&g&&!h&&!i&&!j;</p>

<p>LM> and this:</p>

<pre>
LM> ! !
LM> ! b c d e f g h i j a !
LM> +-< >-+-< >---< >---< >---< >-+-< >---</>---</>---</>-----( )--+
LM> ! ! ! !
LM> ! a ! ! !
LM> +-< >-+ ! !
LM> ! ! !
LM> ! k f ! !
LM> +-< >---</>-------------------+ !
LM> ! !
</pre>

<p>LM> If I typed it correctly they should both be describing the same thing in C and ladder. You are of course entiteld to think whatever you like
is easiest to do but I think most people handling logic in great quantities would prefere the ladder version over the C version.<LM </p>

<p>Just a couple remarks... one small and one hard for the example you call real:</p>

<p>1. The C syntax is very flexible. So there must be a culture to write in C. See for example <a href="http://www.Micrium.com">www.Micrium.com</a> application note AN-1003.</p>

<p>More or less readable notation _for the choosen identifiers_ could be someting like this:</p>
<PRE>
a = (((b || a) && c && d && e && f)||(k && !f)) && g && !h && !i && !j;</PRE>

<p>or maybe so:</p>
<PRE>
a = g && !h && !i && !j && ((k && !f) || (c && d && e && f && (b || a)));</PRE>

<p>Really I see a vialation of the following rules:<br>
a. Keep the code simple<br>
b. Be explicit<br>
c. Avoid complicated statements</p>

<p>2. The choosen identifiers can be characterised only with the word "ugly". One of the main attributes of the quality programming style is a strict and informative system for the names. (Else any complex program is just impossible </p>

<p>No need to say that the informative identifier systems are incompatible with the LD.</p>

<p>(lets try to rewrite your examples with the identifiers of 20 characters, instead of
toy-names "a, b, c, d, i, f, g" </p>

<p>
LM> The above is a real example, but of course with the real tags stripped and - there was a LOT of similar (and a lot of not similar of course) rungs in the program where this was found. I guess looking at some 300+ lines C code like the one above would make it quite hard to quickly find an error somewhere. </p>

<p>Sorry. I am disagree. The example for C-language is real example only to demonstrate a bad programming style.</p>

<p>Textual languages demand the culture and give the flexibility and the power and provide real readability (if we speak about the complex programs ... </p>

<p>LM> If someone used to C should write a program solving the same thing the program where this was found it would most probably not be logic lines like the one above but rather a lot of
</p>
<pre>
LM> if (h||i||j)
LM> {
LM> a=0;
LM> }
LM> else if (g)
LM> {
LM> if (f)
LM> {
LM> if (b)
LM> a=1;
LM> if (!c||!d||!e||!f)
LM> a=0;
LM> }
LM> else
LM> {
LM> a=k;
LM> }
LM> }
LM> else
LM> a=0;

LM> and so on.
</PRE>

<p>It looks like you are too biassed...</p>

<p>OK, lets rewrite the sentence (with ugly identifiers)</p>

<PRE>
// a = g && !h && !i && !j && ((k && !f) || (c && d && e && f && (b || a)));
// <- kf-> <-ba->
// <------- cb -------------->
// <-------------- kc ----------------------->

ba = b || a;
kf = k && !f;
cb = c && d && e && f && ba;
kc = kf || cb;
a = g && !h && !i && !j && kc;
</PRE>

<p>just 5 lines... comparing to 8-10 lines in the LD example...</p>

<p>Plus (obvious):<BR>
1. you can use informative identifier;<BR>
2. you can use the comments</p>

<p>Plus other advantages... that are not so obvious... like e.g. the opportunity to provide cross-platform compatibility. ;-) heheh... </p>

<p>LM> It would perhaps work, but would probably miss some important cases, or at least would the risk be greater.<LM</p>

<p>LM> Writing it in ladder help you think logic - not that you can't do it in C also, and not that you can't do it in a "bad" way in ladder but if you learn the tool properly it forces you to think in a new way - that is the important point in this thread.<LM</p>

<p>I need no new way of thinking. I need the best way of thinking.</p>

<p>Writing in ladder forces you to think in the relay terms. OK.<br>
The next step would be to show that:<br>
a) the way of thinking covers all tasks of logic
programming, b) the LD is the best way comparing to _all_ other ways.</p>

<p>(and the examples ought to be really real </p>

<p>Best regards,<br>
Vladimir<br> mailto:[email protected]</p>

 

The example IS real, I stripped the names by purpose since I didn't want to reveal them. I do a lot of programming in C/C++ so - no I don't think I am biased at all actually (I don't actually program in ladder very often at all) but that is beside the main point - since the point was that the language affects the way you think. I don't think your rewritten example are easier to read than the ladder (or even as easy to read) completely regardless of the number of lines.

There are no "best" way of thinking about all problems, different problems need different ways of thinking. How different are different for different problems. (Hmm overuse of different I think.....)


What does cross platform compatibility have to do with this? really? That cross platform compatibility is good and C provieds it quite nicely? - well, agreed, but it is beside the point.


What is my point? My point is that if you try to solve a problem in C requitering you to start and stop a number of motors based on some decitions it is easier to start thinking in terms of if something then start that motor and so in, ie to think in what is to happen when rather than pure logic what are the conditions for this motor to be turned on.

I guess I mixed that up in my previous post and it didn't turn out clearly (don't know if it is clear now either)


/Johan Bengtsson

Do you need education in the area of automation?
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

 

Bob Pawley:
> Is there a program that converts C to ladder and the reverse? Is there
> a program to convert both to flow logic diagrams??

Ladder to C is easy (in fact, if you're willing to write mnemonics, you can just grab the mnemonics-to-C translator from the MAT LinuxPLC). http://mat.sf.net/manual/logic/il.html

The other ones, like Rufus said, will be harder.

I guess C to Ladder wouldn't be that hard, but it would produce ugly ladder, and I don't think anyone ever bothered.


Otherwise, you could probably apply data-flow analysis to ladder (ie, work out how the rungs depend on each other) and simplify it to `simpler' ladder, for some definition of simpler.

That might be useful if you're faced with obscure / obfuscated ladder.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

Hello johan,

On Friday, January 25, 2002, 3:52:14 AM, [email protected] wrote:

jbps> The example IS real, I stripped the names by purpose since I didn't jbps> want to reveal them.

Look: I said you, "it is not real example!"
And you agreed - "I stripeed the names" and then again insisted - "The example IS real"...

The real example must be with the real names.

Why?
- Because only semantics of the text gives the right answer on the question "is it readable?". There are no semantics(meanings) in your "a, b, c, d..."

jbps> I do a lot of programming in C/C++ so - no I don't think I am biased
jbps> at all actually (I don't actually program in ladder very often at all)
jbps> but that is beside the main point - since the point was that the
jbps> language affects the way you think.

yes... the language affects the way you think... Agreed. The LD forces you to think in the relay terms.

The question is, is it right approach?... IMO. Ideal language is the language that does _not_ affect the way of thinking...

jbps> I don't think your rewritten example are easier to read than the ladder
jbps> (or even as easy to read) completely regardless of the number of lines.

With the remark about the identifiers - agreed... the example in C is unreadable... as well as the example in the LD...
Why? - Nobody can say, is the example correct or no.

Really the words "rewritten example is easier to read" means "rewritten example can reduce the COMPLEXITY".

I must confess, the number of the "a, b, c, d..." leads me to the toughts that even C may reduce the complexity ... that the "a, b, c, d... etc."
are semantically _heterogeneous_... ;-)

Please, show the semantics.

jbps> There are no "best" way of thinking about all problems, different
jbps> problems need different ways of thinking. How different are
different
jbps> for different problems. (Hmm overuse of different I think.....)


Yes. It is impossible... about all problems... But there is the best way of thinking about a given class of problems... So, the best language (for every given class) must exist.

jbps> What does cross platform compatibility have to do with this? really?
jbps> That cross platform compatibility is good and C provieds it quite
jbps> nicely? - well, agreed, but it is beside the point.

Yes. It is beside the point (concerning the way of thinking), but it is quite close to the demarcation problem. IMO.

jbps> What is my point? My point is that if you try to solve a problem in
C
jbps> requitering you to start and stop a number of motors based on some
jbps> decitions it is easier to start thinking in terms of if something
jbps> then start that motor and so in, ie to think in what is to happen
jbps> when rather than pure logic what are the conditions for this motor
jbps> to be turned on.

IMO. Pure logic for the case is the logic of events. (events with meanings that are not reducable to 0/1, ON/OFF, "a, b, c,d...")

and C permits to fulfil the task much easier than the LD... because of the means of comments, and full-fledged identifiers, and its flexibility (IMO)

jbps> I guess I mixed that up in my previous post and it didn't turn out jbps> clearly (don't know if it is clear now either)

I see you say the tool must be corresponded to the task. Agreed.

And it seems to me you think kinda the adequate way of thinking is to put the result of logical operation in the right part (in the LD)... instead of the left part (in C). (?) Disagreed.

I think, the LD can pretend, it reduces complexity because of the grafic representation of the algorithm only... it has an advantage for some cases. We just ought to formulate it... in order to see the line of demarcation

--
Best regards,
Vladimir mailto:[email protected]

 

Ok, this happened to jump to another topic, so if anyone misses the post I answer that's the reason...


Why could not the example be real without it's names? Ok, It is hard for you to understand it but the real names are not that much easier to read - and no I don't want to reveal them anyway.

I don't think there is any such thing as a language not affecting the way you think, the more experienced you get the less you see this. If logic is not the right way to think about the problem then ladder (or FBD for that matter) is not the right way to solve it. So this goes two ways, the way of thinking about the problem affects choice of language and the choice of language affects the way of thinking. What was first chicken or egg?

The point someone tried to make (and I agree to) is that you would be a better programmer by learning some set of languages with different ways of thinking - just because they have different ways of thinking. As I have said - you can solve most problems quite well in C, but you can solve it in a lot of different ways.

I have seen parts of programs written in C (there was no other choice of language at the particular place) where the programmer would have
done a lot better job by thinking logic (ladder or FBD or whatever your favorite form of logic representation is) rather than think C. The fact
thet you can implement logic in C is quite good but does not help if you don't think logic since you don't realice it is the way of solving it.
(No I won't reveal that code either)

btw, about the left to right vs right to left thing. I could not care
less. It is the graphical representation I think makes LD (and FBD)
easier to read.



/Johan Bengtsson

Do you need education in the area of automation?
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

 

I am one of those electricians that do all the programming required whether big or small. Where do you draw the line at size? If the electrician doesn't understand what he is trouble shooting at 3:00 am will the PROGRAMMER take callouts?

 

Jiri:
> > Certainly one person can do all three jobs, especially in small, simple
> > installations. But where the size and/or complexity of the project
> > warrant it, they should be separate jobs, with quite different
> > qualifications.

Gord Graham:
> I am one of those electricians that do all the programming required
> whether big or small. Where do you draw the line at size? If the
> electrician doesn't understand what he is trouble shooting at 3:00 am
> will the PROGRAMMER take callouts?

I guess the call is for a program technician that'll have a similar relationship to the programmer or software engineer that an electrician has to the electrical engineer.

There's no reason why an electrician couldn't also be a program technician. But it needs to be recognised that it's a separate qualification.


Saying "we can't use modern programming techniques because we hired the wrong kind of technician" is just silly.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools