Author Topic: Status(2) behavior with extended filesystem  (Read 5629 times)

garysdickinson

  • Hero Member
  • Posts: 502
  • Old PLC Coder
    • View Profile
Status(2) behavior with extended filesystem
« on: July 01, 2016, 08:02:18 PM »
I use the extended file system as a method to update PLC settings via text files. The text files are uploaded to the  PLC via FTP. The PLC code checks for the existence of a new configuration file, periodically.  If a new file is found, the PLC code opens the file for read, extracts the new configuration data and then deletes the file.

The small problem is that it is difficult to tell if a file exists.  The filesystem documentation suggests that reading the value returned from the status(2) function will indicate if the command was successful.  A value of "1" indicates success.

PRINT #8 "<READ Z000.TXT>"   ' Attempt to open file
s = status(2)
[/color][/font]

The call to status(2) will return a 1, to indicate success, under more conditions that you might think. I get a value of 1 for all of the following:
  • File does not exist
  • File exists and contains no data
  • File exists and contains data
It is not possible to determine if a file exists by issuing the "<READ xxxx>" command. In fact I have found no way to determine if a file exists.  It is possible to determine the size of a file after you have "successfully" opened it with the "<READ xxxx>" command using the status(19) function.

Status(19) returns 0 for non-existent files.  Status(19), also, returns 0 if the file exists but hold no data.  For my purposes, an empty file is about as useless to me as a non-existent file.


PRINT #8 "<READ Z000.TXT>"   ' Attempt to open file for read

if status(2) <> 1
   ' File may be already open
   '
   PRINT #8 "</>"         ' Close  file
   return               '   and bail out
endif

if status(19) = 0
   ' File contains no data or it does not exist. You can't actually tell...
   '
   PRINT #8 "</>"         ' Close file
   return               '   and bail out
endif

' we got here because the file exists and contains data
'
' what follows is just test code to allow me to inspect the contents
' of small text files
'
for i = 1 to 26            ' write null strings to A$..Z$
   $$ = ""
next

' read at most 26 strings from the file and place then in A$..Z$
'
for i = 1 to 26
   $$ = INPUT$(8)
   if status(2) = 255
      exit      ' end of file reached,  break out of for loop
   endif
next

PRINT #8 "</>"      ' close file
[/color][/font]

Just some hints on the extended filesystem behavior.

Gary D*ickinson
« Last Edit: July 01, 2016, 08:18:41 PM by garysdickinson »

support

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3170
    • View Profile
    • Internet Programmable PLCs
Re:Status(2) behavior with extended filesystem
« Reply #1 on: July 01, 2016, 10:52:39 PM »
Thanks for the feedback. The simple file system on these PLCs are mainly designed for the PLC to write to these files and then the file can be uploaded to a server or downloaded by a client software.  

One way to detect if a file contains useful data would be to store a signature line on the first line of the file. That way your software can open the file and check for the signature. If it exists it means a new file has been uploaded and it can continue to read the useful data from line #2 onwards. Otherwise it will close the file and continue until the next scan of the data file.

Email: support@triplc.com
Tel: 1-877-TRI-PLCS