Hi Björn,
thanks for that ... just had a short look ... it seems to be technologically
integratable as it seems to require the installation of the usual suspects we
already have for building C++ and Thirft.
However I doubt integrating this into the PLC4X system would be a good idea -
If we wanted to use it for testing also ...
Does it allow to define logic modules which can then be run in it? ... I'm sort
of thinking of building tutorials with matching mock PLC simulations. A java
based system might be more publicly acceptable.
Perhaps it's inner workings could be a good inspiration though ... as I'm not
very looking forward to writing C code ;-)
Chris
Am 18.10.19, 08:11 schrieb "Bjoern Hoeper" <hoe...@ltsoft.de>:
Hey everyone,
sorry for joining the party this late. But it is rather busy times at the
moment.
Depending on the context maybe I can help with an existing solution: There
is the runtime environment provided by the Chair of Process Control Engineering
in Aachen. It is a rather complete RTE for PLCs which can also be manipulated
during runtime. The neat thing about this is that it is available as open
source under Apache 2.0 license. Our company has several extensions (mostly
also open source) which can be used to manipulate the internal state of the PLC
during runtime. If we would like to add other communication protocols (at the
moment ACPLT/KS and OPC-UA are available) the communication is modularized.
Furthermore everyone may customize what is running inside the RTE by writing
own libraries in C.
Regarding the ACPLT/KS solution we have a ReST API in C# which can be used
like the low-level API sketched out by Tim. At the moment this is not open
source but we could think about it. So it would be an easy start because we
have already quite a lot available.
Maybe you guys just check it out under: https://github.com/acplt/rte.
Next week at ApacheCon I could also give a little introduction because it
is not all to obvious how everything fits together.
Best Regards
Björn
-----Ursprüngliche Nachricht-----
Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Donnerstag, 17. Oktober 2019 16:24
An: dev@plc4x.apache.org
Betreff: Re: [PLC-Simulator] Thoughts on the "Context" for our simulator
Hi all,
Just had another idea what the Simulator could be good for (or at least the
server modules)
If we want to simulate bad behavior for integration tests ... with these we
can sort of implement any form of bad behavior ;-)
- Invalid responses
- Slow responses
- Dropping connections
- ...
The more I think about it, the better it gets ;-)
Chris
Am 17.10.19, 11:08 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
The intended user of the simulator (Perhaps we should really call it
PLC-Mock)
Is definitely people wanting to learn how to use PLC4X.
Poor documentation and the availability of no tutorials, how-tos or
trainings is one thing many people have complained about.
Using an OPC-UA simulator could potentially help, but it would only
cover one of the communication options.
For me OPC-UA is not a usable reality in the real world yet (Lack of
availability of OPC-UA capable PLCs and the bad performance of the existing
ones).
Usually a PLC has multiple options to communicate (My S7 can do (I
think): S7-STEP7, S7-TIA, Modbus, ProfiNet) ... each protocol has its
advantages and disadvantages.
So with the simulator supporting all the protocols we support as
clients, a user could experiment on all of this.
It will currently be a pretty restricted thing ... so it will probably
not be able to simulate every type of S7 or other hardware,
but we could make sure it supports everything we want to demonstrate in
tutorials (Just like a good Mock ... you don't use that in production ... well
... ok ...
there was this one Bank that actually had Mokito in the compile path,
because one service in production was a Mock ... but usually you don't expect
this).
Hope that explains things a bit more.
Chris
Am 17.10.19, 05:45 schrieb "Otto Fowler" <ottobackwa...@gmail.com>:
Who is the intended user of the simulator, or users and what do
they want
to accomplish? Maybe if that were spelled out or people could
suggest those
cases, some number of cases could be agreed upon, allowing the
initial
effort to be done with plans for later expansion to the remaining
uses
cases down the road.
In my own case:
In the past I have used PLC simulators that I have written or from
open
source projects to stand in for real devices when I could not
acquire the
hardware. I am not sure that that use case should be high on
PLC4X’s list
since that is a lot to chase.
With PLC4x, I have thought that I would need or like a simulator or
“sample
system app->driver->simulator” in order for me, as a developer to
debug and
trace through the PLC4X workings, such that I could then understand
the
system well enough to either work on it or develop against it.
These types
of systems can stand in leu of, or augment extensive developer
documentation.
At the rate that Chris and others are progressing with refactoring
and
extending the libraries, it would be helpful to have such a system
maintained as those refactoring went along.
On October 16, 2019 at 21:07:02, Strljic, Matthias Milan (
matthias.strl...@isw.uni-stuttgart.de) wrote:
Hi Chris,
yeah i see the benefits of doing all this simulated PLC endpoints
for a
nice testing.
I just meant that it is also possible to just setup an OPC UA
Endpoint
Server with Eclipse Milo in Java or a Python package without a real
PLC
behind it.
So it is possible to just program and provide a sample Server which
could
be started for playing around with a "acting like a real PLC"
Endpoint.
There I just wanted to throw it in as a light weight solution to
provide a
starter scenario. This ofc then is complete restricted to OPC UA.
+1 if the goal is to implement(generate?) a simulated endpoint with
the
same generated serialization components for a two sided testing
scenario
for all the supported protocols.
Matthias
Matthias Strljic, M.Sc.
Universität Stuttgart
Institut für Steuerungstechnik der Werkzeugmaschinen und
Fertigungseinrichtungen (ISW)
Seidenstraße 36
70174 Stuttgart
GERMANY
Tel: +49 711 685-84530
Fax: +49 711 685-74530
E-Mail: matthias.strl...@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de
-----Ursprüngliche Nachricht-----
Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Wednesday, October 16, 2019 10:09 PM
An: dev@plc4x.apache.org
Betreff: Re: [PLC-Simulator] Thoughts on the "Context" for our
simulator
Hi Matthias,
Well my colleagues used such a simulated OPC-UA PLC.
And the thing is we don't really need a real PLC with RT Cycles and
such
... we want something a PLC4X learning person can use instead of a
PLC.
The thing is with these you would only be able to do one little
part of
PLC4X learning.
With the Simulated PLC (Or Mock PLC) I think we'll be able to
provide
dedicated simulation modules and real training for different types
of PLCs
and protocol.
Also it's a great test for the old and new drivers. At least I
found one
big (potential) problem in the old S7 driver and quite a bit of
fine-tuning
of the new ones.
The end result should be something simple to start as "java -jar
plc-simulator.jar" and off you go ...
now just connect to localhost using whatever protocol you like and
start
playing and comparing.
With all the others you would probably have to sort of also provide
some
sort of program but they would always just use one or max two
protocols.
Chris
Am 16.10.19, 17:38 schrieb "Strljic, Matthias Milan" <
matthias.strl...@isw.uni-stuttgart.de>:
Hi Chris,
sry for joining so late.
What speeks against a OPC UA Server as PLC-Mok. It is not a big
deal to
implement it with Milo and provides a function complete OPC UA
Server
implementation.
I Know it is not a real PLC and has no RT Cycles which restricts the
possible communication.
But I do not know if such a technical deep simulation is the right
thing
for the IT-guys and for the OT guys there is in my opinion no gain
without
pain 😃
For that I would agree with @Lukas Ott and rather cooperate with
some
existing solutions and add there a nice setup/starter guide which
can also
be used by the IT beginners?
Gereetings
Matthias Strljic, M.Sc.
Universität Stuttgart
Institut für Steuerungstechnik der Werkzeugmaschinen und
Fertigungseinrichtungen (ISW)
Seidenstraße 36
70174 Stuttgart
GERMANY
Tel: +49 711 685-84530
Fax: +49 711 685-74530
E-Mail: matthias.strl...@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de
-----Ursprüngliche Nachricht-----
Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Wednesday, October 16, 2019 9:38 AM
An: dev@plc4x.apache.org
Betreff: Re: [PLC-Simulator] Thoughts on the "Context" for our
simulator
Hi Lukas,
my colleagues here at codecentric recently did some searching for
simulated
PLCs.
They were writing a blog post about the PLC4X Logstash integration
and
needed something to produce test-data.
To make it short: They were very unhappy with what they found. In
the end I
think they used some opc-ua simulator.
For some you needed to actually write projects for the PLC with for
example
TIA as they simulate being a real PLC ;-) Most of them simulate
being PLCs
but lack the communication options (Most of them only support
Modbus and
OPC-UA) If I look at the open-plc thingy you reference ... that is
good to
learn to program PLCs. The editor looks as if you could learn this
(from a
IT developer's point of view) little strange way of writing
programs for
PLCs.
From the documentation it only supports Modbus.
We want to build something to help learn writing PLC4X software,
not to
write software running on PLCs ...
especially to learn writing software for the different protocols
PLC4X
supports.
Perhaps "PLC simulator" is sort of a bad name as we wouldn't even
try
simulate being a real PLC.
It's more intended to be a mock PLC for training purposes.
So I was hoping to have multiple protocol servers running on
multiple fixed
simulations and writing how-tos and perhaps even videos and
Trainings on
how to use PLC4X based on these very fixed scenarios but using
varying
protocols.
I think this is what I currently hear most as being the missing
piece of
getting started with PLC4X.
And I found out that it's a mega-awesome testcase for our generated
drivers
:-) Being able to use the old hand written drivers to communicate
with the
generated servers already helped with getting the generated s7
driver into
shape
Chris
Am 16.10.19, 08:16 schrieb "Lukas Ott" <ott.lukas...@gmail.com>:
Hi all,
That would fit to https://www.openplcproject.com/ as the Runtime is
using
MODBUS....
Maybe ask https://github.com/thiagoralves if we just could with his
https://www.openplcproject.com/plcopen-editor ?
The major question is it easier to collaborate and leverage the
project? or
check the relevant licences and work together?
Lukas
Am Mi., 16. Okt. 2019 um 07:46 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:
> Hi Cesar,
>
> No they wouldn't. They would be exposed to the server
implementation and
> the ui.
>
> The thing is that the above structure s7 could probably
automatically
> translate into s7 addresses. However for Modbus an explicit
mapping is
> required (sort of mirroring reality with real plcs).
>
> I was thinking that perhaps the server/protocol would provide the
means
to
> map the context into their address space (extra editor) and that
the ui
for
> displaying the current context values, could have a column per
installed
> server, with plc4x addresses for addressing these resources.
>
> Just me brainstorming....
>
> Chris
>
> Holen Sie sich Outlook für Android<https://aka.ms/ghei36>
>
> ________________________________
> From: Cesar Garcia <cesar.gar...@ceos.com.ve>
> Sent: Wednesday, October 16, 2019 4:44:30 AM
> To: Apache PLC4X <dev@plc4x.apache.org>
> Subject: Re: [PLC-Simulator] Thoughts on the "Context" for our
simulator
>
> Hi Christofer,
>
> How would these data structures be exposed to the user? An API?
Or a
> service?
>
> A simple way to see it would be to have the PLC data structures
(DB, PEW,
> M, etc.) as instances of ByteBuf from the Netty library.
>
> Best regards,
>
> El mar., 15 oct. 2019 a las 8:55, Christofer Dutz (<
> christofer.d...@c-ware.de>) escribió:
>
> > Hi all,
> >
> > While implementing the S7Server part I noticed that my
HelloPlc4x
config
> > is always set to get the values of the inputs and the outputs
and not
the
> > internal memory of the S7
> >
> > So this got me thinking … just having a Map<String, Object> as
context
> > might not be enough to really play around.
> >
> > For a S7 I would assume a context should be:
> >
> > * Map<String, Object> (Sorted map with an explicit order such
as a
> > TreeMap)
> > * List<Input<Boolean>> (Digital Inputs)
> > * List<Input<Long>> (Analog Inputs)
> > * List<Output<Boolean>> (Digital Outputs)
> > * List<Output<Long>> (Analog Outputs)
> >
> > Should this be enough for a somewhat realistic simulation?
> >
> > I know for Modbus there is not automatic mapping of any form of
context
&
> > IO to the Modbus Coils (Boolean) and Registers (Short)
> > But for the rest I do think that a PLC has the concept of an
input and
> > output and these in flavors: Analog and Digital.
> >
> > I know that my PLC knowledge is somewhat theoretical. You guys
at least
> > some of you work with them every day. So I would appreciate
your input.
> >
> > Chris
> >
>
>
> --
> *CEOS Automatización, C.A.*
> *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
> *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
>
> *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
> *Ing. César García*
> *Cel: 0416-681.03.99*
>
> *Cel: 0414-760.98.95*
>
> *Hotline Técnica SIEMENS: 0800 1005080*
>
> *Email: support.aan.automat...@siemens.com
> <support.aan.automat...@siemens.com>*
>
