FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

Performance blocker on cFP-2020: file-I/O! How to improve?

Hi all,

after resolving my serial-communication problems I still have a performance problem. The code is way too slow which causes e.g. the ftp-server on the fieldpoint to not respond anymore to requests from my PC. I always get timeouts. I also frequently get loop-finished-late events within my two state-machines. I have now used the timing and performance monitor to sse which vi is taking so much time. The result: A file-I/O vi that writes data and log-entries into three different log-files. With a former verion I simply used one vi that appends a string to an existing file. However, since this function disappeared with LV8.2 I had to rewrite the code to use the following sequence of LV-functions:
- file open
- set pointer to the end
- write string
- file close
My vi shich calls this sequence is horribly slow - execution time per run is about 200ms and the top of the list in the performance monitor. Are there any suggestions on how to improve this code? I simply want to add a string to the end of the log-file......

The vi is attached. There are two features in the code which are not self-explanatory: The first sub-vi generates a new file if is used for longer than a preset time (15 minutes in my case). So the create-time of the file is stored in the filename and whenever the current time exceeds create-time plus 15 min. A new file name is created. For simplicity, the name is stored only for the first of the three log-files. The other two are created by string operations from the first filename. Second, whenever a file is "created", that means is does not exist yet, a data-header is written to the file, before data is appended.

Can you see simple improvements here that will accelerate this code? Maybe open the file only once and then append data subsequently and only close it when a new file is created? But I do not need all three files all the times, there may be situations where only one file is needed, and the others need not be created at all.

Thanks,

Olaf
0 Kudos
Message 1 of 5
(5,328 Views)
I think moving the open file, move to end of file, and close file out of the loop would certainly help.  These functions could be associated with or built into your "determine new file" VI.  Since the file paths get passed into the loops, you could pass them through with shift registers so that you can close them after the loops end.
 
One other thing to look at is your initialize array and insert into array functions.  I believe insert into array is one of the costlier functions.  Build array would be better.  And initializing a much larger array and using replace array subset is better yet.  But if you wind up with more elements than you had originally initialized for, you will have to use build array to enlarge it.   I would recommend searching the Labview forum for insert into array, build array, and replace array subset for threads that do a better job explaining the differences and advantages of each.
0 Kudos
Message 2 of 5
(5,322 Views)


@Ravens Fan wrote:
I think moving the open file, move to end of file, and close file out of the loop would certainly help.  These functions could be associated with or built into your "determine new file" VI.  Since the file paths get passed into the loops, you could pass them through with shift registers so that you can close them after the loops end.
 
One other thing to look at is your initialize array and insert into array functions.  I believe insert into array is one of the costlier functions.  Build array would be better.  And initializing a much larger array and using replace array subset is better yet.  But if you wind up with more elements than you had originally initialized for, you will have to use build array to enlarge it.   I would recommend searching the Labview forum for insert into array, build array, and replace array subset for threads that do a better job explaining the differences and advantages of each.


Thanks, that improved the performance of this vi by about two orders of magnitude. The application is now much more stable.
However, I cannot connect to the cFP-2020 anymore by ftp. I even swithed the fieldpoint to boot without vi.
To be specific, I can access the cFP and cd into all directories except for the directory with the data. I assume that there is a large
amount of files in it now, but used to work before even with lots of files. The only thing that might be not so nice is that there is a space
in the folder name, but that has been like that for years now and used to work.
Is there any reason (corrupted file or something like that) that can cause the ftp to fail on this specific directory?

Thanks,

Olaf

...at least I am very close now to a satisfying and running system.... 🙂
0 Kudos
Message 3 of 5
(5,314 Views)
I don't know the answer to that.  But the file I/O functions still work on that directory?  Try a small VI to see if you can copy them to another directory and FTP to that.  And use some file delete functions to empty out that directory and try FTP'ing to it again.  That will show whether the issue is related to the files contained within it.
0 Kudos
Message 4 of 5
(5,312 Views)


@Ravens Fan wrote:
I don't know the answer to that.  But the file I/O functions still work on that directory?  Try a small VI to see if you can copy them to another directory and FTP to that.  And use some file delete functions to empty out that directory and try FTP'ing to it again.  That will show whether the issue is related to the files contained within it.


I could acces the files in safe mode. Once I got them all (around 500 files) moved over to the pc, everything worked again. Also newly created files were visible via ftp. So it was pretty much the amount of files that was the problem.

Cheers,

Olaf
0 Kudos
Message 5 of 5
(5,303 Views)