why use CLR_IO_STAT Karel built-in?

DuhbCakes · April 11, 2015 at 9:50 PM

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.

Code

PROGRAM fileopentest
%NOLOCKGROUP


VAR
 STATUS, entry :INTEGER
 devicePath :STRING[64]
 inputFile :FILE


BEGIN


GET_VAR(entry,'*SYSTEM*','$DEVICE',devicePath,STATUS)   -- path was set to wrong location for this test MC:\IO.csv does not exist. file is saved at UD1:\IO.csv
-- FILE_LIST('IO.csv', n_skip, format, ary_nam, n_files, status)
devicePath = devicePath + '\IO.csv'


OPEN FILE inputFile ('RO',devicePath)
IF (IO_STATUS(inputFile) <> 0 ) THEN
 --	CLR_IO_STAT(inputFile)
  WRITE('open ', devicePath, ' failed',CR)
  WRITE(IO_STATUS(inputFile),CR)  -- returns 
  CLOSE FILE inputFile  -- sets IO_STATUS back to zero by default  
  devicePath = 'UD1:\IO.csv'  -- set path to correct location  
  OPEN FILE inputFile ('RO',devicePath)
  WRITE(devicePath, ' opened',CR)
  WRITE(IO_STATUS(inputFile),CR)
ELSE
  WRITE(devicePath, ' opened',CR) 		
ENDIF

END fileopentest

Display More

rf103 · April 15, 2015 at 11:15 AM

Quote from DuhbCakes

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.

DuhbCakes · April 15, 2015 at 7:18 PM

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?

rf103 · April 17, 2015 at 9:19 AM

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.

DuhbCakes · April 22, 2015 at 2:15 AM

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.

why use CLR_IO_STAT Karel built-in?

Advertising from our partners

How to see your Job Posting (search or recruit) here in Robot-Forum.com