Hi, Just a clarification, I have these to changes complete (at least for java) in the opcua branch. I'd need to see what changes I made and port them over to the other three languages.
I might create a branch just for these at some point to make it a bit clearer as to what was done. Kind Regards, Ben On Sun, Feb 14, 2021 at 8:14 AM Christofer Dutz <[email protected]> wrote: > Hi Ben, > > first off all ... a big +1 for allowing Enums in discriminator field. > Actually there shouldn't be any change to mspec itself required to support > that. Just in the code-generation we need to tweak a bit. If we use an enum > value as discriminator (a feature I recently added) it only makes sense to > use the enum value in a discriminator. > > The second proposal took a while till I understood what you are referring > to. But do I understand correctly: > > - Currently, if someone uses a string field, he provides the length in > bits. > - Now if we wanted to provide dynamic strings, you propose to make the > size-argument also accept expressions? > > I agree that this would be great ... especially in S7 it would help clean > up things a LOT. I have also thought about this in the past and I think I > even tried working on it, but gave up every time. The reason for this was, > that it requires changing the Antlr4 grammar, the parser, the model, all > LanguageHelpers as well as all Language templates. > > So this "little" change would be quite a big change requiring a LOT of > work. I wasn't going to invest the time on my own to do this allone. But if > we want to do it together, I'd be happy to do that on a branch. > > Chris > > -----Ursprüngliche Nachricht----- > Von: Ben Hutcheson <[email protected]> > Gesendet: Sonntag, 14. Februar 2021 12:48 > An: [email protected] > Betreff: Changes to mspec > > Hi, > > While working on the OPC UA native driver I have come across a couple of > cases where it was beneficial to modify mspec. I'd like to bring these up > for discussion. > > - OPC UA makes heavy use of pascal strings. This is where the length of > the string precedes the string. Currently when specifying a string in mspec > we have two options. If the string is a predefined length just use the > length in bits. If it is a variable length then we would need to call a > manual function such as what the S7 mspec does. > > ['IEC61131_STRING' STRING > [manual string 'UTF-8' 'value' > 'STATIC_CALL("org.apache.plc4x.java.s7.utils.StaticHelper.parseS7String", > io, stringLength, _type.encoding)' > > 'STATIC_CALL("org.apache.plc4x.java.s7.utils.StaticHelper.serializeS7String", > io, _value, stringLength, _type.encoding)' '_value.length + 2'] ] > > My proposal would be to allow the length of the string length to be an > inline mspec function. > > [type 'PascalString' > [simple int 32 'stringLength'] > [optional string 'stringLength * 8' 'UTF-8' 'stringValue' > 'stringLength >= 0'] > ] > > This allows us to specify a variable length string using the preceding > string length. We could also expand this to have a variable length field > for any data type, however I'll leave that out of this scope. > > > - We have a field type in mspec to be able to specify a value is an > enumerated type. However if we then need to make that field a discriminator > for a typeswitch we can't. > > discriminatedType 'ExpandedNodeId' > [simple bit 'namespaceURISpecified'] > [simple bit 'serverIndexSpecified'] > [discriminator NodeIdType 'nodeIdType'] > [typeSwitch 'nodeIdType' > ['NodeIdType.TwoByte' ExpandedNodeIdTwoByte > [simple TwoByteNodeId 'id'] > ] > ['NodeIdType.FourByte' ExpandedNodeIdFourByte > [simple FourByteNodeId 'id'] > ] > ['NodeIdType.Numeric' ExpandedNodeIdNumeric > [simple NumericNodeId 'id'] > ] > ['NodeIdType.String' ExpandedNodeIdString > [simple StringNodeId 'id'] > ] > ['NodeIdType.Guid' ExpandedNodeIdGuid > [simple GuidNodeId 'id'] > ] > ['NodeIdType.nodeIdTypeByteString' ExpandedNodeIdByteString > [simple ByteStringNodeId 'id'] > ] > ] > [optional PascalString 'namespaceURI' 'namespaceURISpecified'] > [optional uint 32 'serverIndex' 'serverIndexSpecified'] ] > > Shown above is my proposal where the nodeIdType is an enum and is used as > the typeSwitch parameter. This allows us to retain the use of an enum when > we also need to use it as a discriminator. > > Looking forward to hearing your opinion. > > Ben >
