mspec - proposal for changing the way we read STRING values

[Łukasz Dywicki <lu...@code-house.org>]

I am starting a new thread which is not bound to S7. String handling is
a general context of drivers/mspec hence I would like to raise an
ineffeciency I observed.

The current string type itself has no ways to declare its variable
length, leading to multiple places where I had to do utilities just to
assemble strings from char/byte array. That was the case for a profinet
and LLDP mspecs I made a while ago.
While it is not big effort to make such utilities it limits portability
of mspec. I am not sure how static_call statements are mapped to C or
python, however in this particular case we can simply avoid it either by
generating necessary loop or delegating it to standard library of
underlying platform.

Now the string data type is declared as:
base='string' size=INTEGER_LITERAL encoding=idExpression

For now the only structure which permits variable length is either
"manual" or "array" field.

WDYT about making a necessary changes to support variable length strings
directly in mspec?

Best,
Łukasz


On 20.08.2020 12:44, Christofer Dutz wrote:
> Hi all,
> 
> while investigating: https://issues.apache.org/jira/browse/PLC4X-240 I noticed that the reading of STRING types seems to be extremely inefficient.
> 
> The reason is that we are currently reading a STRING element by reading 258 bytes (1 byte for MAX num of chars, 1 byte for ACT num of chars and then 256 bytes containing char data).
> 
> The problem is that with a PDU-Size of 240 you can’t read one STRING with only one packet. With a S7 1500 or 400 it might work as they have larger PDU sizes. Currently the 0.6 drivers split this up into 2 requests.
> 
> But it’s highly inefficient as usually the content will not be anywhere near the 256 chars.
> 
> So my idea is to only request one byte (the ACT size) of the String and as soon as that’s returned, to ask for only the chars that are actually used. This should drastically reduce the payload on the wire.
> 
> What do you think?
> 
> Chris
>