Since I came to PLC programming from a general CS background, I spend most of my time programming in ST. I have a wishlist for the coming year for the guys at the IEC. Dunno if I will actually get anything I wish for, but no harm in just hoping right?

Still, I'll try to be realistic, given that things still have to execute quickly and PLC programmers shouldn't have to worry about memory leaks, multiple inheritance, and other such thorny issues. So, the list:

1) More powerful string processing. I want printf-style interpolation and escape sequences, and simpler, easier ways to access substrings and concatenate them. I also want to increase the size limit to more than 255 characters.

2) First-class functions. Anonymous functions and function pointers would be awesome.

3) Real object-oriented programming. At minimum, I want inheritance, and class and instance methods.

What do you guys think?

Maybe the ability to "shadow" inherited members. The parent function block can define abyData AS ARRAY[1..10] OF BYTE, but the derived one should be able to redefine this as ARRAY[1..100] OF BYTE. Also the ability to redefine initial values, constants in the derived class.

Optional parameters for functions, or variable number of arguments

More clever conditional compilation (I think this is just CoDeSys related)

MusashiAharon hat geschrieben:
3) Real object-oriented programming. At minimum, I want inheritance, and class and instance methods.

In CoDeSys V3.x you already have methods, properties, inheritance and also access modifier.

i do not agree,
the 61131 should not be changed, it is a standard and when you always change the standard it is not standard anymore,
better to have 61132 for this.

Can you tell us more about this 61132?
???

Strucc hat geschrieben:
Can you tell us more about this 61132?
???

It's just a hypothetical new standard. If we were to make a new 61131 standard, it would have the next sequential number - 61132.

Another thing I'd like is a bunch of dynamic data structures in the standard library. Things like doubly-linked linked lists, hashtables, sets, dictionaries, and resizable arrays and strings. Plus, I'd like a FOREACH construct to work with them. Maybe even FOREACH ... WHERE. Of course, the data structures would be implemented as objects.

In Codesys V2.3, I'm not allowed to make recursive data structures, even if it's just a pointer to the same data type. Right now, I have to get around this by storing the pointers as DWORDs and casting them later, but I'd rather just have it declared as what it really is. I want to allow pointers to a data type within the same data type.

Also, can I have ++, --, +=, -=, etc. like in C? It would be nice if + and += worked on strings, too...

and we are still talking about ladder diagram with double linked lists and recursive data structures.

i have a car with four wheels, and i wish it can fly.
just kidding but keep the structure simple as 61131 is big enough to do most jobs in a standard PLC.
which still is controlling a machine.

shooter hat geschrieben:
and we are still talking about ladder diagram with double linked lists and recursive data structures.
i have a car with four wheels, and i wish it can fly.
just kidding but keep the structure simple as 61131 is big enough to do most jobs in a standard PLC.
which still is controlling a machine.

I really don't think this is too hard. I've actually implemented doubly-linked lists myself (although I had to use the workaround I mentioned earlier). Although people using ladder logic might not have heard of lists and their power, they probably have heard of a FIFO queue or a LIFO stack. Both of these are highly useful, and they are implemented as lists. I can totally see using lists, at least indirectly, even in ladder logic.

Ok, we get it this isn't for you. But if you want all of the OOP then look at Beckhoff. In their new version of twincat V3 they integrated it into Visual Studio. Now the world of PLC programming has met the world of CS. Check it out.

Originally created by: Bernhard Werner

Every standard gets maintenance from time to time and is revised. And so is the 61131-3. There will be a new edition (edition 3) of the standard, release date
is scheduled to February, 2013.
We (3S) took part in the development of the new standard. A major new topic of this new standard is object orientation. The standard will contain classes, methods, inheritance, interfaces, abstract classes etc. CODESYS V3 object orientation is already compliant to that new standard.
So you just have to wait some more weeks and a lot of your wishes will be fulfilled.
But of course, releasing a new standard, doesn't mean that there will also be a range of products. I don't think that you will soon find 3rd-edition compliant products other than codesys.

Bernhard Werner

Originally created by: Bernhard Werner

I gave a (german only) presentation about the new features of the 61131-3 3rd edition at the Sommerkolloquium in Aachen last year,
which you can find here:

http://www.plt.rwth-aachen.de/fileadmin/plt/events/2012/Sommerkolloquium/Werner-61131-3.pdf

Thanks for the presentation, it replied most of the issues mentioned earlier.

Would be great to hear about 3S plans / schedule to implement the missing elements (like variable number of parameters, optional parameters, "dynamic" arrays).

I'm also looking for a proper way to use / implement things like collections in C#.
This problem comes, when a function block instance has to be defined with variable number of arguments...

For example :

FUNCTION_BLOCK ROOM 
VAR_INPUT
   Lights : ARRAY[*] OF LIGHT_INFO;
END_VAR

```...

ROOM1 : ROOM := (
   Lights :=
      (Name := 'Main', Device := ADR(_R1_L1)),
      (Name := 'Ambient', Device := ADR(_R2_L2))

);

Then...

FOREACH MyLight IN THIS^.Lights
   MyLight.TurnOn();
END_FOREACH

```
(Or could be the way as in the standard proposal, (lbound, ubound));

Also, not included in the standard, the pragmas could be a bit more elaborated. Currently there is no way to define something in the application, and compile the project for that specific application based on the definition. Conditional defines doesn't seems to work in the project tree.

Originally created by: Bernhard Werner

at the moment, I can't give you a date for the missing features.
But you can be sure, that we will eventually implement all of these features.

You should not mix up CODESYS and the standard. Pragmas for example are only mentioned in the standard,
that they do exist, and any semantics of pragmas are implementation dependant.
In fact, you can set a define in the "Compiler defines" of the Build options of an application, and use it in your code
like this

{IF defined('something')}
// do this
{ELSE}
// do that
{END_IF}

but you can't use that define in the interface, and you can't use it in the project tree.
Concerning Collections: have you checked the CAA_ListAndTree.library?
Generics as in C# would be a great thing, but not for the near future.
Be sure, we will continue to implement new functionality, we currently released the static analysis,
and we are working on UML-integration. We are planning a profiling option...

Bernhard Werner

Thanks for the reply.

Regarding conditional compilation / defines:
I don't see a (n external) reason, that it shouldn't work in the project tree. (I know, it's documented)
Example:
A library implements complex automation tasks. Debugging and logging features are useful, but in a real application they are resource consuming. Would be nice, to be able to build a debugging version of the project, and after the development simply turn that flag off. Similar with simulation options: For example, code is added to the FB to allow process simulation ... a PID controller in simulation mode should use the simulation time rate for example... But, this code should be excluded from the production application. Also... On multi-platform projects, one might imagine a library with slightly different implementations... But still relying on a common code basis.

Regarding CAA_ListAndTree - The documentation /example was missing, I was playing with that, but ended up to implement something similar. However, in the future I'd be very happy to avoid that, I think the value of my code depends on it's well focused functionality. In this case, I think it's also important to see the implementation background (how much memory does a list entry take, what resources are used, etc...).

Also... As a library developer, I'd be very happy to see more recommendations (I know the old CAA material, and the new document released with SP2).
More exactly: what libraries to rely on in the future? (Yes, in general use CAA, try to avoid SysLib) For example in V2, I did a dynamic memory "wrapper" library, as SysLibMem was not available on some platforms. So, I ended up by writing a similar library relying on a simple static byte array, pointers, etc. Would be nice to know, and clearly understand, what is the minimal set of libraries one can build a library on.

In general: we all know that * everything * can be done, even with CoDeSys V2. There are some really nasty tricks, one can even enjoy them ... But what we are aiming, is the "art of programming" - to be able to write compact, easy to understand, reusable code. I'm really happy to see recent CoDeSys developments, not only concerning the language, but replying business needs, like javascript based web visu.

I'd be glad to discuss these in detail, and within the framework of our current project we are on the way to establish this kind of communication with 3S. Please drop me a mail to pop (at) eik dot bme dot hu.

(I didn't find a way to write personal messages here)

I agree. One thing from a development standpoint is how would we know to look in a library named CAA_ListAndTree? That is one issue. Finding things that can be useful without wasting days figuring it out. All the 3s examples are so basic they need deeper level examples for us to learn from. But again 3s I think expects the OEM who implemented CoDeSys onto their target to support you, which by the time the support gets to the end user of that product (myself) no-one can answer any questions. I had the exact issue come up as Strucc mentioned just last month. I tried to use Pragmas but it didn't seem to work well. I too wanted test code or unit testing to do position control. I wrote my test FB that when commanded acts like a VFD drive that responds to velocity and encoder feedback. But I have to add all that code into the project. At least I could not find a solution that was elegant. I was hoping for at least setting a global variable to turn on/off testing. What's hard is if you are already using software from a 3rd party and they are not using at least interfaces from V3 then I'm not sure at compile time I can change one FB for another like

If define (DEBUG = 1) then
FB := TEST_FB;
else
FB := Third_Party_FB;
end_If

Especially into FBD since you have to enter a FB instance on the screen before compile time.

I really do need to write a book in ENGLISH on CoDeSys since there is nothing out there.

spfeif: No you don't have to... 'cause it's going to be me who write that book
(ok, if you have the title and the publisher, I'm happy to contribute the rest of it )

Anyway... Beside researching the next generation of controllers and programming languages, we should spend more time, to disperse this knowledge. And in fact, for us, involved in the "academic" sphere, it's a challenge as well...

spfeif: did you learn from books? The last book I bought in my practice was the one with the camel at the cover. Yes, I like perl. And camels. That time it was a value. And I feel the same, there is a strong vacuum for explaining the practical application of the educated programming skills. But a book is not really an answer... today... We should start a wiki page, or... something compatible with g***gle. It's a strange - and a bit sad - but still something to learn to live with.... Tomorrow's programmers are not going to be IT professionals... just today's children, with a slightly different approach... and instincts...

This is a bit off-topic. (just as the effect behind the birth of CoDeSys: at a point people just suddenly realized, that PLCs are a kind of computers... and why not to use them as computers? The language seems to go trough the already known (r)evolution. WTF??!!! PLCs parsing XML??? Why not? Then... we need the right instruments to do this...)

One good place to start is a manual for best practices for IEC61131 for coding conventions like naming conventions,Layout conventions, Commenting (V23 doesn't support // as apposed to ( )) , language guidelines. This would almost boil over into some guidlines for naming conventions for automation like the use of En (Enable), Permit vs Interlock etc.. You understand, you get my drift. This way you can almost aid in some self documentation just by looking at the input / outputs of a FB. Do I hold this input TRUE all the time or only on rising edge? These questions can almost be answered at the FB interface. Anyway I would love to follow some standard that helps EVERYONE make it a bit more clear. I maybe crazy but just a thought.

I like to participate when writing a book on 61131-3
special when it is done on codesys.

shooter your in. Now we just need a starting point.

Any news about this?

Hmm seems I don't get emails anymore from the forum when their are new posts. Need to check settings.

Strucc you mean a book? Although I am serious I guess I need a kick in the but to get moving? Are you saying you are still interested?

If so you can contact myself via email and we can see were it goes?

Sry,I can't see your email address,
Mine is pop at eik dot bme dot hu...