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>*
            >
            
        
        
    
    

Reply via email to