Get length of a 3-D char array

    Hello,

    I'm currently trying to set-up a catalog of errors using 3-D arrays.

    The idea is to define bunch of errors on different levels (by levels - I mean Warning, info, errors). Here's an example:

    Code
    DECL CHAR C_msg[3,80,80] ; where plane 1: info/ plane 2: Warning / plane 3: errors

C_msg[1,1,]="(I01) Gripper Changed to "
C_msg[2,1,]="(A01) Could not change GRIPPER. Please put back the previous gripper "
C_msg[3,1,]="(E01) Error returned by the gripper - See device"

    The idea behind defining all the errors in one 3-D array is to keep the code nice and clean rather than defining bunch of 1-D array for each level of errors (at least, to my liking).

    I'm after that trying to build strings by adding values at for example the end of sentence and therefore display them using msgNotify().

    I first tried to simply write to C_msg[1,1,] using SWRITE command then display the string using msgNotify but an error is returned.

    Then I thought about copying the 2-D char array to a 1-D char array using a for loop to finally display the 1-D array using msgNotify():

    Code
    DEF copyString(C_array1[]:OUT, C_array2[,,]:IN, I_index1:IN, I_index2:IN)
   DECL CHAR C_array1[], C_array2[,,]
   DECL INT I_index1, I_index2, I_lenArray2, it
   I_lenArray2 = STRLEN(C_array2[I_index1,I_index2,])
   FOR it = 1 to I_lenArray2
      C_array1[it] = C_array2[I_index1,I_index2,it]
      msgNotify(C_array1[], "Test")
   ENDFOR
END

    When I set manually the for loop maximum value to be exactly the length of the string, it works all fine but if the value is one value above the exact length, an error is returned.

    So I tried STRLEN but it doesn't look like to be working with 2-D arrays. Any ideas (or maybe a better way to solve the problem)?

    Cheers,

    Zaid

    SkyeFire,

    Thank you for your answer.

    If I understood you correctly, everytime we've gone over the array limit, we catch and simply continue the program?

    So there's no actual straight forward as strlen to get the length of a 3-D array?

    I unfortunately don't have my laptop close by to check the msglib.

    Panic mode,

    Thank you for your answer.

    I actually don't see how would it be feasible to use a structure, could you please elaborate more?

    Cheers,

    Zaid

    well there are different ways including making your own string type.

    here is another approach

    Code
    STRUC my_message_t CHAR info[80], warn[80], error[80]


DECL my_message_t c_msg[80]
C_msg[1].Info[] = "(I01) Gripper Changed to "
C_msg[1].Warn[] = "(A01) Could not change GRIPPER. Please put back the previous gripper "
C_msg[1].Error[] = "(E01) Error returned by the gripper - See device"

    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

    Oh, very clean and intuitive as an approach. Thank you!

    However, I tried it and looks like WorkVisual doesn't like it.


    EDIT: . It works perfectly inside of a function but I however would like to declare it in $config.dat

    Cheers,

    Zaid

    Edited 2 times, last by zaidb (September 9, 2020 at 10:36 PM).

    dot operator that connects element with subelement only works in program

    so in DAT file you would declare entire array element without breaking it down:

    Code
    DECL my_message_t c_msg[80]
C_msg[1] = { Info[] "(I01) Gripper Changed to", Warn[] "(A01) Could not change GRIPPER. Please put back the previous gripper ", Error[]  "(E01) Error returned by the gripper - See device" }
C_msg[2] = { Info[] "info...", Warn[] "warn... ", Error[]  "error..." }
C_msg[3] = { Info[] "info...", Warn[] "warn... ", Error[]  "error..." }

etc.

    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

    in this case you would not need it. each array is 1D.

    Code
    I_lenArray1 = STRLEN(C_msg[1].Info[])
I_lenArray2 = STRLEN(C_msg[1].Warn[])
I_lenArray3 = STRLEN(C_msg[1].Error[])

    But if there was a 2D array, own loop and ON_ERROR_PROCEED would do the trick.

    in fact i was forced to replace many standard functions, including StrLen() which does not work even on 1D character arrays if they are a bit longer.

    This is just one of examples of things that are not even mentioned anywhere. I would REALLY like to see full description, range of each parameter, any limitation, default value etc of each function, variable etc. list of ALL messages with every POSSIBLE parameter. I keep encountering undocumented messages practically every day and no, they are nowhere to be found. And if StrLen() has limitation to only process strings of few hundred of characters, why not state so? I may want to use 32k long strings... or longer.


    Btw. I did bunch for projects for Honda and they want everything Mitsubishi. Detailed documentation is one thing i really learned to appreciate from working with Mitsubishi products (PLC, servos, whatever). Translation of the manuals may not be exactly the best but it is more than adequate. But... what really impressed me how VERY clean and consistent structure of everything is (file format, file version, references, troubleshooting etc.). Each manual TELLS you what the related manuals are, each function, parameter etc is FULLY documented (R/W, range, scope, validity, exceptions, execution time for each instruction etc.). One can literally build anything and know what to expect and what the performance will be - just by reading the manual. And manuals are named according to predefined format so one can have several versions of "same" manual in the same folder - no conflict. And downloading latest version will have unique file name so there is no risk of overwriting older ones, while one can instantly tell which version is the most recent. Germans could or would not ever do that - simplicity is not on their minds. :winking_face:

    Sadly...none of this is possible with KUKA. Although KUKA does it's best trying to keep things compatible, but development does not stop, features are changing and evolving at much faster pace (things change among products even within minor release). As a result files are not named consistently. Versions are not stated consistently. Variables are not clearly or fully documented... or not even mentioned.

    Number of major changes may be introduced even within minor software release.

    I have seen declarations move from one DAT file to another, or move DAT file to a different folder when migrating from something like 8.5.6 to 8.5.7. This should not happen since 8.5 (first two digits same) is a same major version and shall be compatible. All declarations (such as collision detection) should not move around. This leads to duplicates when merging projects for example. And of course it happens on a last robot on Friday at 4PM when everyone just wants to get out. :astonished_face:

    Or WoV changes file format when moving from something like WoV 4.0.4 to 4.0.5 or thereabouts. These are kinds of changes that should not happen until major version release, but they do happen...

    Same goes with names of HMI menu entries (was very frustrating when trying to give exact instruction over the phone with someone not speaking same language).

    I helped in another thread with braketest time and of course it is different on 8.3 and 8.5. but this IS fair game as that is different major version.

    Hence things like this are why I keep insisting on EXACT version of KSS, tech package etc when asking for help.

    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 from panic mode

    Btw. I did bunch for projects for Honda and they want everything Mitsubishi. Detailed documentation is one thing i really learned to appreciate from working with Mitsubishi products (PLC, servos, whatever). Translation of the manuals may not be exactly the best but it is more than adequate. But... what really impressed me how VERY clean and consistent structure of everything is (file format, file version, references, troubleshooting etc.). Each manual TELLS you what the related manuals are, each function, parameter etc is FULLY documented (R/W, range, scope, validity, exceptions, execution time for each instruction etc.). One can literally build anything and know what to expect and what the performance will be - just by reading the manual. And manuals are named according to predefined format so one can have several versions of "same" manual in the same folder - no conflict. And downloading latest version will have unique file name so there is no risk of overwriting older ones, while one can instantly tell which version is the most recent. Germans could or would not ever do that - simplicity is not on their minds.

    Well, if their products are good on top of that, then I would want everything Mitsubishi too. A lot of companies see documentation as only a checklist requirement or an afterthought. For any complex thing, documentation is part of the thing.

Advertising from our partners