Using an array of filenames for CWRITE

    KSS 8.6, KRC4

    Hello everyone,


    Attempting to read from a file with krl_fgets while referencing an array of file names.
    The issue I'm having is even calling to open the file:
      CWRITE($FCT_CALL, STAT, MODE, "krl_fopen", _FILES[FileNumber, ], "r", HANDLE)

    Where _FILES is a char array of [# x 256], each row containing a file name like "F1.TXT".

    Is this illegal?? I've also tried populating a temp variable like _File_i which takes _FILES[FileNumber, ]... To no avail.

    Code
    _FILE[] = _FILES[FileNumber, ]

CWRITE($FCT_CALL, STAT, MODE, "krl_fopen", _FILE[], "r", HANDLE)
  • Go to Best Answer

    yeah... that is not valid. file name is a string. you cannot assign an array of strings (en entire dimension) to a single string. this is no different than trying to assign an array of integers to a single INT variable.

    myInt=I[] ; this is not valid, left side is a single INT variable, right side is an array of INT.
    myInt=I[3]; this works, both sides refer to a single INT.

    and there is another issue - KRL does not have STRING type so you still cannot assign string value using simple assignment (equal sign).

    Quote from RoboMan3000
    Code
    _FILE[] = _FILES[FileNumber,3]; this works with other types but both with STRING since this is NOT a string, it is a CHAR array

    so, if you need to transfer value of a SINGLE string to another string use either SWRITE or... use loop to transfer individual characters. perhaps something like

    DECL INT n,ch

    for n=1 to 24
    _FILE[n]=0
    ON_ERROR_PROCEED
    _FILE[n]=_FILES[FileNumber,3]
    endfor

    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

    so, if you need to transfer value of a SINGLE string to another string use either SWRITE or... use loop to transfer individual characters. perhaps something like

    Thanks for the advice panic mode.

    Seems as though even SWRITE will not work - as the format CWRITE needs is a string and there is literally no way to MAKE a string from character arrays..?

    When I ask the pendant to show me the first column of the file name matrix during program operation, it returns "F1.TXT", not "F", "1", ".", "T", "X", "T"

    I've gotten the error as well that there is a formatting error, that one of the characters in the string is ", which I need in there to declare that it's a string...(below is how I declare the character array in the DAT file)

    Code
    DECL GLOBAL CHAR _FILES [5, 256]
_FILES[1, ] = "F1.TXT" 
_FILES[2, ] = "F2.TXT" 
_FILES[3, ] = "F3.TXT" 
_FILES[4, ] = "F4.TXT" 
_FILES[5, ] = "F5.TXT"

    And in my SRC file:

    Code
    CWRITE($FCT_CALL, STAT, MODE, "krl_fopen", _FILES[ (indexing variable here), ], "r", HANDLE)


    Honestly just confused on what in tarnation kuka is going for here. Even using SWRITE or loop population, it will still be a CHAR array, since I cannot declare a string.

    KRL uses CHAR arrays as ersatz strings. Which usually works. For example, I had this in a .DAT file:

    Code
    CONST CHAR chRFMasterFile[200]
chRFMasterFile[]="RFMaster.txt"

    And in the SRC:

    Code
    FileOpen (chRFMasterFile[], _chMode[], _nFileHandle)

    FileOpen is just my library subrouting that call the KRL_FOPEN command:

    Code
    GLOBAL DEF FileOpen(FI_chFileName[] :IN, FI_chMode[] :IN, FO_nFileHandle :OUT, FI_BufferMode :IN)

CWRITE($FCT_CALL, _OPSTATE, _MODE, "krl_fopen", FI_chFileName[], FI_chMode[], FO_nFileHandle, FI_BufferMode)

    Your problem is that you want to create an array of strings, which isn't possible to do directly in KRL. I don't think you can work around it using 2D arrays, at least not without resorting to loops with single character copying. What I've done in the past is to create a STRUC, which includes a CHAR array "string" variable, then create an array of the STRUC type.

    Code
    GLOBAL STRUC ROBOT_DATA CHAR Name[24],V7KName[24],INT Context,RobotTypeEnum Type,BOOL HasToolchanger,Reg_Coop RegistrationCoOp,BOOL ResidualCorrection,GuidanceTypes GuidanceOption
DECL GLOBAL ROBOT_DATA Robot[10]
Robot[1]={Name[] "rnd-kr210-642486",V7KName[] "Cell1-Spirit",Context 1,Type #V7OML,HasToolchanger TRUE,RegistrationCoOp #Master,ResidualCorrection TRUE}
Robot[2]={Name[] "xxx",V7KName[] "Cell1-Spirit",Context 2,Type #V7IML,HasToolchanger FALSE,RegistrationCoOp #Slave,ResidualCorrection TRUE}
Robot[3]={Name[] "xxx",V7KName[] "Cell2-Spirit",Context 1,Type #V7OML,HasToolchanger TRUE,RegistrationCoOp #Master,ResidualCorrection TRUE}
Robot[4]={Name[] "xxx",V7KName[] "Cell2-Spirit",Context 2,Type #V7IML,HasToolchanger FALSE,RegistrationCoOp #Slave,ResidualCorrection TRUE}
Robot[5]={Name[] "xxx",V7KName[] "Cell3-Spirit",Context 1,Type #V7OML,HasToolchanger TRUE,RegistrationCoOp #Master,ResidualCorrection TRUE}
Robot[6]={Name[] "xxx",V7KName[] "Cell3-Spirit",Context 2,Type #V7IML,HasToolchanger FALSE,RegistrationCoOp #Slave,ResidualCorrection TRUE}
Robot[7]={Name[] "xxx",V7KName[] "Cell4-Spirit",Context 1,Type #V7OML,HasToolchanger TRUE,RegistrationCoOp #Master,ResidualCorrection TRUE}
Robot[8]={Name[] "xxx",V7KName[] "Cell4-Spirit",Context 2,Type #V7IML,HasToolchanger FALSE,RegistrationCoOp #Slave,ResidualCorrection TRUE}

    It's a bit kludgy, but I can confirm it works. Just pass something like Robot[7].V7KName[] to FOPEN (those empty braces are vital, it's how you tell KRL you're passing the entire array), and FOPEN will try to open the file named Cell4-Spirit.

    Here's an example of a Logging function that uses SWRITE to create the file names on the fly. It's using date/time values instead of an array, but the same SWRITE principle will work:

    Thank you SkyeFire - I think that works!! Do you work for Kuka or something??


    When I get to the CWRITE - "krl_fgets" process, I get an error message number -11, "At least one function parameters have an invalid value."

    I initialize my buffer Buff[256] to be all zeros, and Offset = 0 and READ = 0, here is the line

    CWRITE($FCT_CALL, STAT, MODE, "krl_fgets", HANDLE, Buff[], 256, READ)

    Is there a secret anomaly besides not feeding fgets an empty buffer?

    • Best Answer
    Quote from RoboMan3000

    Thank you SkyeFire - I think that works!! Do you work for Kuka or something??

    No, I just did a lot of KRL programming for about 20 years.

    Quote from RoboMan3000

    When I get to the CWRITE - "krl_fgets" process, I get an error message number -11, "At least one function parameters have an invalid value."

    Hm... it's been a long time. The module I've attached is the most advanced one using FGETS I ever wrote. I do recall that FGETS has some fiddly requirements the docs don't explain very well.

    Quote from RoboMan3000

    I initialize my buffer Buff[256] to be all zeros, and Offset = 0 and READ = 0, here is the line

    Hmm... I looked at my old module, and I always did an STRCLEAR on the buffer, then set _chBuffer[1]="x" before calling FGETS. I vaguely recall a long, painful learning process that lead to that. And I think setting all the buffer to be 0s actually doesn't work, it needs to be some valie alphanumeric char:

    Code
          WAIT FOR STRCLEAR (_chBuffer[])
      _chBuffer[1] = "x"

      CWRITE ($FCT_CALL, _FgetsState, _Mode, "krl_fgets", _nFileHandle, _chBuffer[], _nFGetsLength, _nCharsRead)
      CWRITE ($FCT_CALL, _EOFState, _Mode, "krl_feof", _nFileHandle, _bEOF)


    Long old thread here: Re: CWRITE

    Quote from MOM

    in C you have zero terminated strings.

    Therefore initialising a buffer[256] with zeros is actually creating a buffer with 256 empty strings.

    Yeah, the whole string-handling thing in KRL is a bit... So, here's the thing. KRL internally handles strings as CHAR arrays, and if you use STRCLEAR, it just (IIRC) puts an EOL terminator character into Array[1]. The rest of the array is still populated with the old data, but KRL string functions can't "see" it.

    But then, around KSS 5.4(?), KUKA started adding additional functions like EKX (EthernetKRLXML), which for the first time gave KRCs the ability to send/receive data through TCP/IP ports (weird that it took them so long, they were WAY behind the competition). Then in KSS 8, they added the KRL_F... file functions.

    The thing is, EXK and the File functions work by passing calls to the C underpinnings of VxWorks (hence CWrite), below the KSS layer. And at that level, you're suddenly working with C-type strings, instead of KRL-type 'strings'. It's a bit of a mess, caused by decades of adding features to a robot OS that was first built in the late 1980s.

    That's why some of the example code you'd seen in this thread seem to jump through some weird-looking hoops when moving data between KRL 'strings' and the KRL_F... functions. There's reasons for all of it. And I know I can't keep all of it memorized, which is why I built all those library functions so I wouldn't have to.

    Thanks everyone for your input.

    The process is up and running, and I pinpointed the last issue yesterday after switching to STRUC methodology as SkyeFire graciously advised.

    Let's discuss fgets:

    krl_fgets(INT Handle, CHAR[] Buffer name, INT Buffer size , INT Read<, CHAR Separator>)

    What Kuka doesn't inform the user in their manuals not only is that the buffer must be initialized with a string character like x, is that the input variable INT buffer size must be one less than the length of the actual buffer character list. So, the length of my Buff[] was 256, I must declare 255.

    This is something you also do in your program you shared SkyeFire. After that, things work!
    Exciting to be able to bypass file size limitations like this. Thanks guys!

    Quote from MOM

    This is not correct:
    In C an array starts with index 0: therefore array[0] .. array[255]
    => number of elements: 1 to 255 + 1 Byte for index 0: total element =256!

    MOM, thanks for the info - nowhere in the manual is this denoted (prove me wrong), so not sure how I was supposed to know that. I've never coded in C, and didn't know C meant C the coding language.
    Skill issue?

    Regardless of whether you think I'm wrong or right - what I described works! :winking_face_with_tongue:

    Hey guys,
    So, at this point I've made up a prototype of what we'd be using this program for in production.
    Something comes up while testing, which did not show in the earlier tests with this program type.

    When I run a path, I get the errors:

    Interrupt priority inadmissable 1 (Taskname tZYK_HP)
    Runtime error on activating trigger declared in testfile@167

    This happens on the last part of the movement execution from this slice of code:

    Code
        FOR INDEX = 1 TO DATAFILE[FILENUM].COUNT

      LIN FPOS[INDEX] C_DIS
      TRIGGER WHEN PATH = {2} ONSTART DELAY=0 DO OP_LOG( INDEX ) PRIO=1


    ENDFOR
    WAIT SEC 1

    I've tried using prio 2, 5, 10, all the same error.
    In testing previously, this worked without any issue.
    I've got the WAIT SEC in there to break the ARP.

    Interestingly, if I go to the variable view and watch INDEX, it seems to incriment to the value of (COUNT+1)...........

    I've tried even going and hard-coding the value I want in there, putting an IF statement in the loop to watch if the value of INDEX exceeds the COUNT variable, all to no avail.

    If anyone has ever encountered this before, please let me know.


    KSS 8.6, KRC4

    Quote from RoboMan3000

    Interrupt priority inadmissable 1 (Taskname tZYK_HP)
    Runtime error on activating trigger declared in testfile@167

    Huh! That's a new one on me. And this only happens on the final motion of the FOR loop?

    Quote from RoboMan3000

    I've tried using prio 2, 5, 10, all the same error.
    In testing previously, this worked without any issue.
    I've got the WAIT SEC in there to break the ARP.

    Even stranger. That code looks okay to me. And using the WAIT to break the ARP is a wise move.

    Quote from RoboMan3000

    Interestingly, if I go to the variable view and watch INDEX, it seems to incriment to the value of (COUNT+1)...........

    Ah, now that's normal. A FOR loop always exits with the "counter" variable at Max+1. Think of a FOR loop as looking like this internally:

    Code
    LoopStart:
; do stuff
Counter = Counter +1
IF Counter <= CounterLimit, THEN
  GOTO LoopStart
ENDIF

    So I don't think the Index variable is causing your issue, here. If it were, you should have gotten a out-of-bounds error from the LIN command.

    Is the above code inside a Interrupt routine? I think in interrupts only simple triggers without up call are allowed. Does it work without the trigger? Does it work with a trigger without up call?

    Zyk_hp is among other things the task inside the VxWorks realtime kernel that handles trigger signals.

    Thanks for the advice, guys.

    Using Prio = -1 fixed this. I haven't gotten the chance to really analyze data from the process using -1 as the prio, but I suspect lowering the priority will increase the "lag" in taking data into the logging sequence?

    From the early tests I did, there was a systemic bias in the measurement points, due to the computation cycle I'd guess. The measurements of position would always be a few fractions of a millimeter after the robot passed the midpoint of its move.

    This is fine and can likely be optimized if ever necessary....

    I suspect the problem here (reason we need to use prio = -1) is something to do with a couple functional (but mostly unused) tech packages on the new robot I've been experimenting on. For the tools we use.
    With all the extra production we've needed to rewire the connectors of all our shielded ethernet wires with connectors that have dedicated ground crimping! Awesome and annoying as hell at the same time lol...

    both triggers and interrupts are just forms of interrupt and both are accessing the same resources. therefore programmer need to make sure that there are no conflicts. when multiple interrupts are triggered at the same time, they are queued and highest priority is processed first, then next etc. subroutines called by interrupts need to be as short and as quick to execute as possible in order to not hog resources.

    there are 128 interrupt levels or priorities. the smaller the number, the higher the priority.there is no level -1. this is special value for automatic assignment of priority level for trigger instructions.

    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

Advertising from our partners