This is not an easy question to answer. There are a number of variables that can substantially effect the results including network traffic and programming techniques.
There are at least two primary programming approaches that could be used to create this system.
Approach 1 would be to have the FP-2010 have no embedded LabVIEW code in the module. Instead, the FP-2010 will be acting in a manner similiar to the FP-1600 by simply broadcasting all 8 channels from the FP-AI-100. Using this approach, the estimated delay would be 2.8 ms (All channel update rate of the FP-AI-100) + 12 ms (emperical data from a test with FP-1600 firmware revision 0200 pumping data from a FP-AI-100 at the maximum speed) + overhead from DataSockets on the FP-2000 + loop speed for calculations (I think you had wanted to decide whether the signal was greater than 5 volts or not) + 1.25 ms FP Write.vi time (benchmarks for a single digital module have shown speeds up to 800 Hz assuming optimal LabVIEW programming techniques)+ 50 us FP-DO-400 output time. The big unknown is the DataSocket and VI times which will be severely effected by programming techniques and optimization. A downside to this approach is that you are transmitting 8, 16 bit values over the network which will decrease the total amount of updates since the updates are larged. Also, the Pause parameter of the FP-2000 and FP-2010 may decrease the total speed of the system (for all approaches).
Approach 2 places more of the logic in the FP-2010. The FP-2010 would be using the FP Read.vi to read the FP-AI-100 and would calculate a single 8 bit number that represents all 8 of the digital channels. In this case, the approximate times would be 2.8 ms (FP-AI-100 All channel update rate) + 2.5 ms (benchmark speed for 8 channel read using FP Read.vi under optimal conditions) + calculation loop time + DataSocket Write time (direct to All channel tag) + FP-2000 reaction time + 50 us (FP-DO-400 output time). In this case DataSockets only have to write a single 8 bit number so they should be somewhat quicker than 8 16 bit numbers. Note that in this case, we do not need any code running on the FP-2000.
Unfortunately, because the rate of change of signals, network traffic, network speed, and programming technique will play a large role in the ultimate speed, it is practically impossible to provide you an answer in milliseconds. The best thing to do is to write clean code and benchmark it. Be aware that bumping VI priority levels can cause the processor not to allocate time to the IA control environment which publishes the FieldPoint data over the ethernet which can cause poor performance.
Regards,
Aaron
LabVIEW Champion, CLA, CPI
