Function Library

C

Curt Wuollet

Hi all

In case it got lost in the stream, I am looking for the essential, common, set of functions a PLC is expected to have. I don't want at this point, to emulate any particular machine or vendor, simply to provide useful functionality.

If you folks could work out a list, I'll see what it would take to put functions in a library. One list please. That will save your time and mine. I will be out of touch with email today but expect to be back tomorrow. Let's stick with
the basics for now and figure out "advanced" functions later.

Regards

Curt W.

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

J

Jiri Baum

Curt Wuollet:

> In case it got lost in the stream, I am looking for the essential.
> common, set of functions a PLC is expected to have. I don't want at this
> point, to emulate any particular machine or vendor, simply to provide
> useful functionality.

The following functions should probably be supplied as normal stepladder instructions:

Basic algebra: add, subtract, multiply, divide.

Inverses: bitwise invert, negative, reciprocal.

Trigonometric functions: sin, cos, tan, asin, acos, atan, sinh, cosh, tanh, asinh, acosh, atanh. (Well, really, once we have `reciprocal' in there these are just library calls so we might as well put them in.)

Misc. maths: sqrt, cbrt, nth root, pow/exp, log/ln, round, ceil, floor, frac, hypot, absolute value, modulus.

Comparison: >, <, >=, <=, ==, <>, absolute difference

Conversions: BCD, gray, 7-segment, ascii

Generic table lookup with interpolation (eg thermocouple linearization).

Stack-like operations: duplicate current rung, duplicate nth previous rung, discard current rung, swap current and previous rungs, swap current and nth previous rungs. (These will probably make more sense with examples...)

Now you see why I need to re-design the IL parser

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

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

S

C

Curt Wuollet

Jiri Baum wrote:

> The following functions should probably be supplied as normal stepladder
> instructions:
>
> Basic algebra: add, subtract, multiply, divide.
>
> Inverses: bitwise invert, negative, reciprocal.
>
> Trigonometric functions: sin, cos, tan, asin, acos, atan, sinh, cosh, tanh,
> asinh, acosh, atanh. (Well, really, once we have `reciprocal' in there
> these are just library calls so we might as well put them in.)
>
> Misc. maths: sqrt, cbrt, nth root, pow/exp, log/ln, round, ceil, floor,
> frac, hypot, absolute value, modulus.
>
> Comparison: >, <, >=, <=, ==, <>, absolute difference
>
> Conversions: BCD, gray, 7-segment, ascii
>
> Generic table lookup with interpolation (eg thermocouple linearization).
>
> Stack-like operations: duplicate current rung, duplicate nth previous rung,
> discard current rung, swap current and previous rungs, swap current and nth
> previous rungs. (These will probably make more sense with examples...)

yep.

> Now you see why I need to re-design the IL parser

Yeah, most of what you mentioned implies real numbers, if nothing else. I was thinking digital functions at the moment, but we are blessed with an extensive and well-proven math library and floating point acceleration and we certainly should capitalize on it. These functions can be light wrappers and won't take much space, many could be direct calls into the math lib with a little juggling.

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

C

Curt Wuollet

Hi Scott

I don't have IEC-61131-3 and am unlikely to buy it for our free project. I would prefer the opinion of working automation folks to the IEC anyway. I have seen bits and pieces and it seems written to please rather than to inform. This may
be heresy, but I believe we can do this without consortia. I'm sorry, I don't mean to be rude, but a list is more helpful. I'm sure everything we do will be in that document somewhere. I hopefully won't be writing the languages as I am not an expert. I'm willing to write what others suggest would be useful. These functions will be called by whatever language is used. My alternative is to pick a popular PLC and copy what it does. This is far too political as
everyone has a favorite. I'd rather include the stuff common to all and then the best of the rest.

Ragards

cww

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

J

Jiri Baum

Jiri Baum:
> > The following functions should probably be supplied as normal

[...]

Jiri
> > Now you see why I need to re-design the IL parser

Curt Wuollet:
> Yeah, most of what you mentioned implies real numbers, if nothing else.

Yup, and in combination with integers that means typed stepladder.

What we might call "data cables" for the electricians.

; R3 = R1 * R2
LD R1
MUL R2
OUT R3

; a + b
; e = -------
; c + d
LD A
LD C
DIVB
OUT E

; a + b
; e = -------
; c + d
; (structured style)
LD A
DIV (
LD C
)
OUT E

> I was thinking digital functions at the moment,

There's not all that many of them that I can think of...

Gray code and maybe BCD are about the only ones that'll be more calculation than wrapper, and even then it's doubtful.

Of the others, only the thermocouple linearization sounds interesting, and even that will be more reading manuf. data sheets than any excessive code.

> but we are blessed with an extensive and well-proven math library and
> floating point acceleration and we certainly should capatalize on it.
> These functions can be light wrappers and won't take much space, many
> could be direct calls into the math lib with a little juggling.

Exactly.

In fact, I'll probably end up sticking them in separate files (trig.fn, math.fn and so on) and lightly massaging them with Perl before compilation.

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

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

C

Curt Wuollet

We should probably delineate what will be done on the fly and what be a library function. I was thinking that the library should do type conversion, ordering, and that sort of putziness so the translator need only build the call. This isn't important now, but as we get more translators, it might be a good thing if we keep as much of the detail as possible in the library.
Another way of saying this is that the library interface should handle the native PLC types, allowing pass by value to local variables and doing the assignments in the translator output code. This eliminates having the library doing hidden magic on variables outside its scope. It also fixes the inputs at the call and the outputs on completion, which could be important if we're free running.and for debugging. Sorta like fencing in all the pointers. I haven't thought this all completely through, but it just seems right.

What do you think?

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

S

Scott Cornwall

Curt,
I sense you have a similar distaste for standards as I. They are however useful to learn from, implementing them is a completely different issue. To ignore what is possibly one of the most significant artifacts of the automation industry would be just plain stupid. The standard does provide a certain amount of information about what is expected from a system such as what the Linux PLC will have to be if it is going to
obtain acceptance. The standard is not only about languages, a major section of it is the "common elements". My instant reaction to the list Jiri put together was that this list has
been produced by a software developer. No offence intended as it is natural to be influenced by the kind of functionality you are used to in a software development environment. Although most of the list from Jiri is in 1131, there are several items that control systems programmers would consider more important than a long list
of floating point maths functions, like bit shifting, timers, counters, etc. It would be useful if a few people with domain experience commented on the basic functions they would need for the LinuxPLC to be of use.

Also you do not need to buy the standard, an html version is at (I'm sure this has been mentioned before) :
ftp://ftp.cle.ab.com/stds/iec/sc65bwg7tf3/html/toc.htm

Regards,
Scott

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

C

Curt Wuollet

Scott Cornwall wrote:

> Curt,
> I sense you have a similar distaste for standards as I.

I have great appreciation for standards that serve the user, are open and are apolitical . I have much less appreciation for vendor driven, political standards that mostly serve the needs of consortia members. So far they haven't done a very good job of selling this one on it's merit. It _does_ formalize some very loose practices and will discourage proprietary extensions and so has value.

> They are however useful to learn from, implementing them is a completely
> different issue. To ignore what is possibly one of the most significant
> artifacts of the automation industry would be just plain stupid.

I've been accused of being stupid before, I'm fairly secure though. I didn't say we would ignore it, it is unlikely anyone will ever completely implement it. It is so broad that virtually anything we do would be in it. anyway. Standardization is a good thing, Quasi-standards that include the kitchen sink and everyone's favorite don't do as much to standardize
things as they might. The new fieldbus "standard" is an even worse example. If email could use any of a dozen "standards", how well would this list work? I simply think standardization should mean fewer entities rather than more. Curt's first rule of standardization: If everyone got what they wanted, you've failed.

> The standard does provide a certain amount of
> information about what is expected from a
> system such as what the Linux PLC will have to be if it is going to
> obtain acceptance. The standard is not only about languages, a major section
> of it is the "common elements".

I'm mostly interested in the subset that people actually need.

> My instant reaction to the list Jiri put together was that this list has
> been produced by a software developer. No offence intended as it is natural
> to be influenced by the kind of functionality you are used to in a software
> development environment.

Fair enough, but we're asking for expert input.

> Although most of the list from Jiri is in 1131, there are several items that
> control systems programmers would consider more important than a long list
> of floating point maths functions, like bit shifting, timers, counters, etc.
> It would be useful if a few people with domain experience commented on the
> basic functions they would need for the LinuxPLC to be of use.

Exactly, that's what I'm fishing for.

> Also you do not need to buy the standard, an html version is at (I'm sure
> this has been mentioned before) :
> ftp://ftp.cle.ab.com/stds/iec/sc65bwg7tf3/html/toc.htm

I happily stand corrected, now if I could get the "Open" devicenet and profibus standards free, I might give consortia more slack.

One thing you have to understand, Scott, is that I'm not convinced that we aren't in the position of setting standards. A lot of the existing standards are incompatible with our goal of community owned, truly open, free, control
systems based on open standards. They are owned by someone, and while we must interoperate with them, they, by definition, can not be part of the
project as they are not open and are legally encumbered. I'll bet, for example that claiming that you are IEC-61131 compatible involves paying through the nose for compliance certification and testing. What use is a standard like that to us? I don't mean to pick on you, this is something that I've been thinking a lot about lately. Peace.

cww

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

J

Jiri Baum

Scott Cornwall:
> My instant reaction to the list Jiri put together was that this list has
> been produced by a software developer.

It was

> Although most of the list from Jiri is in 1131, there are several items
> that control systems programmers would consider more important than a
> long list of floating point maths functions,

Well, the long list of floating point maths functions has the virtue that, once we've implemented about three of them, the rest are basically free.

> like bit shifting,

Yup. I forget that not everything can be done with multiplication... Still, like the ones above - once we have addition and subtraction, bit
shifting will be just one more line in the Big Table of Instructions.

The select operation (from INTERCAL) might be interesting, and perhaps a
"reverse bits" one.

> timers, counters, etc.

Timers and counters were actually a conscious omission - I should have probably listed them separatly instead... They'll need a bit of thought to implement well (so that they fit into the shared memory map model).

Timers will probably best be stored as "starting time", with the IL executor making note of wall time at the start of the scan, then the TIMER
instruction will just compare the difference between the two with the given value.

So:
LD T01 ; timer T01
TIMER 5 ; is it five seconds yet?
OUT Q05

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

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

R

Ralph G. McDonald

I have not had a chance to look at list since last Thursday so I may be a little late replying to your request.

Basic ( minimum ) functions required for a functioning PLC:

The old original 5TI had the following and it was possible to do real work with it.

Digital Functions:

Start Rung
Start Branch
End Branch
Examine On
Examine Off
Output - Assumes single output per rung and all rungs end with an output.

Timer
Counter

I would add the following if possible:
Latch Output
Unlatch Output

For analog math and word functions:

Copy - ( or Load, or Get and Put) some method of moving data words between analog inputs, storage registers, analog outputs.

Minimum Math Functions:
Subtract
Multiply
Divide
Square Root

Math Functions should return or set error flags as well as results

Minimum Bitwise Operators
AND
OR
XOR
SHIFT

Nice to have, but not absolutely required in first draft:
Floating Point Math: - You can do a lot with scaled integer if you have to.
Trig Functions:
Exp Functions:
Conversion Functions: to/from binary/BCD/ASCII
Program Control Functions: Subroutine, Return, Master Control Relay, etc.

I hope this is the type of list you want, with the minimum functions listed I can program for most water/wastewater systems, bulk conveyors, etc. It may not be as easy as with more advanced functions but it can be done.

Ralph

S

Scott Cornwall

> Timers will probably best be stored as "starting time", with the IL
> executor making note of wall time at the start of the scan,
> then the TIMER
> instruction will just compare the difference between the two
> with the given
> value.
>
> So:
> LD T01 ; timer T01
> TIMER 5 ; is it five seconds yet?
> OUT Q05

OK, but what ever is monitoring the system (on same Linux box or remote) will want to see the current value of the timer in some form. If only the starting time is being saved then some calculation needs to be invoked to determine the current value. When monitoring remotely then the comms protocol will have to invoke this calculation, which may place some limitation on the choice of protocol for this sort of communication.

Scott

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

D

DigiMicro (Gilles Allard)

>Timers will probably best be stored as "starting time", with the IL
>executor making note of wall time at the start of the scan, then the TIMER
>instruction will just compare the difference between the two with the given
>value.
>
>So:
> LD T01 ; timer T01
> TIMER 5 ; is it five seconds yet?
> OUT Q05

If you implement timers that way, you won't be enable to support a "enable" input in your timer instructions. Some PLC (for example, the Simatic TI) provide a timer instruction with two inputs: enable and reset.

To provide this feature, a timer can be a time accumulator (unsigned long). At every scan, a timer (if enabled) would be incremented by the duration of the last scan.
To summarize:
Inputs: reset, enable (we may also call it freeze), duration required (in msec)
Output: timeout
Logic:
- a reset would clear the accumulator
- at the beginning of every scan, a timer (if enabled) would be incremented by the duration of the last scan.
- the output of a timer will be true if the accumulated time is >= the required duration.

My .02 cents
Gilles
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

J

Jose Fernandez

I've got some documents in MS Word about IEC 1131-3, 4, 5 and 7, and other users guides for IEC 1131-3, which I have found within Internet, those
documents are public draft electronic copies of the IEC task which is working in IEC 1131 suite of standards, If you wish I could send those to
you to have a look on them.
There is a site with URL: http.//www.plcopen.com (or .org) that has (or had) a html version of the IEC 1131-3, I recommend to visit that site.

Regards

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