1. The Primary Control loop for our system is running at 200Hz. We am publishing and subscribing using my custom device on several dozen topics. Therefore this loop also needs to run at 200Hz.
2. Hard to say how fast it is currently running. This is part of a Veristand custom device on a cRIO target, so we don't have good diagnostic information. We did do some timing analysis of each of the individual components using some simple VI checks. See #3.
3. I put some timing diagnostics inside the main loop on a test build (i.e. Tick Count (ms).vi) and passed that data out via UDP. I put those before and after everything that was happening during each iteration of the loop. That VI consistently took the longest of all of our VIs in that loop to run (it took more than triple the time to run than VI on the lower left to "READ" data from Veristand). Additionally, when that VI is included, the fastest we can get our topics to run is about 90-92% of what they need to be. For example, we have data that needs to be published at 100 message/sec. However, when that VI is used, the fastest we can get it to go is about 92 messages/sec, with lots of variability (+/- 3 messages/sec). When the VI is removed/disabled, the DDS publishing is able to keep up to our timing requirements.
Important to note that we have tried multiple ways to move that VI from our main loop to a second (slower) loop, using notifiers/queues, and only using a single instance of it to try to stop our VI loops, but no matter the location or implementation of that VI, it seems to slow everything down for us.
