The reason you are not getting the last element of the queue (at least not until you restart the VI) is that you have your auto-indexing tunnel that is accumulating all the data to send to the Write to SS File function wired to the shift register. So that last piece of data from the queue gets put into the shift register, but doesn't get put into the 2-D array by the auto-indexing tunnel until the next iteration of the loop. When you rerun the VI, because the shift register is uninitialized, it is already there and becomes the first point of your next run of data.
Why did you put the shift register in? Just eliminate it and just use the auto-indexing tunnel.
I don't know what you really want to do with the 2nd loop to say whether a notifier is correct or not. But if you don't want to lose data in the other loop, then what you should use is a second queue, and have your producer loop enqueue the data in both queues, one queue for each consumer loop.
As for seeing zero elements in the queue, the way your code is setup, the queue will nearly always be empty because the dequeue function will be ready to pull the element out immediately after the enqueue function puts it in. Unless you have your producer loop running significantly faster than your consumer loop, you won't see a build up of elements. (Try putting a wait longer than 100 msec in your consumer loop. Then you will see elements build up in the queue.)
I'm not sure why you are putting the Write to Spreadsheet File function after the loop. A normal usage for queues in a producer/consumer architecture is to pass the data to a separate loop that contains the file writing functions. That way it can operate at its own pace, but write out the data, and make sure you don't lose it. As you have it now, if your code runs a long time, you could run out of memory when the array at the auto-indexing tunnel gets too large. And if your application crashes before you end it with your stop button, then all data is lost because you had not written it out to the file.
