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

  • I've asked KUKA about the possibility to do this...

    They have told me to use CAPS LOCK to write the texts as it is not possible to use accents and special chars in char arrays...

    I have multiple declarations in a DAT file like:

    DECL GLOBAL CHAR sSMUserMessage[80]

    And In a SRC file I initialize them like:

    sSMUserMessage[] = "This is a text without any accent and it works well!"

    But in case I use any accent there:

    sSMUserMessage[] = "Presión"

    Here the "ó" kills the compiler which tells me there is an invalid character.

    Can anything be done here?

    I can't believe accents are not allowed...

    Of course everybody can relax... nobody will die for this but...

    PS: the file has been modified using OrangeEdit so the format should be fine...

    Thank you all!

  • Place your Ad here!
  • 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.

    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]

    , then run something like this in the SRC file:

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

    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.

  • In a much closer galaxy...

    Thank you very much Panic Mode!

    Time to make a small function to convert automatically strings to their correctly displayed ascii counterparts...

    Something like

    var := parse_string("mystringwithaccentseverywhere")

    As I'll execute that function for all the strings in the project only once, this will not have any impact into the robot capabilities.

    How nice would it be to get an answer like this from the official support department.

    Maybe it's an error in the translation of the manual... or me being picky about it, but "ó" exists in the ascii table therefore it should be possible to use it like I did... At least nothing in the Spanish manual suggests ascii characters are not welcome during the initialization of a char array/string.

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

    [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 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] :top:

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Quote

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

    Can't speak for the others too, in my case the question to the support department is done always after trying to make it work... Then the questions come after trying all I can imagine/think about.

    The answer from the KUKA tech support has been: "it can't be done, sorry, use capital letters... and a small laugh..." in Spain years ago there was a "non-written rule" that stated that capital letters didn't have to be accented, which nowadays is not right... today capitalized letters need accents too.

    This is not about having high expectations, during a phone call details flow easier than in a forum post... something like what you proposed (which is a good idea/workaround) has not been proposed by the support technician who has given an easy answer that doesn't solve the issue... I would be ashamed to show all the messages wrongly written given the GUI/HMI is capable to show all the characters in different tables (looks like UNICODE to me).

    You are right interfacing A and B without technical support should be a capacity anyone in this world should have...

    Yes, my fault here, not specifying the KSS et al... I guess that, after spending some time trying to understand what it was the problem (file encoding, checking CHAR array capacities in the manual (SOFTWARE KR C... Programación por el experto Release 4.1 -> page 33), using different editors, OrangeEdit, WorkVisual...) I was trying to get an answer fast, losing sight on the correctness or giving the most info to get a good answer... I guess all can be found guilty of this at some time (some more than others) :grinning_squinting_face:

    Regarding the error, in WorkVisual there is no error, everything seems OK. But in the SmartPad I can read "carácter indicado inválido" (which would translate roughly as "invalid character". The version of the KRC is 8.3.36, HMI / KS 8.3.8403 obviously in a KRC4.


    "I can't believe accents are not allowed...". This is conclusion without evaluation. Why believe and not test?

    I can’t believe it after testing it... I mean it surprises / deceive me that nowadays this could be happening.

    And I hope you were right too speaking about KUKA guys looking at those forums... and that they could /would like to address this kind of issues.

    And reading all what I've written I realize it is completely impossible to make a parser that modifies the letters to their ascii codes counterparts in the robot as the robot is not capable to read the special char...
    The only solution I can imagine is making a small program in Excel VBA or in VC++ or whatever language that could do it and make a string translator for KUKA... Again, something that nowadays should not happen. I should not need to do this... The problem is not the capacity of doing that translation engine... the problem is needing to spend time on this. With an extra ball when the manual misleads you telling you the ascii characters are allowed in arrays of chars...

    At the end... you are 100% right, details matter...

  • Hi Joan,

    I am facing the same problem because I am french and I need to display messages in french (see my post here…ters/msg123606/#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 !

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners