Accents in char arrays... Can this be done?

In a galaxy far far away someone created character set. then everyone created their own version. Then US government stepped in and told them to cooperate or else. Then ASCII was created and finally machines from company A finally could understand data sent from machine created by company B.

Then rest of the world decided to get on the same ride and language specific code pages were created but this created mess since the table could still only hold 256 characters (each character is represented on ONE byte).

Then UNICODE was created which uses two bytes per character. Finally one set can represent all alphabets. This is great for word processing, browsing internet etc but it is not exactly common in places where resources are lean or performance is expected.

So...
1. Read manuals, they clearly state that CHAR variable is meant to hold ASCII characters, and not UNICODE.
2. Get ASCII table and find character you are after (or similar one).

The user interface imposes some speed bumps here. I haven't done a full test, but I don't think the KRL can "natively" handle ASCII characters outside of the range 32-126. So the only way to assign characters outside the range (0-32 or 127-256) only works by directly assigning an INT ASCII value to a particular, single member of the CHAR array, as Panic showed.

You can see what I'm talking about if you declare a CHAR array (string) in a .DAT file and give it an initial value, like

DECL CHAR TestString[512]
TestString[]="xxx"

, then run something like this in the SRC file:

DECL INT Index
Index = 1
REPEAT
  TestString[Index] = Index
  Index = Index + 1
  TestString[Index] = ","
  Index = Index + 1
UNTIL (Index >= 512)
ENDFOR

Then open the .DAT file. What you'll see is that any "unprintable" ASCII character is represented by a KRL-styled Hex Integer value embedded in the string. So after running that FOR loop, the .DAT entry will look something like:

TestString[] = "'H00','H01','H02'

and so on. "Printable" ASCII characters that KRL can handle "normally" will be shown as normal characters.

[size=2]You are welcome,[/size]

Quote from JoanM

[size=2]How nice would it be to get an answer like this from the official support department.[/size]

[size=2]Thank you. I cannot speak about support in Spain but ... it is fair to say that this goes both ways. [/size]
[size=2]It is easy to have high expectations from 'others' (support for example). But how many people have asked themselves what they could do - themselves?[/size]

[size=2]In my opinion anyone doing ANY work should be qualified to do that work. Most people asking for help on this forum are not qualified to get near an industrial robot. I just wonder what stops them from deciding to mess with something else they are not familiar with, or try to become surgeons, pilots, hostage negotiators, civil engineers etc. [/size]

[size=2]System integrators should be knowledgeable about interfacing thing A and thing B. Interfacing is at the heart of being an integrator. Interface can be hardware (such as I/O) or software (such as data conversion). Any integrator should be able to analyze and convert data any way needed. This includes making little program to test particular behavior - WITHOUT dependence on external support. [/size]

[size=2]As evident from my posts in this forum, my constant gripe is that most people are not communicating correctly or accurately or using correct channels. Everyone may think "that's not me" but ...no offense anyone... - it IS almost everyone. [/size]

[size=2]For example just look at this very topic:[/size]

[size=2]1. You never mentioned system (no KSS version or at least controller type). [/size]
[size=2]2. You mentioned some manual and potential translation issue but no details (manual name, version, page). Plenty of Kuka employees are reading this. How can they improve if complaints are not pointing specific issue?[/size]
[size=2]3. you did mention making changes in OrangeEdit but - there are NO details on specific error. your post does not quite clear things up:[/size]

[size=2] "Here the "ó" kills the compiler which tells me there is an invalid character.". What does this mean? what is the EXACT message displayed? [/size]

[size=2] "I can't believe accents are not allowed...". This is conclusion without evaluation. Why believe and not test?[/size]

[size=2] "They have told me to use CAPS LOCK to write the texts". Can you be specific? This only makes typed letters capitalized. [/size]

[size=2]My point is that details matter and the best way to deal with issues is to be specific. [/size]

Hi Joan,

I am facing the same problem because I am french and I need to display messages in french (see my post here https://www.robot-forum.com/robotforum/kuk…3606/#msg123606).

I finally managed to leverage the message database that you can find in KRC/DATA. I now know how to create a new database, register it in the windows registry and use it to display your own messages from Set_Msg / SetDlg in a KRL program in the language of the KRC.

This solution works only for messages. And because I am working on a KRC2 and don't have access to a KRC4 I don't know if this solution is reproductible on a KRC4. Apparently messages are now stored in a xml file but the the access layer is probably not different.

In my opinion, If you want to localize your messages this is the only serious solution you have. Or you'd better drop the idea to display messages with accented char.

If you want to test this solution, I can set up a small (KRC2) tutorial. You'll have to dig in your self to see I you can do that on your KRC4.
Let me know if you are interested !