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">
[QAction] string sText = Convert.ToString( protocol.GetParameter( xxx ) );
<Name>MsgText</Name>
<Description>MSG TEXT</Description>
<Type>read</Type>
<Interprete>
<RawType>other</RawType>
<Type>string</Type>
<LengthType>next param</LengthType>
</Interprete>
</Param>
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 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.