OK - so the formatting blew up on me and I can't seem to edit the original post. But, what I have found related to the above is similar to the Start Asynchronous Call performance. Essentially, the VI that I call via this routine is reentrant and it starts by attempting to initialize a serial port. If the device is not present, the port throws an error when I attempt to configure it, but only after waiting 5 seconds. So, the reason everything seems so slow is due to the long configuration time. This seems to be a hardware defined timeout - the configure serial port VI will not relinquish control until it has finished attempting to configure the port - 5 s. This in and of itself is not a big deal. We can live with this timeout, but what I don't understand is why this might be interfering with other VIs that are attempting to read from other serial ports that are properly connected. In my current setup, the display VI launched via the call to the Start Asynchronous Call attempts to connect repeatedly (this helps if a user accidentally disconnects the device and then reconnects later). The call to initialize the ports resides in a reentrant VI that runs on the instrument i/o execution system. All others use the stanard execution system.
Does anyone have any thoughts as to why the execution of reentrant VIs might interfere with each other if all VIs called are reentrant themselves?
Matt
