[Imported] Logic and Russian characters

[sbeadle]

>>Message imported from previous forum - Category:ClearSCADA Software<<
User: florian, originally posted: 2018-10-25 20:35:22 Id:307
This is a re-posting from the obsoleted (October 2018) "Schneider Electric Telemetry & SCADA" forum.

-------------------------------

**_Dmirty:_**
**_I have the small logic programm:_**

_PROGRAM GenerateCSV (* ?????? ????????? *)_

_VAR CONSTANT_
_AddEnd : BOOL := 0; (* ?????????? ???? ???? 1 *)_
_FileName : STRING := 'c:\\testFile.txt'; (* ??? ????? *)_
_TmpStr : STRING := '??????? ???????';_
_END_VAR_

_VAR_
_FileNumber : UDINT; (* ????? ????? *)_
_WriteExport : UDINT; (* ????????? ?????? *)_
_CloseFile : UDINT; (* ???????? ????? *)_
_END_VAR

_FileNumber := OPEN_FILE (FileName, AddEnd );_
_WriteExport := WRITE_FILE ( FileNumber, TmpStr);_
_CloseFile := CLOSE_FILE (FileNumber);_

_END_PROGRAM_

**_result of work of of this program - some number null characters._**

**_if we replace_**

_TmpStr: = 'some English text',_

**_then the output file will contain some English text_**

**_how can I fix this program?_**

**_i use CS2013r2.1 on win7x64. System language Russian._**

**_ps ??? it is russian charaster...._**

**_forum and does not understand them too:D_**

------------------------------------

bevanweiss:
Does the Logic compile ok?

Are you able to put these characters into a String Parameter and then display it on a mimic? I'm just interested in how far the multi-language support in ClearSCADA might go..

My suspicion is that the string is only interpreted as an ANSI character array, and not in unicode or anything else capable of handling non-ANSI characters.

It might be worth trying this with CS2015R1 beta. I believe there was an enhancement for language support included. But it might not extend to the logic (in which case you'd have to raise

-------------------

evandew:
In general the logic support Unicode, e.g. when writing to a string point.

It seems that the WRITE_FILE function does not support unicode characters. There is no difference in using OPEN_FILE or OPEN_FILE_EX using text mode.

Depending what you want to do you could (ab)use a SQL Export object to write to file, since this does support Unicode.

The CS 2015R1 has got no improvements for language support in this area.

Erik

-------------------------

**_Dmirty:_**
**_Compile... Success!_**

**_If write this line in CPointStringInternal, the value write correctly._**

**_I work with ClearSCADA since CS2009r.1, we use Russian characters for points name. it works well._**
**_Animation is working with Russian symbols correctly._**
**_specifically in this case, that does not work the function WRITE_FILE._**

**_Ok._**

**_WRITE_FILE_BYTE does not work._**

--------------

bevanweiss:
I would raise a feature request for it in regards to the WRITE_FILE method call (possibly combined with the OPEN_FILE method, to open in ANSI / Unicode / UTF8 mode).

It might not help you right now, but does let Schneider know that it could be improved

----------------

**_Dmirty:_**
**_i again confront this problem. i tried to bypass using WRITE_FILE_BYTE. since there is no special function to get the symbol number, I use STRING_TO_BYTE. this function works correctly for characters with a number less than 255 (#FF) (and there is 1 byte) for characters with numbers over #FF; it returns the values of the low byte. STRING_TO_WORD does not work. and no WRITE_FILE_WORD_**

------------

bevanweiss:
That does sound tricky.
STRING_TO_BYTE is only going to support the ASCII character set I imagine.

I assume there is no STRING_TO_WORD function (I haven't looked).

I think you might be forced to do this in logic yourself.
If you know that your unicode characters are in a subset then you could just test for these and write the appropriate two bytes for them.
I'm not sure if Unicode may have Russian characters nicely in something like a high byte of 0x01, with changing low byte. That would be nice, since then you could just test for ASCII ( CHAR(STRING_TO_BYTE(X)) == X ), if so do
_WRITE_FILE_BYTE( 0x00)_
_WRITE_FILE_BYTE (STRING_TO_BYTE(X))_
.. otherwise you could do
_WRITE_FILE_BYTE( 0x01 )_
_WRITE_FILE_BYTE(STRING_TO_BYTE(X))_

You should also raise this as a feature request with your Schneider Tech Support contact.
It won't help you with 2015R2, but may help in the future.