HI Dan,
If you do not mind, I would prefer to keep this thread going on the the D-Exch so I have access to it from the web and to help others.
I think you are right in that I was confused. This is probably do to how I have things set up in my app.
Let's see if I can take a couple of minutes to give you a better idea of how things are set up and see if I have a better idea of how the sync/async setting affects my app.
The app works tightly with a RT app that simulates a complex system. In this project the RT app keeps a number of PID loops closed and deterministicly polls a device on two RS-485 ports. The Windows app. (the part i am questioning) performs 5 major functions. It uses DAQ to monitor 120 channels at 1000 Hz, supports user selctive monitoring of these channels, while also monitoring status messages from the RT system via ethernet, and also collects and displays the responses returned by the device under test to the RS-485 poll requests that were issued by the RT system. It also provides logging, snap-shot, and averaging.
The logging functionality is invoked using a run VI and runs at low priority. Aside from that, no other priority and thread assignment has been done. The rest of the windows app runs a parallel loops inside the main VI. There is a seperate loop for the GUI, snap-shot, DAQ and serial.
The serial loop watches both ports for waiting data by checking the number of bytes at the serial ports. As the app. sits at the moment, the greater of the two waiting byte counts is then used to do two VISA reads, both on the same diagram in parallel. Both of these parallel reads are set as syncronous.
The app. performs its functions well but I have noticed some sluggishness in the the GUI responding to clciks etc. If you just watch the app. and do not touch it, you would never suspect anything odd.
The memory is good and stable. The CPU takes some spikes periodically but consistently runs below about 35% utilization.
With all that having been said I would like to now try to apply what I think you have been telling me to what I am seeing.
CHECK THAT! I may still be confussed. Let me back up.
If the the two syncronous VISA reads are in the same VI they have to be running at the same priority.
Because the two calls are running parallel (i.e. two seperate "error cluster" sequenced strings on the diagram) they CAN run in different threads.
Is this correct?
Can I be certain they run in different threads?
I understand that if they are both in the same thread and the non-ready executes first, the ready will have to wait.
Do I have to wrap the the VISA reads up seperately and set the wrappers to run in different threads?
Do you think the way I am handling the VISA reads has anything to do with the mistereous sluggish-ness?
I am resonably sure it the most recent version of VISA (don't remeber the version off-hand) but the app was developed after I remeber you stating the VISA read hangs the CPU problem was fixed.
I appreciate your patience with my inquiries. You posting answers here and on info-Labview have been very enlightening. Around our office when I mention "VISA Dan" they know I am talking about something that you said.
Enough of that stuff.
What do you think about what is happening with the app?
Gratefull for your answers this far,
Ben