Well I can't view the .vi files at the moment as I don't have LabVIEW at home, but you do know when you connect an array to a for loop that when it automatically makes the bracketed box instead of the solid box that it is auto-indexing unless you change it back. It seems you go the part about putting the code that you want to repeat for each reading inside the loop, but I just figured I'd point this as as in a case such as this if you want to run the loop once for each element in the array you don't have to wire anything to N as it will automatically execute until it runs out of elements in the array with autoindexing. If you are converting the strings to numbers than you can actually use a single (for instance) convert decimal string to decimal) function and wire the entire array and the output will be an array of all the strings converted to decimal numbers in one swoop. You could then just resize the indicator on the front panel to view all the elements if you wish and there is no further processing to do and be done with it. Recording the readings could again be done as the whole array at one time (you can use the more complicated report functions if you want to do specific row and column placements, but I find basic appended log files to be the easiest for large amounts of data storage and then if necessary do post processing later), but again you could probably just write the %s strings directly. If you are just wanting to log the data to a text file, then since most of the time this is saved as a numerical string anyway you could simply wire the entire array to some of the write to file routines especially if it is a basic tab delimited file and you are just appending data to the end of the file.
As far as the time-out problem, you can specify a different time-out time limit in several places. You can specify it in the Measurement and Automation Explorer configuration or using the initial GPIB Configuration routines. If you are using a VISA address I believe you can also go to the create property node right click menu option and in there I think is a time-out parameter. The basic GPIB read/write functions I'm pretty sure have an optional timeout input.
It could be something as simple as leaving off some of the required command termination characters (usually the carriage return <cr> or "/r" and/or line-feed or "/n" <lf> characters) especially if you don't allow enough time for a command to be received and acknowledged before sending the next. It could also be that you are making your command requests too rapidly with not enough pause and the device is not ready for the next sequence and so it misses the command and so goes into waiting and the computer sits waiting for a response (as the acknowledge from the just completed command can often be mistaken for acceptance of the missed one). Sometimes the device misses the command, but has a command queue capability and will sometimes after a delay suddenly see the waiting command and then respond or the computer sometimes ends up sending another signal that the device receives. I've found even a short 5ms being wired to a wait ms timer between each command can often be enough to fix reading queries that used to take several seconds to allowing multiple readings each second. If you just need data over 5 seconds then you could probably go to 1/4 of a second or 250ms if needed and still have time for around 20 commands.
Depending on your instrument and especially for multi-channel temperature instruments I find you need to check if there is a "scan" mode or just a "measure" mode. A "scan" mode continually takes readings for all channels and then you simply query the current reading for the selected channel (you can often get the readings from all channels at the same time with one command) while a "measure" mode or command actually invokes the specific measure function of the instrument which often takes a whole lot longer for each reading and often is specific to just one channel and so halts the preparation of readings from all the other channels for transmission (even if the display on the unit itself updates).
A neat trick that is harder to use is to use the timed loops for the measurement sequence. It is very nice because you can use multiple ones to set up separate code that repeats and yet runs concurrently at different rates and many other things. One of there features is a option to force the loop to timeout and repeat and sometimes while you won't get a complete set of readings that go-around, the program will still continue for the next series of readings. You could add a check to see if you got all the readings or not and discard the rest if you didn't and wait for a full set.
Don't know if any of this helps.
-Leif
