09-05-2012 06:44 AM
The machine code is done in LV2009 on a WIN_7 platform. Queued State Machine architecture inside 50ms timed loop. Launches into a Main and once user makes a selection, launches one amoung some 40 sub-VIs and the main FP is removed. All well . Code working.
But there has been a random code-crash or application-freezing issue, when a File I/O operation is on. Inside the code there are various occassions where I open a CSV file and append result data to it. Finally after the whole test is over, the complete CSV file is sent to a central server for saving. And most times its "Error 1" which says that some input parameter in file path is invalid and also displays the full file path - of course there is no error as i can see and defenitley no disallowed characters. And since the file name is programmatically done, the possibility of such rogue characters is not possible. So that Error-1 is actually a wrong message in itself.
What I would like to know is : Is there any way that a File I/O operation can be made robust ? One idea that occurs to me is an added verification to see if the file path meets stiuplated rules. Apart from this are there any other methods ? And is it a good idea to keep writing data to HDD on the fly when the machine is going through its sequences ?- I have some CanOpen communications also in code. Would it be better to store all the test values on to a array or cluster variable and after the test completion, dump the whole thing on to a CSV file in the HDD ??
Thanks
09-05-2012 07:10 AM
09-06-2012 08:24 AM
I think I would recommend a top-level server /daemon / actor for your file I/O. When you start your program, start up the server. Communicate to / from it using queues. The underlying code should be a queue-based task handler. The server can open the file, write to the file, close the file, and copy the file to other locations. Since all writing is done at a single location, you can buffer data for more efficient writing or flush every write for safety, at your option. All operations on the file will occur in a single thread, even though the commands for the operations could come from multiple locations. This should make the operation fairly robust.
Note that the actor framework (included in LabVIEW 2012) makes this kind of thing fairly easy but will incur an extra data copy over a custom solution. In your case, this should not be an issue, since you seem to be dealing with fairly small data sets.
If you have further questions, let us know. Post code if you can.
09-07-2012 01:59 AM - edited 09-07-2012 02:04 AM
A top level server / daemon / actor ? I guess I can follow your concept but have no clue on how to go about implementing a top level server. A simple example would help me get started . Thanks.
And you are right in saying that my data to be written is not much - some 150 numbers of double precision values plus a few string values.
Posting code - well in this case its too large a code to post. But I can explain the structure if that helps :
So in the above scenario how do I bring in the top level daemon to streamline the HDD read / writes ??