plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject Re: Proposal for driver generation ...
Date Tue, 29 Jan 2019 08:43:21 GMT
Apache is a funny organization, I noticed so many times before.

So I started searching for some existing solutions for defining state machines and stumbled
over SCXML [1]

When doing some more research on this I found some pages that referenced examples. Unfortunately
when visiting these sites, I got 404s ... but when looking at the url, I noticed it's an Apache
So it seems that the Apache Commons project has a sub-project exactly about this [2]
The good thing is: Being Apache Committers we could contribute to this project automatically
:-) (Don't know if you all know that every Apache committer automatically has commit rights
to the Apache Commons repos ... of course you shouldn't just go ahead changing things without
discussing things ...)

From a first glance, it looks as if it's a quite good fit.

Will report any findings.



Am 28.01.19, 15:41 schrieb "Christofer Dutz" <>:

    Hi all,
    So in the past two weeks I managed to write a DFDL definition for the message types of
the Siemens S7 protocol. And also a lot of tests testing that spec.
    I was even able to reproduce and fix the bug Tim reported (with the filling bytes).
    With this we would be able to handle the serialization and the parsing of messages. However
this is only 50% of the way.
    Right now I’m planning on creating a new “sandbox” pom-module where we can add experimental
stuff till it’s production-ready.
    One of these should be a Daffodil based S7 driver.
    This would sort of be a test for implementing new protocols the simple way. This would
greatly simplify implementing new protocols
    But even with Daffodil or a generated model+parsers+serializers still this is only about
50% of the work. We still have to define standard messages, pass in our arguments and then
hard-code which message is sent when and how to handle the response.
    So that got me thinking … in Daffodil I was able to define the expected message-output
in XML. So in general I could define my message templates exactly the same way.
    The thing I’m still missing, is defining the state-machine of the protocol.
    So here comes my proposal:
    We could define a XML format for defining states and transitions. These make up the state
machine of our protocol.
    To each transition a message template is attached. In the states we can define what to
do (stay, take a next transition, …) based on XPath expressions … so if we just sent a
CotpConnectRequest, well instantly go to a state where reading a response goes to another
state … if the response return code is then “All OK” we use the transition that sends
the SetupCommunicationRequest and then wait for a response and depending on that responses
return code go to the next state and so on.
    This way we could define a protocol completely independent of the programming language
and we could generate almost 100% of the drivers in the future.
    What do you think?

View raw message