@Joerg: I just updated my package version from 7.0.1 to 7.1.1 and then created a new RT Tester. The timeout constant is now created. So you're correct, the issue was fixed in 7.1.
I also have an update on my issue running DQMH code from the development environment. As of this morning, after updating my DQMH package to the latest version 7.1.1, the issue is no longer present! I validated my DQMH modules and there were two fixes needed per module, sorry I can't remember exactly what they were now. After fixing the modules I can now run the modules themselves and the testers from the development environment. I don't think it's by virtue of restarting my computer or the cRIO because I did that several times yesterday to no avail. So I'll count this as a big win and move on with my DQMH adventure.
I have a new thought about what we've been discussing regarding where the code should live in the project. In order to maintain the flexibility of quickly testing the module in Windows, but also maintaining the code where it ultimately belongs on the RT Target, what if I just had two projects? One where my 15 or so module libraries were under My Computer and another where they are under the RT Target? That way I don't have to keep moving the library back and forth in the project and potentially breaking something. Maybe I'm overcomplicating things... But as long as all of the VIs are kept in the module's lvlib then each project should be fairly autonomous. I suppose it just becomes a problem if I have business logic that is outside of the module's lvlib. Hmmm... maybe I am making this complicated lol. 😅
