Excuse me, my new groov serv still doesn’t support Chinese characters display in string. What’s the solution? Is there an easy solution?
Excuse me, my new groov serv still doesn’t support Chinese characters display in string. What’s the solution? Is there an easy solution?
I don’t have a good answer for you on this, sorry. 
Assuming you’re using groov to talk to SNAP-PAC devices, the problem is that those devices don’t have any concept of character encodings: they simply store bytes as they’re given. When groov reads a string from those devices, it has to guess at how those strings are encoded. We don’t have a good way of guessing that, so at the moment we decode them using whatever the default character encoding is on the platform that groov is running on.
(Which is probably not the best idea, we should be explicit and either always use the same encoding, or allow users to specify the encoding per device.)
If you’re using an AR-1 or AT-1, groov will use UTF-8 to decode the bytes stored on your device. If you’re using groov Server for Windows, groov will use the encoding that your Windows installation is set to use.
I believe PAC Control/Display will use the encoding that your Windows installation is set to use when writing strings, but I’ll need to double check on that.
If you wouldn’t mind trying something: If you write a tag from a groov gadget, does groov display the string properly?
Hello! Thank you for your reply。
PAC Control/Display has no problem handling Chinese strings. I’ve been using it many times.
The Groov I’m using this time is groovServer for Windows R3.4b, which is the first time I’ve used GrooV. Installed with PAC Control/Display on the same PC.
AR-1 or AT-1 is a hardware device that makes it difficult to install different character coding sets, but the software version of groov can choose to use different ones that should be viable.
Upgrade packs in the form
My personal view, I do not know if it is correct. Thank you
“ allow users to specify the encoding per device“.That’s a good idea.
We had found the same issue on PAC Display R9.6(R9.3 was okay) and reported it to Support Group.
They had fixed this issue by next release version.
We also found the same issue on RESTful and dot NET Libraries of PAC Controller & OptoMMP to read/write a string Variable/Table. We also had reported it to Support Group, but they request us to encode/decode it by our own application.
We believed developer use the ANSI or UTF-8 code not the Unicode to develop the software.
We have a user they use the Raspberry Pi and it can recognize the use’s OS is UTF-8 or Unicode.
The RESTful and dot NET Libraries always work on a windows OS, and Opto 22 is a international company, and most of software are base on windows OS. Why don’t use the Unicode?
You are right. I agree with you very much.
My client also mentioned that OPTO22 is an international company.
Why does it happen?They also use a lot of NI products
