You forgot, [Stage 6] Buy Siemens and fill the headquater with ball bath balls and have all the Managers serve cotton candy to Kids that get to play there for free all day :-)
But back to being serious :-) In java it's not that bad to assemble the messages that the drivers send, in Go it however sucks quite a bit and in C it's a nightmare. So I would love to automate that process. I had a lengthy chat with Sebastian today. He was showing me his new XML serialization. I then remembered how I brought up the idea of a MessageFactory as a next logical step some time ago and initially thought about using the test-data in the Integration-tests as a basis. Unfortunately generating code from that would have been quite a task, because the Jackson XML format was missing quite some information. Sebastian's new format however has all of this information and it would therefore be quite simple to create a code-generator from this. Therefore, it would be great, if we would simply define a list of pre-defined messages in an XML document that we put alongside the mspec. Right now, I would probably simply fire an XSLT on the XML ... this would mean that for every language we would also create an XSLT for the MessageFactory. We could then either use normal Maven plugins, or - what I would prefer - give our code-generator a second mojo that we would simply call to generate this. The configuration needed when using default maven plugins would probably scare people and if we hide this complexity in our plugin, nobody will complain. I would assume, that we don't need to define 3 additional formats. I think something like I built with daffodil and this strange xml statemachine project, should also work: - Mspec for syntax - XML for semantic So, I'm in strong favor of starting this journey. Chris -----Ursprüngliche Nachricht----- Von: Sebastian Rühl <[email protected]> Gesendet: Dienstag, 20. April 2021 17:58 An: [email protected] Betreff: Next evolution of code generation Hi Together, Having worked now on golang for a while and jumped back to java I saw that we had many similarities between the languages. First of all the structure if message being sent (e.g. during the S7 connection dance) and the conversations happening (e.g. during the s7 connect). So it feels more and more like and extension to our current code generation: [Stage 1] At the moment we are in Stage 1: - We can generate Typed structure into the languages from mspec (The definition of what is contained in an instance of a message) - We can generate „how“ the message is serialized on to its primary medium In byte form (xml, string, etc will be decoupled soon from these models, as they currently re-implement the [de]serialization in a different format [first fruits from that already in develop]) - We can generate some known constants from mspec At this point we have at least a reproducible serialization between languages (assuming the templates are correctly implemented). [For that I also have began changing the way xml (un)marshaling works which will replace the current one soon which I will talk about more in a later mail] [Stage 2] We can generate Message instances in a template like code - also a sister spec - Taking S7 for example: during a connection initalization you need to send 3 specific defined messages (with potential little variation) to the plc. These messages need to be re-implemented in every language the same way - Defining a sister-spec beside *.mspec we could define these message with placeholders and generate a MessageTypeFactory from this to create known messages. - Another example is the ADS symbolic addressing where you send a well defined message and get the response for the index offset in the response. [Stage 3] We can generate an interaction for a ping-pong - also a sister spec - e.g. Sending request x with parameters x1, x2 we expect response with value z1,z2 - defining this we could define a simple request/response and generate code from that [Stage 4] We can generate an conversation - also a sister spec - going back to the s7 connection dance, we could possible using the features from the stages before define a whole well defined flow: „Send COTP Connection Request->Receive COTP Connection Response->Send S7 Connection Request->Receive S7 Connection Response->Send S7 Identification Request->Receive S7 Identification Response“ - at the moment we do something like this already in our driver test suites but we don’t generate code from that. [Stage 5] We can define properties and options - at the moment we need to reimplement necessary options and parameters in every language again. e.g. AmsNetId, S7-Rack and so one. - defining known and required options we could generate configuration parsers in every language [Stage 6] World domination - We ran out of stages and there is nothing more left to do for plc4x :o) So now as the wall of text has ended I would be glad to get some feedback and ideas on the above points. Disclaimer: points above came up while having a fruitful OTR discussion with Chris. So credit where credit is due :) Sebastian
