I'm running a program on a cRIO 9045 that I'm trying to set up to control through my web browser. Until now I've been running it from the LabVIEW development environment, but we are looking to hire someone to work with me, so that won't do for much longer. I went through the process of building my application, making sure to also follow the steps NI has posted for how to run web browser access, and I get the following error on startup when the program runs as the Real-Time Application: Tue 08 Feb 2022 11:16:13 AM EST-201003DAQmx Create Channel (AI-Voltage-Basic).vi:1780001<append><B>Device Specified: </B>Mod6 <B>Task Name: </B>_unnamedTask<0>Error -201003 occurred at DAQmx Create Channel (AI-Voltage-Basic).vi:1780001 Possible reason(s): Device cannot be accessed. Possible causes:Device is no longer present in the system.Device is not powered.Device is powered, but was temporarily without power.Device and/or chassis driver support may have been removed.Device is damaged.Ensure the device is properly connected and turned on. Ensure the device and/or chassis is supported in the current version of the driver. Check the device's status in NI MAX. Turn the computer off and on again. If you suspect that the device is damaged, contact National Instruments at ni.com/support. Device Specified: Mod6 Task Name: _unnamedTask<0> None of the possible reasons make any sense considering that the program runs fine when it isn't attempting to run as a Real-Time Application. I don't believe that the specific device being Mod6 means anything - that's just the first module that I create a task for in my program, and I believe that if a different module were first I would run into the same thing but with a different specified device. Thanks for your help!

FYI, I reached out to NI tech support and got a solution from them, so I figured I'd post that here in case anyone stumbles across my post in the future. Here's the suggestions I received from tech support: "There are a couple of steps we could try to find out the cause of this error only in a rtexe: Add an initial delay to your code. This could help the RTOS booting up and setting all hardware before getting to the actual executable. Make sure you're not using or calling module resources using other programming methods than DAQmx (Scan Interface, FPGA). You can create a simple DAQmx rtexe to test this out, for example, just a simple acquisition task. Format and reinstall software to the cRIO, this can ensure a fresh installation on the target to avoid any corruption issues. Additionally, if you could attach a MAX report of both the cRIO and your host PC could help to evaluate any logs." Suggestion #2 did not apply since all of my modules were configured for Real-Time, so I tried suggestion #1 and put a Stall Dataflow VI before my hardware loop to tell it to wait before execution. This was successful after I set it to 8 seconds (I started with 5 seconds and that still wasn't enough - play around with the delay on your system if you're having this same error come up). I guess that the device needs some time on startup to load all the drivers and whatnot, so stalling the dataflow allows the device time to warm up. Here's the wording from tech support: The suggested delay should be placed before you get into your main loop (where you call the DAQmx functions), so it takes the delay time to get to the DAQmx calls. This is due to the possible scenario that the RTexe starts running before the Linux RT operating system completely loads all hardware configurations.If the DAQmx driver is called before this we should expect an error indicating there's no hardware available. About the amount of time, I'd suggest starting with a few seconds (maybe 5) and increment if the error still persists, just to discard this as a possible cause. Hope this information helps someone else in the future from spending too much time trying to get their Real-Time Application to work right!

From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.