Decrease in speed when I plug in SCXI Chassis

[nnugent]

I have a 6052E DAQ card in a Win2K machine running LabView 6.1. If I configure the digital and analog lines, using MAX, directly to the card's availible I/O pins, my application's timer increments in under 1 milliseconds intervals. This is a good thing. Because the system this was controlling grew, so did the need for more channels. So I bought an SCXI chassis and 1102, 1124 and 1160 modules to use in it. In MAX I created a new config file and then added the chassis. MAX auto detected the modules without problem and I added the channels using the virtual channel method. All channels tested fine. I ran the same application as before and now the counter increments (at best) 30 ms. I used the probe tool in LabView to monit
or the error out from the read and write sub vi's and everything seems to be running perfectly except it is now 30 times as slow. What can I do to solve this problem?

[Russell]

The extra overhead involved with communicating and sampling from the SCXI chassis will slow down your program. You still won't miss any data though, since your probably doing a buffered acquisition. I'm afraid there's nothing you can really do about that. Depending on what kind of problem the slower rate is causing you, most likely there are some ways around it. Multiple threads, notifiers, etc...

[nnugent]

This system is used mainly as a control system and not as much for acquisition. The slower counter rate is not allowing tight tolenrences to be set for an event. Example: I want to actuate a relay at 2.23 seconds. At 2.25 seconds I want a different relay to open/close. Etc. So if the clock counts 2.00, 2.03, 2.06 ... 2.24, 2.27. Setting tolerences too low would cause the event(s) to be missed and too high (say 10 ms for this example) would cause the relays to open/close at the same time instead of two different times.
I understand that multiplexing and demultiplexing the 6052E card's data lines would take some time. Are you saying the problem lies with the DAQ card being too slow to communicate with the SCXI, demultiplex, then update the outputs, multip
lex the data to the SCXI and talk to the SCXI again? If so, what DAQ card could overcome this problem? Or, are you saying the SCXI just cannot handle what the DAQ card is sending to it?
Also, I don't understand why the counter would be effected by the hardware addition. In the application, the counter is in a while loop by itself. Since I am using the two onboard counters, how would the counter even know (or care) if a chassis were plugged in or not? I could understand if the outputs weren't getting written fast enough. However, the counter will count in 1 ms increments without the SCXI then count in 30+ ms with it plugged in. Since it is in it's own loop and has no input dependencies and writes to a local variable out, why would it matter if (for say) the digital out took 5 minutes to complete? The counter loop should continue counting and when the digital out loop completes (after 5 minutes) it then attempts to do it again.
Thanks for the help.