Eclipse Community Forums: 4DIAC - Framework for Distributed Industrial Automation and Control » declaration of subroutines/functions currently not possible in ST algorithms?

Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » declaration of subroutines/functions currently not possible in ST algorithms?

Show: Today's Messages :: Show Polls :: Message Navigator

declaration of subroutines/functions currently not possible in ST algorithms? [message #1761169]

Mon, 08 May 2017 14:07

Marc Jakobi

Messages: 67
Registered: April 2017

Member

Hi.

I am attempting to create some BFBs using ST algorithms.
From the literature I found on ST, it should be possible to declare subroutines (see code snipped below). However, the IDE gives me the message, no viable alternative at input 'FUNCTION'.
Is it currently not possible to declare subroutines in BFBs? If not, is there a workaround?

Is it possible to call an algorithm from within another algorithm? If so, a workaround could be to declare internal variables of the function block that are designated as the subroutine-algorithm's inputs and outputs.

FUNCTION REAL_TO_CEILEDINT: INT
	VAR_INPUT
		X : REAL;
	END_VAR
	VAR
		tmp : REAL;
	END_VAR
	tmp := REAL_TO_INT(X);
	IF tmp < X THEN
		REAL_TO_CEILEDINT := tmp + 1;
	ELSE
		REAL_TO_CEILEDINT := tmp;
	END_IF
END_FUNCTION

Report message to a moderator

Re: declaration of subroutines/functions currently not possible in ST algorithms? [message #1761171 is a reply to message #1761169]

Mon, 08 May 2017 14:18

Monika Wenger

Messages: 18
Registered: September 2015

Junior Member

there are some parts where the IEC 61499 Standard Points to the IEC 61131 Standard. this is especially valid for ST. Since the model of IEC 61499 is different than those of IEC 61131 it is not always possible to just take all references comming from IEC 61131 as they have been made. I think the links to IEC 61131 are not always well thought out. Therefore there are some Points where 4diac only Supports a subset of ST, as functions, this Array stuff you already figured out or structs.

Report message to a moderator

Re: declaration of subroutines/functions currently not possible in ST algorithms? [message #1761174 is a reply to message #1761171]

Mon, 08 May 2017 14:43

Marc Jakobi

Messages: 67
Registered: April 2017

Member

Thanks for the quick reply. It seems like calling algorithms from within algorithms is not possible, either. I guess I'll try to follow the tedious path without subroutines then Sad

Report message to a moderator

Re: declaration of subroutines/functions currently not possible in ST algorithms? [message #1761181 is a reply to message #1761174]

Mon, 08 May 2017 15:31

Monika Wenger

Messages: 18
Registered: September 2015

Junior Member

IEC 61499 Standard does not provide Support for calling algorithms within algorithms, so currently there is no possibility to fake subroutines, sorry for this. but basically algorithms are not supposed to be complex Code. usually they should be short and simple, but this depends on what you actually want to program.

[Updated on: Mon, 08 May 2017 15:33]

Report message to a moderator

Re: declaration of subroutines/functions currently not possible in ST algorithms? [message #1761203 is a reply to message #1761181]

Mon, 08 May 2017 21:08

Alois Zoitl

Messages: 1584
Registered: January 2014

Senior Member

I wanted to add to Monika's comment that we know about this limitation and there is also some discusion going on in the standardization working group to add such featuers to future versions of IEC 61499. By asking such questions we get from you the feedback that this is a feature that not only we see but that it is really needed by our users.

Also there is a kind of workaround which you could consider if you want to have a library of IEC 61131-3 functions. We have this for example for all IEC 61131-3 standard functions (e.g., SIN, MAX, MIN). There we have a C++ header file with all the function signatures. This functions can then be used in your ST algorithms like ST functions. So what you could to is develop a C++ header file with your functions (in c++) and add this header file to your FBs. In the property sheet of your fb there is a field header. There you can insert "#inlcude <yourfile.h>" and this will be added to your exported FB.

Although it is a little bit clumsy I hope this helps. Do you think we should improve our support of IEC 61131-3 function libraries?

Report message to a moderator

Re: declaration of subroutines/functions currently not possible in ST algorithms? [message #1761245 is a reply to message #1761181]

Tue, 09 May 2017 11:03

Marc Jakobi

Messages: 67
Registered: April 2017

Member

@Monika Yes, what I am trying to implement is more closely related to optimization than simple automation and is a little complex (so far, I have only implemented it in Matlab and Java and am modelling the FBs based on my Java classes), but I think it will be possible. It may turn out to be a better idea for me to break it up into smaller BFBs and combine them to a CFB.

@Alois I am glad to provide feedback Smile

. Your workaround sounds like a good solution. But I presume it would have the same portability problems as writing the algorithms in C++ entirely?
About the improved support: I don't know the IEC 61131-3 function libraries very well, since I only did a little research on both standards about a month ago and quickly decided to focus on IEC 61499 for my project. But anything that promotes code-reuse is good in my opinion, as long as the overhead doesn't become a problem.

Report message to a moderator

Re: declaration of subroutines/functions currently not possible in ST algorithms? [message #1761340 is a reply to message #1761245]

Tue, 09 May 2017 20:04

Alois Zoitl

Messages: 1584
Registered: January 2014

Senior Member

You are right. When writing a function libraries in C++ you get the same portability problems. Therefore I think it makes mostly sense when you have a set of functions (in the IEC 61131-3 sense you would like to use in several FBs. This was also the direction I thought about for the tool support. Because we could then have a code generator for this functions so that you can write them platform and system independent in pure IEC 61131-3 ST.

In the mean time I found even a further workaround for your issue. I found a way how you can call other algorithms from your algorithms in ST. For this you unfortunately need to know that our code generator is prefixing the algorithm names in C++ with "alg_". So when you write in your ST algorithm where you like to call an other algorithm called myAlg alg_myAlg the correct code should be generated in your c++ file. This is also a little platform dependant as it would in the beginning only work for our code generator. What we could rather quickly add for you to test (maybe in the code for the upcoming 1.9 version) that we add the prefix during code generation if you are interested to work on a special version of 4daic for tests. Based you your experience we could then work on the new text for the standard. And you could do everything in portable structured text.

P.S.: From your description I would be rather curios on the final result of your application. We would be happy to feature a guest post in our news/blog on what you are doing.

Report message to a moderator

Re: declaration of subroutines/functions currently not possible in ST algorithms? [message #1761379 is a reply to message #1761340]

Wed, 10 May 2017 11:32

Marc Jakobi

Messages: 67
Registered: April 2017

Member

I would be glad to work on a development branch of 4diac and provide feedback. Sounds like a great opportunity.

About your P.S.: I'm still in the beginning phase of my project, but I'd be happy to see it in a guest post on your news/blog Smile

Here's a short summary (If you like, we can discuss the details via e-mail or something)

For my master's thesis, I am developing a model-based controller for solar energy systems (i.e. photovoltaics + battery + heat pump).
Currently, I am working on function blocks that will implement power generation and load forecasting and forecast-based charge optimisation (e.g. the PVprog algorithm developed at HTW-Berlin).
I am hoping to create a communication interface between FORTE and the simulation software Polysun so that the application can be developed as a model-view-controller (where Polysun is the model that can be swapped out for field tests with a real system later on).
Finally, I want to implement the EEBus "SPINE" communication protocol (a relatively new protocol on the application layer for smart home systems that supports features like device discovery).

Report message to a moderator

Re: declaration of subroutines/functions currently not possible in ST algorithms? [message #1761434 is a reply to message #1761379]

Thu, 11 May 2017 06:51

Monika Wenger

Messages: 18
Registered: September 2015

Junior Member

do not know if it is already clear ... we implemented all standard IEC 61131-3 functions and function blocks within 4diac. These function blocks are contained within 4diac's type library > IEC 61131-3 folder. They can be activated in cmake as own module. within a former research project we also integrated armadillo in 4diac, in case you are interested to use something similar within your master thesis.

to implement your own communication layer you should have a look on this

Report message to a moderator

Re: declaration of subroutines/functions currently not possible in ST algorithms? [message #1763495 is a reply to message #1761434]

Tue, 16 May 2017 17:31

Marc Jakobi

Messages: 67
Registered: April 2017

Member

Thanks for the tips.
I don't think I'll be using armadillo in my current project, since I want to stick to IEC 61499 conformity as much as possible, but it's good to know it's available for possible future projects.

Report message to a moderator

Previous Topic:	using OPC to control siemens PLC
Next Topic:	BOOL to ANY_BIT converstion (IEC61131-3 Bitwise Operators)

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 23 16:35:09 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter