I’m creating a ‘smart-serial’ connector for the device that sends ascii/unicode string.
Without options=”unicode” type, they can received by the following definitions.
(Of course, I can’t display unicode string correctly.)
[Parameter]
<Param id=”xxx”>
<Name>MsgText</Name>
<Description>MSG TEXT</Description>
<Type>read</Type>
<Interprete>
<RawType>other</RawType>
<Type>string</Type>
<LengthType>next param</LengthType>
</Interprete>
</Param>[QAction]
string sText = Convert.ToString( protocol.GetParameter( xxx ) );
But with options=”unicode” type, only unicode string can be received and no ascii string received.
How to define parameter for receiving both unicode/ascii strings correctly?
Hi Hideyuki,
As Edib already mentioned, ascii is a subset of unicode so you should be able to receive it in the same parameter. Strings are being terminated by a 0x00 byte though, so maybe check if that character is not being sent by the device.
Another thing I wanted to mention is that when the protocol is unicode, the commands are also being sent to the device as unicode instead of ascii. You can override that on command level using the following attribute: https://docs.dataminer.services/develop/schemadoc/Protocol/Protocol.Commands.Command-ascii.html. Maybe the device doesn’t recognise the command anymore after changing the protocol to unicode, and sends back a much shorter response now.
Are you processing the data in a QAction? If that’s the case you could use the GetData() method to retrieve the raw unprocessed bytes from the parameter. Then you can do the desired conversion yourself. More information about the GetData method can be found here: https://docs.dataminer.services/develop/api/types/Skyline.DataMiner.Scripting.SLProtocol.GetData.html.
Hi Tom,
Thank you for the prompt response.
GetData() solved all the issues!
Now I can get both unicode/ascii string correctly by converting from byte array.
You’re welcome! I’m glad to hear that it’s solved now.
Hi Hideyuki,
ASCII is a proper subset of Unicode, which means that Unicode includes all the characters that can be encoded in ASCII, plus many more.
as we can see here all ascii characters are unicode characters as well, so if you set options=”unicode” you should be able to receive and format correctly all acsii characters as well. If that’s not the case your issue may be something else.
Hi Edib,
Thank you for the comments.
[ following comments edited ]
Unicode is not UTF8 but UTF16LE. So, ascii charactor codes are not included in UTF16.
The response definition should be OK because I can get ascii/unicode string without “unicode” option.
With more tests, I found that when the ascii string with odd length received, the last character is missing.
ex) If 1 character received, no string can be available from the parameter.
-> This parameter seems to receive only unicode(UTF16) string???]
Any idea where I have made mistakes in the connector?
String with odd length is not valid UTF16 string, because 16 in UTF16 means 16 bits, 2 bytes. So all valid UTF16 strings must have even number of bytes. LE part in UTF16LE is not relevant in this case, it is relevant how you interpret the data received, LE means little endian.
Hi Edib,
Thank you for the comment.
Of course I know that UTF16 has fixed length 2bytes.
My question was how to prepare buffer for both ascii/unicode.
Now I can retrieve both data using GetData() and convert to unicode/ascii string correctly.
Hi Tom,
Thank you for the comments.
As I commented below, this device send UTF16LE that includes 0x00.
ex) “ab” char in UTF16LE is 0x61 0x00 0x62 0x00 and these are handled correctly with unicode option.
This connector acts as server and only receiving packets.
I think ‘ascii’ option is not available on response nodes.