Are you sure that you are getting data in from your serial port? Put some probes in different parts of your serial reading loop to see if you are actually getting data out of your serial port, and whether the stop condition of that innermost while loop is being met. Since I don't have your device, I disabled that part of the code and replaced it with dummy data. The data seemed to be logged to the file okay. How much data is your device sending, and how fast? What is your baud rate? You have a 2 second timeout, and your VISA read is waiting for 4096 bytes. That sounds an awful lot like a full buffer. And at 9600 baud (an assumption on my part since I don't know your serial port settings), 4096 bytes are going to take over 4 seconds assuming they are all sent continuously (longer if there are any gaps between bytes due to the way the device sends data.) You would certainly get timeout errors in that case.
Now let's talk about all the other problems with your code.
- Why do you have 3 stop buttons to stop the different loops. They are scattered all over the front panel. With the mechanical actions all being latched, you run the risk that one is read, returns to false, but the loop gets restarted because your outermost while loop didn't stop, unless you get lucky and hit all the stop buttons at just the right time in the right order. You are really going to need to change your architecture in a way that allows one stop button to stop everything.
- Your start logging and stop logging buttons are unintuitive. The buttons you used are the kind that look like the should go in and hold, or be out and hold to show whether the button is on or off. Since you have them for latch action. You hit start logging, but it just blinks really quick. Nothing else indicates you are now in logging mode. If you hit start again, it just holds in because it hasn't been read again. The innermost while loop is running and logging, but nothing indicates that, or tells you that you need to hit the stop logging button to get out. A single button called log that is set for switch when released action allows you to push in to log, push out to stop logging, and will have the indicator to show you that it is logging.
- Don't have while loops that do nothing as fast as possible. Put a wait statement in there. Your logging loop when logging has not been started runs as fast as possible hogging all the CPU resources making it difficult to do further debugging on your VI.
- Why did you disable/remove the abort button on your toolbar? You should only do that once your program is working satisfactorily. Because of the fast loop listed above, and the lack of the abort button, I had a hard time switching to your block diagram and no way to figure out how to stop your VI without killing the whole process using task manager.
- Using a local variable to pass the data between loops can lead to a race condition. If the loops get a bit out of synch where one runs twice to the other one's one iteration, you could wind up recording the same piece of data twice, or lose an entire piece of data.
- As I said you really need a new architecture. When you acquire data in one loop and log to file in another, you should be using a producer/consumer architecture using a queue to pass the data. This will prevent the duplicated or lost data caused by the local variable.
- Also, try to clean up your code so that wiring runs straighter, doesn't run backwards, and doesn't take up so much screen real estate. When I ran diagram cleanup (a feature added in LV 8.6 I believe), it cleaned it up automatically and reduced the size to about 2 screens instead of the about 4 it is now.
Search the forums for producer/consumer and also got to File / New ... and look for the design pattern called Producer/Consumer (Data)
EDIT: Wow, I was taking so long to compile my list, Smerc got in a pretty good list himself, including some things I didn't notice. But I think you can safely combine our two lists and work through them to come up with a better program.
