You're sort of answering your first question with your second question. In the first loop the Bytes at Port is meaningless, unless you are intending to use it to perform a read in there. However, since you're reading in the second loop (incorrectly, by the way - more on that later), then there's nothing in the buffer, so you'll get zero.
You can read in as many places as you want. Whether or not it makes sense to do is a different story. It depends on how the data is coming over the serial port. If the instrument you're talking to is sending data continuously, but "sneaks" in a response to a command between two messages, then you obviously don't want to be reading the response to the command in your second loop. The serial port is just one pipe. It's up to you to determine where the data belongs. Furthermore, you can't be guaranteed of getting all of the bytes at once, which means you might read, say, part of the "asynchronous" message, then get the rest in the next iteration as well as the responsed to a command you sent. As far as the Bytes At Port is concerned, it just sees a bunch of bytes. It doesn't know that, for example, the first 2 are the remainder of the asynchronous message, and the rest are the response to the command. Does the instrument not have something in the communication protocol to allow you to distinguish?
As promised, the way you're doing the read: You are setting up the configure VI to disable the termination character, yet you are wiring a termination character. Which is it? Do you want the read to stop at the termination character, or not? If you don't use a termination character, then you need to use Bytes At Port so you know how many bytes to read. You have that property node in the second loop, but you are not using it. Instead you are wiring a constant of 1000 to the VISA Read. This will only work if you have termination enabled. But you don't. See the problem?
