[Beremiz-devel] Use of generated code for integration with variable timestep simulation

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Beremiz-devel] Use of generated code for integration with variable timestep simulation

Beremiz-Devel mailing list

Dear Beremiz developers,

 

We are developers of a variable-timestep (DAE) simulation environment (conceptually similar to Dymola/Modelica). Currently, we are investigating the possibilities of co-simulating PLC code with our physical models. Our simulator will sometimes try to take very long timesteps (hours), while we still want to simulate the PLC code with a reasonable sampling time (normally much shorter). The simulator must therefore be able to reset the state of the PLC to a previously accepted timestep, and to make multiple experiments with progressing the PLC in time from such a saved state. (Presently, each such control object written in C has to have all its internal state stored in a vector of floats that are managed by the solver.)

 

My first question is whether any similar need exists in other common PLC applications? My guess is that it doesn’t and that it will be difficult to find ready-made solutions.

 

We basically see two ways of achieving this:

 

1.       The most straightforward way might be to “manually” create a copy of the entire data structure in the generated code that stores state. The variable-timestep solver would then be able to save and reset the PLC memory by function calls.

2.       To generate code for some simple runtime environment and somehow enable the solver to be able to copy and swap the entire data memory of the runtime.

 

Another possibility that would be convenient for us would be to package the PLC code in terms of an FMU for co-simulation (www.fmi-standard.org). Perhaps there are other parties that would also be interested in such a solution.

 

Please share your general thoughts about the best solution to our problem, or follow-up questions, to this list. We would also be grateful for any contacts that could help us achieve one of the solutions.

 

Best regards,

 

Per Sahlin

 

-----------------------------------------

Per Sahlin

CEO

EQUA Simulation AB

[hidden email]

+46   8 546 20 111

+46 70 422 03 02   (mobile)

plurresahlin (skype)

Råsundavägen 100

169 57 SOLNA, Sweden

http://www.equa.se

-----------------------------------------

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Use of generated code for integration with variable timestep simulation

Beremiz-Devel mailing list
Hi Sahlin,
I think there is another option using Beremiz PLC. You can create a C module to allow and control access data (module synchronizes your structure with plc local data).

Best regards,
Ing. Manuele Conti
Mobile:+39 3492872278
Skype: manuele.conti

On 3 May 2017, at 19:26, [hidden email] wrote:

Dear Beremiz developers,

 

We are developers of a variable-timestep (DAE) simulation environment (conceptually similar to Dymola/Modelica). Currently, we are investigating the possibilities of co-simulating PLC code with our physical models. Our simulator will sometimes try to take very long timesteps (hours), while we still want to simulate the PLC code with a reasonable sampling time (normally much shorter). The simulator must therefore be able to reset the state of the PLC to a previously accepted timestep, and to make multiple experiments with progressing the PLC in time from such a saved state. (Presently, each such control object written in C has to have all its internal state stored in a vector of floats that are managed by the solver.)

 

My first question is whether any similar need exists in other common PLC applications? My guess is that it doesn’t and that it will be difficult to find ready-made solutions.

 

We basically see two ways of achieving this:

 

1.       The most straightforward way might be to “manually” create a copy of the entire data structure in the generated code that stores state. The variable-timestep solver would then be able to save and reset the PLC memory by function calls.

2.       To generate code for some simple runtime environment and somehow enable the solver to be able to copy and swap the entire data memory of the runtime.

 

Another possibility that would be convenient for us would be to package the PLC code in terms of an FMU for co-simulation (www.fmi-standard.org). Perhaps there are other parties that would also be interested in such a solution.

 

Please share your general thoughts about the best solution to our problem, or follow-up questions, to this list. We would also be grateful for any contacts that could help us achieve one of the solutions.

 

Best regards,

 

Per Sahlin

 

-----------------------------------------

Per Sahlin

CEO

EQUA Simulation AB

[hidden email]

+46   8 546 20 111

+46 70 422 03 02   (mobile)

plurresahlin (skype)

Råsundavägen 100

169 57 SOLNA, Sweden

http://www.equa.se

-----------------------------------------

 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Use of generated code for integration with variable timestep simulation

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
Hi, Per!

I think that it is possible to develop a Beremiz target which can do what you need.

Currently Beremiz generated debugger code have the capabilities to get and set(force) PLC variables, see [1], there are certain functions:

RegisterDebugVariable - used to register debug variable, can set (force) the variable,
ResetDebugVariables
- may be called to clear PLC vars force flags before simulation starts after PLC state variables have been set,
GetDebugData
           - can read registered PLC variables
FreeDebugData          - must be called after GetDebugData when PLC vars have been copied.

I think that Linux target may be used a s starting point in such target developement.

Best regards,
Paul Beltyukov

2017-05-03 22:26 GMT+05:00 <[hidden email]>:

Dear Beremiz developers,

 

We are developers of a variable-timestep (DAE) simulation environment (conceptually similar to Dymola/Modelica). Currently, we are investigating the possibilities of co-simulating PLC code with our physical models. Our simulator will sometimes try to take very long timesteps (hours), while we still want to simulate the PLC code with a reasonable sampling time (normally much shorter). The simulator must therefore be able to reset the state of the PLC to a previously accepted timestep, and to make multiple experiments with progressing the PLC in time from such a saved state. (Presently, each such control object written in C has to have all its internal state stored in a vector of floats that are managed by the solver.)

 

My first question is whether any similar need exists in other common PLC applications? My guess is that it doesn’t and that it will be difficult to find ready-made solutions.

 

We basically see two ways of achieving this:

 

1.       The most straightforward way might be to “manually” create a copy of the entire data structure in the generated code that stores state. The variable-timestep solver would then be able to save and reset the PLC memory by function calls.

2.       To generate code for some simple runtime environment and somehow enable the solver to be able to copy and swap the entire data memory of the runtime.

 

Another possibility that would be convenient for us would be to package the PLC code in terms of an FMU for co-simulation (www.fmi-standard.org). Perhaps there are other parties that would also be interested in such a solution.

 

Please share your general thoughts about the best solution to our problem, or follow-up questions, to this list. We would also be grateful for any contacts that could help us achieve one of the solutions.

 

Best regards,

 

Per Sahlin

 

-----------------------------------------

Per Sahlin

CEO

EQUA Simulation AB

[hidden email]

+46   8 546 20 111

+46 70 422 03 02   (mobile)

plurresahlin (skype)

Råsundavägen 100

169 57 SOLNA, Sweden

http://www.equa.se

-----------------------------------------

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Use of generated code for integration with variable timestep simulation

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list

 Hello Per,



On Wednesday 03 May 2017 18:26:33 [hidden email] wrote:
> Dear Beremiz developers,
>
(...)

> The simulator must therefore be able to reset the
> state of the PLC to a previously accepted timestep, and to make multiple
> experiments with progressing the PLC in time from such a saved state.
> (Presently, each such control object written in C has to have all its
> internal state stored in a vector of floats that are managed by the
> solver.)
>
> My first question is whether any similar need exists in other common PLC
> applications? My guess is that it doesn't and that it will be difficult to
> find ready-made solutions.
>

 Well, it could make sense in a fault-tolerant setting where redundant PLCs
were to be used. Depending on the redundancy architecture (hot or cold stand-
by, forward or backward recovery, etc...), a snapshot of the current state
would make sense in this scenario.


> We basically see two ways of achieving this:
>
>
> 1.       The most straightforward way might be to "manually" create a copy
> of the entire data structure in the generated code that stores state. The
> variable-timestep solver would then be able to save and reset the PLC
> memory by function calls.
>

 What do you mean by 'manually'?
 If you want to require manual changes to the generated C code, then obviously
anything is possible. But I am sure you want some kind of automation. How much
automation would you consider viable?

 Thinking about this for less than 5 minutes, it seems to me that it could be
possible to make an ugly hack that would serialize all the internal state. At
the moment I think you could get away with doing this without any changes to
matiec.


>
> 2.       To generate code for some simple runtime environment and somehow
> enable the solver to be able to copy and swap the entire data memory of
> the runtime.
>


 I don't exactly know what kind of 'runtime environment' you are considering.
Running the C code generated by the matiec compiler does require a (very few)
lines of code that may be considered a runtime environment, but it is possible
that you are thinking of something else. Perhaps some code that does dynamic
linking of the compiled C code? Something else?

 This might be possible, but it seems to me that it would take more effort.


> Another possibility that would be convenient for us would be to package the
> PLC code in terms of an FMU for co-simulation
> (www.fmi-standard.org<http://www.fmi-standard.org>). Perhaps there are
> other parties that would also be interested in such a solution.

 I was not aware of this standard. I have just spent 5 minutes looking at
their website, and to be honest my first impression is that this approach might
just be possible. We may need to somehow change the structure of the generated
C code (I don't exactly know what FMI expects), but doing this seems to me to
be eminently feasible (depending on how many changes are required).

 This might require a few changes to the matiec compiler. It is something we
would need to look into.




  There are other ways we could approach this (as suggested by some other
posters). Some would take a long time to make a snapshot but require minimal
changes to matiec generated C code (e.g. using the debugging functions to
read/write the variables), while others could be faster but require more
changes. It really depends on how much you wish to invest in this...


  Yes, I know my comments did not help you out very much - unfortunately this
was intentional. I have provided thousands of lines of code for free under the
GPL. I am not however willing to provide technical assistance to commercial
entities for free. I hope you understand. If you perchance decide that I might
just be able to assist you, please feel free to contact me (msousa at
fe.up.pt).


 Cheers,

         Mario.


 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Use of generated code for integration with variable timestep simulation

Beremiz-Devel mailing list
Hi Mario,

I want to reply at this email to explain what I think is wrong with the beremiz project mailing list. You are the most expertise about matiec project so if a user want to get best help he must write to you. This is the way open source project work. 

In my opinion writing that you do not work for free it seems to me is not polite.

Maybe you should have a way to underline your position in this project (changing your signature?!) or create a fork version with a professional support.


Do not be angry at me was just a friend's observation :-)

Best regards,
Manuele

On 4 May 2017, at 20:58, [hidden email] wrote:


Hello Per,



On Wednesday 03 May 2017 18:26:33 [hidden email] wrote:
Dear Beremiz developers,

(...)
The simulator must therefore be able to reset the
state of the PLC to a previously accepted timestep, and to make multiple
experiments with progressing the PLC in time from such a saved state.
(Presently, each such control object written in C has to have all its
internal state stored in a vector of floats that are managed by the
solver.)

My first question is whether any similar need exists in other common PLC
applications? My guess is that it doesn't and that it will be difficult to
find ready-made solutions.


Well, it could make sense in a fault-tolerant setting where redundant PLCs
were to be used. Depending on the redundancy architecture (hot or cold stand-
by, forward or backward recovery, etc...), a snapshot of the current state
would make sense in this scenario.


We basically see two ways of achieving this:


1.       The most straightforward way might be to "manually" create a copy
of the entire data structure in the generated code that stores state. The
variable-timestep solver would then be able to save and reset the PLC
memory by function calls.


What do you mean by 'manually'?
If you want to require manual changes to the generated C code, then obviously
anything is possible. But I am sure you want some kind of automation. How much
automation would you consider viable?

Thinking about this for less than 5 minutes, it seems to me that it could be
possible to make an ugly hack that would serialize all the internal state. At
the moment I think you could get away with doing this without any changes to
matiec.



2.       To generate code for some simple runtime environment and somehow
enable the solver to be able to copy and swap the entire data memory of
the runtime.



I don't exactly know what kind of 'runtime environment' you are considering.
Running the C code generated by the matiec compiler does require a (very few)
lines of code that may be considered a runtime environment, but it is possible
that you are thinking of something else. Perhaps some code that does dynamic
linking of the compiled C code? Something else?

This might be possible, but it seems to me that it would take more effort.


Another possibility that would be convenient for us would be to package the
PLC code in terms of an FMU for co-simulation
(www.fmi-standard.org<http://www.fmi-standard.org>). Perhaps there are
other parties that would also be interested in such a solution.

I was not aware of this standard. I have just spent 5 minutes looking at
their website, and to be honest my first impression is that this approach might
just be possible. We may need to somehow change the structure of the generated
C code (I don't exactly know what FMI expects), but doing this seems to me to
be eminently feasible (depending on how many changes are required).

This might require a few changes to the matiec compiler. It is something we
would need to look into.




 There are other ways we could approach this (as suggested by some other
posters). Some would take a long time to make a snapshot but require minimal
changes to matiec generated C code (e.g. using the debugging functions to
read/write the variables), while others could be faster but require more
changes. It really depends on how much you wish to invest in this...


 Yes, I know my comments did not help you out very much - unfortunately this
was intentional. I have provided thousands of lines of code for free under the
GPL. I am not however willing to provide technical assistance to commercial
entities for free. I hope you understand. If you perchance decide that I might
just be able to assist you, please feel free to contact me (msousa at
fe.up.pt).


Cheers,

        Mario.




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel