Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » Modules and plug-ins(Design information about modularity)
Modules and plug-ins [message #1759311] Mon, 10 April 2017 13:07 Go to next message
Adrian Orive is currently offline Adrian OriveFriend
Messages: 38
Registered: March 2017
Member
Until version 1.8.x, only compile-time modules where available that allowed the inclussion of additional FBs and Communication layers. In version 1.9, a LUA interpreter is being implemented to allow non-compile-time plug-ins in order to be able to introduce new FBs without needing to recompile the whole runtime.

  1. Is there any documentation about this modularity?
  2. Does a discussion about the modular dessign concepts exist?
  3. Is there any intention in adding non-compile-time communication layer plug-ins?

[Updated on: Mon, 10 April 2017 13:10]

Report message to a moderator

Re: Modules and plug-ins [message #1759346 is a reply to message #1759311] Mon, 10 April 2017 17:16 Go to previous messageGo to next message
Alois Zoitl is currently offline Alois ZoitlFriend
Messages: 615
Registered: January 2014
Senior Member
First of all the compile-time FBs will not go away. This whole idea about being able to add new FBs to a compiled FORTE without the need for recompiling a new FORTE is driving us since the original developments of FORTE long before it got open sourced. In 2005 I supervised a master thesis by Domenico Rubini at Vienna University of Technology where such concepts have been evaluated. At that time we considered developing our own VM based approach. This was very hard to maintain therefore it never made it in the open source version. But the general design of FORTE was always to accommodate modularity on FB level. This is also a key design element for the C++ based FBs. Later on guys at Profactor experimented with Lua as potential implementation language and execution environment for FBs in 4diac. Michael Hofmann and Gerhard Ebenhofer have published some papers at ETFA conferences and there are also presentations at 4diac users' workshops. This work has been taken up by colleagues of mine at fortiss and currently we are expanding this concept and experimenting with first prototypes. Unfortunately there is appart from the above mentioned not really any documentation available. Currently it is also not in a state that it is usable by the general 4diac user. We hope to have more ready by the next milestones (probably 1.9.0-M3).

For now the work is focused on providing an environment dedicated for FBs. That also means that we are restricting the Lua environment only to these needs. Lua generation and deployment will be integrated in the download functionality and therefore mainly invisible to the normal 4diac user. The main advantage is that users don't need to install compilers but can work with pre-compiled FORTEs.

Sofar we haven't thought about other use of Lua then FBs. And as we still see quite some work on our main use-case we'll focus on that. Also to learn and gain experience on how to use Lua. From that on further usage of Lua could be interesting.

Re: Modules and plug-ins [message #1759373 is a reply to message #1759346] Tue, 11 April 2017 06:32 Go to previous message
Adrian Orive is currently offline Adrian OriveFriend
Messages: 38
Registered: March 2017
Member
My questions were vague on purpose to obtain a bit of information, your post was very clarifying.

Alois Zoitl wrote on Mon, 10 April 2017 17:16
First of all the compile-time FBs will not go away. This whole idea about being able to add new FBs to a compiled FORTE without the need for recompiling a new FORTE is driving us since the original developments of FORTE long before it got open sourced. In 2005 I supervised a master thesis by Domenico Rubini at Vienna University of Technology where such concepts have been evaluated. At that time we considered developing our own VM based approach. This was very hard to maintain therefore it never made it in the open source version. But the general design of FORTE was always to accommodate modularity on FB level. This is also a key design element for the C++ based FBs.


My thoughts were not involving VMs or removing C++ FBs. I was thinking about the possibility of compiling the runtime first, and then compile FBs or communication layers afterwards without the need of recompiling the whole runtime. This would also allow to select at a finer granularity which FBs are needed in each runtime, which would allow more constrained devices to save disk space. Obviously, in such a design a subset of the FBs could be compiled with the runtime too if they are considered to be "required". In conclussion, I was not thinking on removing modularity at compile time but adding modularity at any time. And by modularity I mean C/C++ compiled FBs, not interpreted ones (which is also a interesting but different feature) such as those in LUA.

Alois Zoitl wrote on Mon, 10 April 2017 17:16
Later on guys at Profactor experimented with Lua as potential implementation language and execution environment for FBs in 4diac. Michael Hofmann and Gerhard Ebenhofer have published some papers at ETFA conferences and there are also presentations at 4diac users' workshops. This work has been taken up by colleagues of mine at fortiss and currently we are expanding this concept and experimenting with first prototypes. Unfortunately there is appart from the above mentioned not really any documentation available. Currently it is also not in a state that it is usable by the general 4diac user. We hope to have more ready by the next milestones (probably 1.9.0-M3).

For now the work is focused on providing an environment dedicated for FBs. That also means that we are restricting the Lua environment only to these needs. Lua generation and deployment will be integrated in the download functionality and therefore mainly invisible to the normal 4diac user. The main advantage is that users don't need to install compilers but can work with pre-compiled FORTEs.

Sofar we haven't thought about other use of Lua then FBs. And as we still see quite some work on our main use-case we'll focus on that. Also to learn and gain experience on how to use Lua. From that on further usage of Lua could be interesting.


I understand the LUA interpreter gets compiled when the runtime is, and that what you said about "generation and deployment" is about LUA scripts. Also, what does "generation" mean here, are you talking about auto-generated code or does the application developer need to program it? Will there be some kind of LUA FBs library such as the C++ FBs library there is now or is it just intended for people with scripting knowledge?

[Updated on: Tue, 11 April 2017 06:34]

Report message to a moderator

Re: Modules and plug-ins [message #1759384 is a reply to message #1759373] Mon, 10 April 2017 23:32 Go to previous message
Alois Zoitl is currently offline Alois ZoitlFriend
Messages: 615
Registered: January 2014
Senior Member
Adrian Orive wrote on Tue, 11 April 2017 06:32

My thoughts were not involving VMs or removing C++ FBs. I was thinking about the possibility of compiling the runtime first, and then compile FBs or communication layers afterwards without the need of recompiling the whole runtime. This would also allow to select at a finer granularity which FBs are needed in each runtime, which would allow more constrained devices to save disk space. Obviously, in such a design a subset of the FBs could be compiled with the runtime too if they are considered to be "required". In conclussion, I was not thinking on removing modularity at compile time but adding modularity at any time. And by modularity I mean C/C++ compiled FBs, not interpreted ones (which is also a interesting but different feature) such as those in LUA.

The problem with C++ compiled code is that it is results in native code dedicated for one specific platform. In order to generate it you need the toolchain for this platform. 4diac supports an ever increasing set of hardware devices each requiring partly incompatibly toolchains. Furhtermore you need some mechanism to dynamicaly load or link the compiled FBs. We already have I think 6 operating systems and we are working on some more. Not all have this feature and also it would be hard to maintain.

An interpreted or just-in-time compiled Language like Lua or Java has the advantage that you have one code for all platforms. This comes with some cost but our first experiments are very promising.

Adrian Orive wrote on Tue, 11 April 2017 06:32

I understand the LUA interpreter gets compiled when the runtime is, and that what you said about "generation and deployment" is about LUA scripts. Also, what does "generation" mean here, are you talking about auto-generated code or does the application developer need to program it? Will there be some kind of LUA FBs library such as the C++ FBs library there is now or is it just intended for people with scripting knowledge?


With generation I meant that in the same way as you can currently generate C++ code for your FBs Lua code will be generated. We want to go even a step further: A normal user will not see the Lua code at all. As the Lua code will be generated automatically and then sent to device via our deployment interface when you hit the download button. Therefore ther will not be a library of Lua FBs but only a library of FBs stored in the IEC 61499-2 XML format.


Previous Topic:Memory Leak Test
Next Topic:Server sessions
Goto Forum:
  


Current Time: Tue Aug 14 19:34:25 GMT 2018

Powered by FUDForum. Page generated in 0.01808 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top