Deploying basic VI to CompactRIO non-volatile memory

[MartinZs]

Hello,

I am new to Compact RIO. I have made a very simple VI that runs correctly from the development PC and blinks an LED from a digital output. But I receive an error when I build and deploy to run standalone. I am able to see, by creating file output (see dumperr.txt below), that the error occurs when DAQmx Create Channel (DO Dig Output) attempts to open the channel. So, it seems that some initialization/configuration is missing? LabVIEW from the development PC must do something invisible, whereas the standalone executable running on the target is dependent upon something I am not doing. I've dug around in docs and examples and tried bunches of things, but figure maybe I'm a newbie dingdong and someone out here can tell me how. Maybe I haven't properly configured something I'm unfamiliar with, like a channel/port/etc...I though by hardcoding and using defaults, I should be ok. See "DIO.vi" and project attached.

Thanks in advance!

Martin

Linux CLI output (on 9048)

admin@cRIO9048Dev:~# more /home/lvuser/dumperr.txt
Open:TRUE -201003 DAQmx Create Channel (DO-Digital Output).vi:6970001<append
>
<B>Device Specified: </B>Mod1

Some specs:

Dev PC Windows 10 running LabVIEW 2022Q3, NI CompactRIO driver 2022Q4, NI DAQmx2022Q4

Target: NI9048 Chassis, NI9401 Digital IO module, Linux RT System Image 2022Q4

Mode: plain DAQmx (no SCAN or FPGA)

Also....I'm not able to connect and debug remotely (hence the text file methodology). I enabled in the build spec, but I can't attach to the target's executable via IP address).

[Bob_Schor]

I haven't tried to open your ZIP file, since you appear to be using LabVIEW 2022, which is more recent than the versions I (and many other long-time LabVIEW users on the Forum) use.  I was going to suggest doing a "Save for Previous Version", but with a LabVIEW RT Project, this is probably going to include many files and folders from C:\Program Files\National Instruments, and will be a mess for you and a mess for us to navigate).

The Error Message implies that DAQmx cannot "find" the device you are trying to open.  I went back and looked at a LabVIEW RT routine I wrote for a PXI system (that I think was "retired" almost a decade ago).  In the code running on the PXI, I wrote "regular DAQmx code" for A/D routines -- DAQmx Create Task (such as an AI Task, with a Setup AI Task to create the channels and voltage range), a Start Task, then in a Timed Loop do the AI Reads, putting the data into an RT FIFO.  Note that this code runs fine on the RT System, saving the data in the PXI memory, where parallel routines are running to transfer the data samples (saved in PXI memory) to the Host PC for plotting, saving to disk, etc.

Can you possibly find your DAQmx code and save it to another sub-VI that, in turn, you could "Save for Previous Version" in LabVIEW 2019 or 2021?  As I recall from the old code, doing DAQmx on a RT Target wasn't that much different from doing it on the Host.  [Exception -- I've done some on a cRIO system where a lot of the work was done in the FPGA -- now that's different ...].

Bob Schor

[MartinZs]

Bob,

Thank you for the response! I hadn't considered going to older LV...it was quite painful enough finding the correct version/combo of LabVIEW, RT image and DAQmx drivers that allowed me to locate the cRIO thru NI-MAX/LV...I kind of dread the no tion ofgoing back in both the PC and the cRIO. But...I certainly will if I run out of ideas. I'm going to focus on your partitioning, and something you said about tasks has given me some ideas/learning opportunity. For ease of communication, I'm incuding a simple screen shot of my "Hello LED" application. As you can see it's structured reminiscent of the structure you've described, just using the canned DAQmx VIs. But maybe leaving the task blank/default is problematic, even though it works when running from the development PC's LV IDE.

[MartinZs]

Update: So, I'm not sure how, but I've had partial success. I tinkered with creating a task in DAQ Assistant, which had a conflict at the VI compilation/interpretation by in essence having redundant configuration of the [module / port / line]. So, I removed the task input to the "Create Channel" VI and went on modifying the code. I also removed some repetitive task Start/Stop inside a loop (just "Start" once now) and reloaded code a few times trying this or that...but then I noticed that the LED was working. And then... it wasn't....frustrated...but I persisted and found the following: When I have the USB cable plugged into the cRIO (which is how the development PC establishes a connection), it seems to inhibit the compiled/deployed run-on-startup VI from being able to find the DAQmx device and create a channel. Only when it's unplugged on boot, or I dismiss starting NI-MAX fast enough, does the channel get created. I'm currently trying to ascertain if that's the ONLY factor (i.e. does my original code work without the task changes), and then I'll have to see if it's stable. I really hate "solutions of unknown origin" as they almost certainly fail again.

[Bob_Schor]

Martin,

     My point about LabVIEW versions (vs "pictures of code") was that I find it difficult to work with "pictures of LabVIEW code" -- I can't, for example, easily run, edit, modify, etc. it so I can "try it for myself", see the errors, and try to "fix them".

     In broad terms, what is your RT code is trying to do?  In general, RT Target code operates without a conventional Front Panel -- there are no "buttons to push" or "Charts to view" (these generally exist on the Host and are passed between Host and Target by, say, a pair of Network Streams).

     What you should be able to do, for example, is write a routine that generates a waveform (say a sinusoid for 5 seconds) and writes the result to a file on the Target.  This can run entirely on the Target.  You can configure the code so that it saves the result in the Target Project's "Data" folder, where you can find it after the deployed Target code runs (and stops itself).

     Such a code should be simple to write, and (I hope) would be simple to "Save for Previous Version".  [Note -- I haven't tried doing this, myself, but there's nothing to stop you from running the same code on the Host PC, substituting a DAQmx device for the RIO's DAQ].  The best part is that you'd be able to "test" code that you could run on your PC (in LabVIEW 2022 or whatever you're running), when it works, do a "Save for Previous" specifying LabVIEW 2019, and then try moving the same type of code to your cRIO (and my myRIO) and verify that it still works (or fails to work).  I'll then have something to "see" and "test" ...

Bob Schor

[MartinZs]

My apologies Bob, I misunderstood you wanted me to save to a previous version of LabVIEW for ME to try in earlier LV. As mentioned, finding the right versions that behaved properly was a chore, so I was/am reluctant to change backward, unless critical of course. I've saved the attached as 2019 for you (Thank you for looking!).

Some empirical observation leads me to believe that the issue has nothing whatsoever to do with coding, however. What the problem is/was, it would seem, is that: when the cRIO boots up (either from reboot on deployment, OR power cycle) and the USB cable remains connected the host PC detects the USB, establishes the Ethernet Over USB link, AND claims the hardware for use under its own DAQmx drivers. So when the poor cRIO RT system finally gets around to checking for hardware, it's been swiped by the host PC already. More specifically, NI Device Monitor grabs the hardware, even if I don't start NI-MAX. I believe this is evidenced because if I "Dismiss" NI Device Monitor while the RT Linux is still booting/starting, it appears to make the hardware available to the local DAQmx drivers and hence LabVIEW Runtime and executables.

Now.....I am honstly not 100% sure that's what's happening but it makes sense to me. I think I'm close to satisfied that I understand what was happening, but your concurrence would be greatly appreciated! 

Finally, to answer your question, this silly "hello LED" was just to pathfind the build/deploy/run pathway. 

Lastly, do you have experience remotely debugging?? I have configured the Build Specification to allow that, but can't seem to be able to launch in remote debugging mode (where the host PC is running LabVIEW concurrently with the Runtime/Executable in the remote target)

[UMASO · Accepted solution]

Hello, you may have run into the same situation as I recently had, and I was helped by the below thread.

Please try placing a wait function of about 10 seconds at the very beginning of your RT code.  

Long story short, when RTEXE is started, DAQmx modules may have not been ready yet.  

https://forums.ni.com/t5/LabVIEW/Program-runs-fine-in-development-environment-but-runs-into-a/td-p/4...

[MartinZs]

Ok, that definitely fixes! It's an improvement from having to unplug the USB or cancel NI Device Monitor. I can envision sort what's happening too...the presence of the USB connection must keep the initialization of hardware tied up, so that the RTEXE started running and failed at opening/creating the DAQmx channel...so either shortening the system initialization via USB removal OR lengthening the app initialization works.

OK, I think that's acceptable! Thank you UMASO! And thank you Bob, as well!