Hi Chad,
I'm sorry I did not reply to your post sooner. I have been running a few more troubleshooting cases and trying to figure out a way to send you the part of my code that is having this problem. Unfortunately, I am unable to simply provide the software that is installed on the 8196RT because this is a sensitve system (files cannot be copied) and it is a stand-alone system (there is no connection to the internet). I will keep trying to get a code sample posted, but in the mean time I want to provide more detailed information so you can try out a similar case on your own.
To answer your question, the DAQmx Device Reset VI does not fail when I use it in a Real-Time startup. I have been able to narrow the problem down a bit more, and maybe I can provide enough information for you to reproduce the error. It seems that "Initialize with Topology.vi" is receiving a valid input, but in Real-Time (running as a startup) it is providing an output that looks like an empty string. Conversely, when it is run manually, it creates a valid handle.
I have reproduced the error using a simple VI:
1. I have a while loop with a case structure inside the loop. There is a 100 ms delay in the while loop (using the Wait (ms) function). The Stop terminal of the while loop is wired to run as an infinite loop. The Initialize With Topology VI is outside the loop, wired to the loop using a tunnel, and wired to the case structure inside the loop using a tunnel as well.
2. The case structure inside the loop has eight different cases. A Shared Variable (string type, let's call it COMMAND) is wired to the case selector of the case structure. Each case either opens or closes a specified relay using niSwitch Relay Control.vi followed by niSwitch Wait for Debounce.vi. The following list provides the cases, the switch identifier used in each case, and the switch command (or state) being set in each case:
- CASE 2828, k9, Open Relay
- CASE 2929, k9, Close Relay
- CASE 3636, k6, Open Relay
- CASE 3737, k6, Close Relay
- CASE 2C2C, k5, Open Relay
- CASE 2D2D, k5, Close Relay
- CASE 2E2E, k7, Open Relay
- CASE 2F2F, k7, Close Relay
When the COMMAND Shared Variable has 2D2D written to it, for example, it should open the relay on the card that corresponds to k5. All error outputs are also wired to a shared variable of the proper type.
3. The shared variables used in this VI are accessed by creating another VI on a PC. This VI has a text control (bound to COMMAND), an OK control button, a Stop control button, and multiple error indicators (bound to the error shared variables created in the first VI) on the front panel. A delay of 500-1000 ms provides a good update rate in this loop.
4. This user VI has a while loop with the Stop terminal wired to the Stop control on the front panel. A case structure is placed inside the while loop, and the OK control from the front panel is wired to the case selector of this structure. In the true case, the value entered in the text control will be written to the COMMAND Shared Variable. In the false case, do nothing. All other front panel terminals are placed inside the loop so it will update the values each loop iteration.
When both of these VIs are run manually, the switches respond to the commands as expected. When the first VI is built and run as a startup, the switches don't respond anymore, even though the shared variable COMMAND is read properly and the proper case is selected.
Thanks so much for your help,
Aimi
