Oh Hi Lukas, I just committed a first version of the Modbus mspec ... I think if you take the modbus spec from here (http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf) And the little part about TCP from here (http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf)
I think you will understand the concepts of mspec pretty quickly. The only tricky part might be the typeSwitch thing ... let me add a little explanation here: In the typeSwitch you define a list of inputs for the case decision ... in the modbus mspec there is only one. So in this case we have 3 inputs: Boolean error, Byte function, Boolean response So what happens now is that for each case only the existing values are matched: In case of the ModbusPduError sub-type, only the first parameter is checked, so if "error" is "true", it will use this type and ignore the following ones. So that's why all other cases have the first parameter set to "false". Theoretically you could have a type with no arguments at all at the end, which would become some sort of "default-type", but in general this wouldn't make any sense. An "implicit" type is one who's value is sort of redundant. So if I have a "length" field that defines the length of some payload ... the value of this field is implicitly defined by the data array. So in this case the value is only used during the parsing and is not persisted in the entity. In order to know the value when serializing, you need to specify an expression so the serializer can calculate the value ... I think there are several places where I'm using implicits ... please feel free to read and learn. On the website I should have a reasonably up-to-date documentation on the field types (http://plc4x.apache.org/developers/code-gen/protocol/mspec.html) ... I know there is room for improvement, but we'll keep on improving it. Hope that gets you started. Chris Am 18.01.20, 10:22 schrieb "Lukas Ott" <ott.lukas...@gmail.com>: Hi Chris, I would like to learn more when you starting building the Mspec for Modbus and generate the drivers. So a little tutorial on how we build the Mspec - step by step not just the final result and more details on how the drivers are then generated using the Mspec. For example - Mspec -> Complex Type generates this class structure in the driver etc. So we can make it easier to start working on supporting other programming languages as well. Because the overall flow and building gets clearer. As you may know I am interested in supporting e.g. Python but for me personally the current complexity needs some break down to smaller tasks so that i have an entry point where i can support the project easier. Lukas Am Sa., 18. Jan. 2020 um 09:52 Uhr schrieb Christofer Dutz < christofer.d...@c-ware.de>: > Hi all, > > I just wanted to inform you that yesterday I merged the changes from the > “next-gent-core-2” branch back to develop. > The next-gen S7 driver is now renamed from s7ng to s7 as it’s going to > replace the old one fully (Still need to fix one thing and then it’s ready > to go) > In its current state we have lost a lot of drivers which we once had. > > I will put in some extra effort to port at least two of these drivers to > Mspec as soon as possible (Modbus and EtherNet/IP) > Some drivers like the ADS and the S7 are currently still located in the > sandbox, so be sure to enable the “with-sandbox” profile. > > Would be cool if you could try it out. > > Chris >
