One possible problem.
You are enqueing a waveform in your top loop, but dequeuing from two different loops: your middle logging loop and your bottom water bath control loop. An item can only be dequeued in one location or another. So if one loop dequeues an item first, that item is now gone off the queue and the other location has nothing to work on until something else gets enqueued. Think of a queue like an inbox. One or more people put in papers with work instructions. If you and I are both sharing the same inbox, whoever grabs the next paper first gets to work on it, the other person doesn't see it. If there is nothing else in that inbox, the other person will be just waiting and twiddling their thumbs until something else comes along for them to grab.
The second gotcha could be in your middle loop. Because you have two dequeue functions, one for each queue, the stuff in the no error case won't get to execute until something is pulled out of each queue. So if that next item in the waveform queue was stolen by the lower loop, the middle loop will be waiting longer until another waveform gets enqueued. In the meantime, it would get enqeued at the same time as valve cluster in the top array. So the valve cluster queue will keep growing since it will essentially have two items getting enqueue for each waveform the middle loop dequeues, because the lower loop is stealing the other half of the waveforms.
Another question I have is why you are using a lossy enqueue function? I don't know whether you would actually lose items in the queue because you've set up the queues to be unlimited in size. But lossy enqueue is designed for situations where you have a limited queue size and you don't care whether some items are thrown out or overwritten. In your case (especially for valve control) you want all queue items to get through. So use the regular enqueue function.
1. Queues are meant for 1 to 1 or many to 1 communication. If you want several places to get the same data, create another queue and enqueue the data once in each queue.
2. A loop that has two dequeues will wait until both queues have an item in them to take. If items are enqueued in each queue at different rates (or in this case, one queue loses items to another dequeue function), the loop will wait when you don't want it to. And a queue will likely keep growing and falling behind.
Yes you can enqueue both sets of data in a single queue. Just rebuild your queue definition cluster so that it contains a valve cluster and a waveform. You'll make the changes at the obtain queue function and also the enqueue functions. And of course the dequeue function since you will need to unbundle them from the common cluster.
A couple other things. I still think it would be easier to use a valve array rather than a valve cluster. It would need less bundle and unbundling of a cluster. A 1-D array of booleans represents the state of all the valves. Expand that to a 2-D array where the second dimension handles the changes in time. With a cluster, don't unbundle than build array in the middle loop, just use a cluster to Array function like you used in the upper loop. Also, You have a cluster/array of 13 valves, but you have only 12 filenames defined for your data files.
First, your images you attached to not show. They are located on your hard drive which I don't have access to. This is kind of strange because I thought the recent changes to the forum would make it very unlikely to embed images that were on someone's hard drive.
Second, Your file name array has gotten worse. You still only have 12 filenames defined even though you have 13 booleans in the array. But now the final 3 aren't a complete file path, they just give a path to the subdirectory. I assume this is the source of your error, but I'm not clear from your description exactly where it is occurring.
The good news is that the handling of the enqueues and dequeues and the data being passed looks a lot more logical.
The quickest way to get it going is to put the file dialog at the beginning of your program. Run the error wire out of it so that it just branches and goes and hits all of your loops. That way the loops can't run until the file dialog VI has completed.
A more robust application would have the user being asked for the file path as one of the initial states of a statement machine and the other loops not commanded to start until that state has completed.
Okay, this works. However, I'm not sure how to add my time stamp information to the Write to Measurement File. Right now, it only writes an elapsed time that is not correct. The current program only takes and writes samples for ten seconds and the elapsed time on the first file goes from 0 to 10, but the next file starts at 0 too. I have a For loop that gets the time stamp information for all of the samples, but I don't know how to connect it back with the waveform data into the Express VI.
I know how to do it using Write Characters to File, but LabVIEW doesn't support that function anymore. It tells me to use Write to Text File and use the Set File Position so that the data gets appended to the files, but I don't know how to connect those so that the information is written to the twelve different files. How can I correct this?
That is one of the reasons why I don't like the Express VI for writing to a measurement file. It gives a time stamp and a lot of information at the top, but the raw data below just goes from zero up. If you import the text data into Excel, you have to do some post processing to get a real time associated with each data point.
I would recommend you build your own array with a time value (double representation) for each data point. Format the data into strings and use the lower level file I/O to write that data out.