Program runs fine in development environment but runs into a DAQmx error when running as a Real-Time Application

[rseabeck]

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
-201003
DAQmx 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!

[Kyle97330]

Not sure how to fix your problem but just as an extra diagnostic step, could you drop a DAQmx System property node, set to the "DevNames" property, and record the output (from the built program with issues)?

It could at least separate the issue into one of three categories:

1. It sees no devices at all

2. It sees some devices, but not this one

3. It sees all devices but with different names

[rseabeck]

---

@Kyle97330 wrote:

Not sure how to fix your problem but just as an extra diagnostic step, could you drop a DAQmx System property node, set to the "DevNames" property, and record the output (from the built program with issues)?

It could at least separate the issue into one of three categories:

1. It sees no devices at all

2. It sees some devices, but not this one

3. It sees all devices but with different names

---

Thanks for the response. Alright, gave that a go. Here's the results:

I put in this bit of code to do as you asked. No dice after a couple attempts to run the Real-Time Application. The file never showed up on the cRIO disc. Decided to give it a go running the program from the development environment though just to check if my code even worked. It did, and you can see the snip of the text file it created. 

Does this provide you the insight you were hoping for?

[Kyle97330]

Well in general that is the code I was hoping would run, yes, but since that's the output from the working dev code it's unhelpful in diagnosing the problem on the built application side of things.

It's interesting that the output file doesn't show up on the device.  I don't know if LV is properly set up to handle spaces in file names on CRIOs, maybe you could try it without the space?  If it still doesn't work, maybe there's a permissions issue?  Weird that you wouldn't see an error on the file operations there, unless you're not seeing errors coming from that chain for some reason.

Instead of outputting it as a file, you could maybe output it another way from the built application, like via constructing an error?  You clearly got the error message coming from the DAQmx channel creation VI, so you should at the very least get that.

[rseabeck]

---

@Kyle97330 wrote:

Well in general that is the code I was hoping would run, yes, but since that's the output from the working dev code it's unhelpful in diagnosing the problem on the built application side of things.

---

Yeah, that's what I was afraid of...

---

It's interesting that the output file doesn't show up on the device.  I don't know if LV is properly set up to handle spaces in file names on CRIOs, maybe you could try it without the space? 

---

The error logging file that the error message in the top level post of this thread has a space in the file name and it clearly is still able to log to the file, so the cRIO is able to handle spaces in the file name, but that was a good thought.

---

If it still doesn't work, maybe there's a permissions issue?  Weird that you wouldn't see an error on the file operations there, unless you're not seeing errors coming from that chain for some reason.

---

Any suggestions on how I may check permissions? There've been a few times it's asked me for the username and password before continuing - I just assumed that was enough.

---

Instead of outputting it as a file, you could maybe output it another way from the built application, like via constructing an error?  You clearly got the error message coming from the DAQmx channel creation VI, so you should at the very least get that.

---

Not a bad idea, I'll wire some things to put the device names into the error message and see if that works. I'll keep you posted.

[rseabeck]

---

@Kyle97330 wrote:

Instead of outputting it as a file, you could maybe output it another way from the built application, like via constructing an error?  You clearly got the error message coming from the DAQmx channel creation VI, so you should at the very least get that.

---

Tried this by adding a concatenate strings function and combining the error message and the DevNames output that goes into my error logging subVI, and there were no device names in the file, just the same error message I've been getting.

[rseabeck]

I was able to determine that the issue is just with DAQmx in the real-time application. I bypassed my DAQmx subVI and let my simulation run, and it logged simulated data all night just fine. Maybe there's something special I need to do at the DAQmx Create Channel VI? I'm at a loss here...

Can't control the program because I can't get web server access, but that's probably just an IT issue, and not the topic of this thread.

[rseabeck · Accepted solution]

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:

1. Add an initial delay to your code. This could help the RTOS booting up and setting all hardware before getting to the actual executable.
2. 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.
3. 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!

[UMASO]

reabeck, 

I cannot appreciate enough for your share about this.  Suggestion #1 worked for me as well.   

In my case, error said something that NI 9775 could not be found on my cRIO-9055.  

Then, following your post, I first set 5 seconds wait at starting up application, and yes it was not enough for me as well.  

The amount of wait time was increased from 5 to 8 seconds, exactly following your advice.  

Voila!  Eveerything started working.  

Thanks much for leaving your resolution on this community.  You saved my life.  I wish I could given you 10 Kudos for this.  

[rseabeck]

Hey I'm glad I could save you the headache!