why use CLR_IO_STAT Karel built-in?

  • IO_STATUS(file_id)
    Return an INTEGER value indicating the success or type of failure of the last operation on the file argument


    CLR_IO_STATUS(file_id)
    Clear the results of the last operation on the file argument


    in all of the program examples i find in the Karel manual whenever IO_STATUS is used it is immediately followed by CLR_IO_STATUS. This does not seem to be needed. i put together a quick test and it read out as follows.


    open MC:\IO.csv failed
    2014
    UD1:\IO.csv opened
    0


    To me this means that the CLR_IO_STATUS is not needed as the value will be replaced by the next operation that uses it. the CLOSE FILE built in always sets it to zero. my favorite part is that 2014 is not a listed code in the table. i would expect either 12327 Open file failed or 12328 file is not opened.



  • my favorite part is that 2014 is not a listed code in the table. i would expect either 12327 Open file failed or 12328 file is not opened.


    2-014 is FILE-014: File not found


    The Karel manual very rarely lists possible errors in the function descriptions, possibly because that would make the manual four times its current size.

  • you are correct sir. i should have known better. the lack of leading zeros threw me off. I should have used POST_ERR(IO_STATUS(inputFile),'',0,0) then i would see the dictionary entry posted on the Teach Pendent. That does however reinforce my point. why even use the CLR_IO_STATUS?

  • If I remember correctly there are some IO operations that do not necessarily reset / override the IO_STATUS of a previous operation. An example would be a READ on a file descriptor that has been configured with a timeout (SET_FILE_ATR(fd, ATR_TIMEOUT, ..)). If you don't clear the status prior to calling READ, a call to IO_STATUS() will return whatever it was before the READ in some cases. That makes checking it essentially useless, as you cannot be certain that you are looking at the result of the last READ.


    Besides that, it is good practice to reset things to a known state before attempting any new operations, so you can safely reason about the results.

  • confirmed. Fanuc got back to me and it is as you say. interestingly enough the CLOSE FILE does not update the status with a fault even if it generates one. I agree that it is good practice, and will continue to use it. I just like to know what exactly i am asking the robot to do. call it a programmer's quirk.

Advertising from our partners