is using write to text a good way to do this?

[dannyjhu]

I have main VI with a number of sub VI's for different testing methods.  I wanted to create an easy way to give the user an update as to the last test run without having to open data files.  I was playing around with using a simple write to text file and read from text file as a way to have a scratch file.  So when a section of code runs it would just write a few lines to the text file.  Then when the next section runs it over writes the text file with the updated text message and so on.  The main VI would have a read text file and update as the testing continued.  It seemed like an easy way to go back and add some information for the user.  Attached is a very simple VI as an example.  Are there any downsides i'm missing by doing this? 

Thanks for the help.

Danny

[RavensFan]

It can work.  Although the way you have it implemented in your example VI leads to a sort of race condition (is the data written to the file before or after it is read)?

The advantage of writing something to a file is that in the event the whole program or PC comes crashing down, you have a log file remaining you can look at later to see where it left off.

But beyond that, using a scratch file is a rather crude way of passing data between different parts of your application.  A more efficient way would be to use a queue or notifier to pass information between subVI's and the main VI.

[dannyjhu]

Ravens fan,  Thank you for the advice.  I understand that queue's or notifiers are a better way to do it.  The reason I was thinking about using the write to file was the very reason you pointed out about if the whole program or PC is turned off or crashes you have a file to read from to indicate the last operation.  At some point I would like to add a full log file of each operation preformed but I don't know how to do it, and will have to spend some time reading up on it.  This is a short term fix for now.  Thanks again for the help.

Danny

[Mark_Yedinak]

---

@dannyjhu wrote:

Ravens fan,  Thank you for the advice.  I understand that queue's or notifiers are a better way to do it.  The reason I was thinking about using the write to file was the very reason you pointed out about if the whole program or PC is turned off or crashes you have a file to read from to indicate the last operation.  At some point I would like to add a full log file of each operation preformed but I don't know how to do it, and will have to spend some time reading up on it.  This is a short term fix for now.  Thanks again for the help.

Danny

---

Then do both. The file is a good way to have a persisent status of what has happened and the queue/notifer is a better way to update the user. There is no hard and fast rule that says you can only do it one way. Chose the best solution for the task at hand.

We have develop an interprocess messaging system and log sytem that has the ability to effectively broadcast messgaes to many listerners in our system. As such, we do write things to file and update UI displays using different methods. We can even format the data differently. An approach like this may take a little more time up front however it is a general approach that can be reused over and over. Ultimately you will save development tim eover multiple projects.

[Aldo_A]

Hi Danny,

as Ravens Fan and Mike stated, there are various ways to log depending on the application and your own preference. I must note in your initial design, you may have a race condition where reading and writing might not be synchronized and lead to erroneous behavior. One solution I want to suggest is the use of semaphores to protect your critical section of your code (http://zone.ni.com/reference/en-XX/help/371361H-01/glang/semaphore_vis/). With semaphores, you can guarantee that your file is not being accessed when you are trying to read it by other processes. This is particularly helpful for scalability if you decide to add more processes which will write to the log file.