this the third party software I can find the string missing:

@zorro

when using Library LStream and example project for TIA Portal V16 (2,7 MB)(SHA-256) with TIA16, ...

Thank you for your very helpful report. 

Please could you do me one more favour?.. 
Visit the web page again. You will see there is a comment section on that page. Please make a note there and link to this report of yours. The designers of the library will then be notified. Else they will never see the good work you have done.

Thanks in advance for your co-operation.

Added the comment for this entry, thanks :

According to the documentation of "LStream_typeElement", for the defination of "type":

When the UDT is used in the context of a JSON structure, 0 represents an object, 1 represents an array, 2 represents a string, 3 represents a number und 4 represents a Bool

looks we can use String datatype directly inner the "tree" parameter.

For instance, the problem is in the "tree" DB: "dbJson", we have an array and each item's type is "LStream_typeElement":

the first element "dbJson[0]" and the second "dbJson[1] has the same "type"=2 represents a string, same "depth"=0 and "closingElement"=false, the only difference are the content of the "key" and "value", then after parsing this "dbJson" via "LStream_JsonSerializer", the second element's value is correct string("Module2") in the result "JsonByteArray", but the first one's value is "null" , it should be "Line1":

0_Einstein

Does the LStream documentation describe how to parse a Siemens String datatype into json, with the max length, actual length, and then character array with size set to max length?

If not, then you need to convert the "string" to a char array of the exact length, with perhaps a null termination if json expects that for json "strings".

@zorro

when using Library LStream and example project for TIA Portal V16 (2,7 MB)(SHA-256) with TIA16, using "LStream_JsonSerializer" there are a bug that if the type of the fist value is 'string' in the input output parameter tree[0], then the jsonByteArray will not show the value but with null, something like this: "Key": "",

this the third party software I can find the string missing:

then I found maybe the program has a bug to CONCAT the first string's value between two "#QUTATIONMARK"s in line No.215 of "LStream_JsonSerializer", when I modified the program like below it works well:

//zorro 2023/12/29

#statInfoToWrite := CONCAT(IN1 := CHAR_TO_STRING(#QUTATIONMARK), IN2 := #tree[#statIndexTreeArray].key, IN3 := CHAR_TO_STRING(#QUTATIONMARK),

IN4 := CHAR_TO_STRING(#COLON), IN5 := CHAR_TO_STRING(#QUTATIONMARK),IN6 := #tree[#statIndexTreeArray].value, IN7 := CHAR_TO_STRING(#QUTATIONMARK));

 

 No, I didn't use "LStream_WriteOutString", I just fill the value of the element like this :

tree[0].value := "LIne1";

...

tree[1].value := "Module2";

then call: "LStream_JsonSerializer"

0_Einstein, 

Once your S7 String is built and ready to move to json, are you using the LStream_WriteOutString Function to do that?

@zorro

According to the documentation of "LStream_typeElement", for the defination of "type":

When the UDT is used in the context of a JSON structure, 0 represents an object, 1 represents an array, 2 represents a string, 3 represents a number und 4 represents a Bool

looks we can use String datatype directly inner the "tree" parameter.

For instance, the problem is in the "tree" DB: "dbJson", we have an array and each item's type is "LStream_typeElement":

the first element "dbJson[0]" and the second "dbJson[1] has the same "type"=2 represents a string, same "depth"=0 and "closingElement"=false, the only difference are the content of the "key" and "value", then after parsing this "dbJson" via "LStream_JsonSerializer", the second element's value is correct string("Module2") in the result "JsonByteArray", but the first one's value is "null" , it should be "Line1":

0_Einstein

Does the LStream documentation describe how to parse a Siemens String datatype into json, with the max length, actual length, and then character array with size set to max length?

If not, then you need to convert the "string" to a char array of the exact length, with perhaps a null termination if json expects that for json "strings".

@zorro

when using Library LStream and example project for TIA Portal V16 (2,7 MB)(SHA-256) with TIA16, using "LStream_JsonSerializer" there are a bug that if the type of the fist value is 'string' in the input output parameter tree[0], then the jsonByteArray will not show the value but with null, something like this: "Key": "",

this the third party software I can find the string missing:

then I found maybe the program has a bug to CONCAT the first string's value between two "#QUTATIONMARK"s in line No.215 of "LStream_JsonSerializer", when I modified the program like below it works well:

//zorro 2023/12/29

#statInfoToWrite := CONCAT(IN1 := CHAR_TO_STRING(#QUTATIONMARK), IN2 := #tree[#statIndexTreeArray].key, IN3 := CHAR_TO_STRING(#QUTATIONMARK),

IN4 := CHAR_TO_STRING(#COLON), IN5 := CHAR_TO_STRING(#QUTATIONMARK),IN6 := #tree[#statIndexTreeArray].value, IN7 := CHAR_TO_STRING(#QUTATIONMARK));

 

 

 

Yes, correct, when the type of the first element is number, it works well; but if is String, then the value of the first element will be lost in the serialized bytes:

switch the type of the first element from "string" to "number", the result is as expected:

and the bug report had submitted, thank you very much.

0_Einstein

Let me backup a second ...

If I am reading this correctly (finally), I think if you have an integer as the first json element, strings work as expected the rest of the way through the json serializer.

Is that correct?

If so, definitely submit a bug report to the developer of the LSTREAM library - support and/or email link should be found towards the end of the library documentation.