Difficulty creating a local feed for PXI realtime application

[gregoryng]

I am having trouble creating a feed for a PXI real time application in Labview 2020 MAX. I am coming from a NI MAX  18.5 background where I used to right click on my PXI target in MAX to install a startup application just like installing drivers, etc.

I'm not sure if this is a question for the PXI board or here, or somewhere else, but it seems to have to do with the package system?  Here's where I am at so far.

I'm starting out with creating a feed on my hard drive using these bits of documentation:

• I am using Labview 2020 on Windows 10 on my Dell desktop computer, to write a realtime application for NI Linux RT, for a PXI-6681 target.  I call this project "AQN".
• I have built an nipkg file for my AQN app.
• Distribute Packages Using NI Package Manager - I moved this nipkg file to another directory and create a local feed using the npm CLI method. Also looked at Build a Custom Feed Using NI Package Manager .

In NI MAX, I add this feed to the software list for my target as shown below (Remote Systems -> PXI -> Software -> Advanced -> Manage Feeds)

I then add the directory with the feed in it (which is at C:\ni-feeds\elsa-aqn-feed), and then select the Add/Remove Software menu option.  Then I get this error message, which I don't understand what is going wrong.  I checked that the Packages, Packages.gz files are in the directory and seem to make sense.

I also tried putting this directory on a web server and I got the same result.  Tried checking and unchecking "Trusted"; same result...

Using this same directory, I was able to make a feed for a Windows GUI application that I run on my local Dell PC, and add this to the NIPM GUI.  So it seems like NIPM thinks the metadata is fine for that feed.  Is there some trick for making the feed work in NI MAX with the RT target?  Is there some way to figure out why it thinks the directory is inaccessible?  

[Scott_Richardson]

gregoryng, fwiw, I personally, as someone at NI associated with those that work on NI Package Manager, know very little about the questions you are asking and using that option in MAX.

[WesW]

I am also not a realtime developer, but I can share that NIPM and .nipkg files are only used on Windows. You cannot install a .nipkg file on a Linux RT target with MAX, as .nipkg's are a Windows-only technology. 

You might have luck with this question over on the Real-Time board?

[gregoryng]

Thank you all for your thoughts.  I will try the real time board.  

Really the main thing I want to do is to be able to deploy my application to a real time target so maybe I am just going about it in the wrong way.

[gregoryng]

---

@WesW wrote:

I am also not a realtime developer, but I can share that NIPM and .nipkg files are only used on Windows. You cannot install a .nipkg file on a Linux RT target with MAX, as .nipkg's are a Windows-only technology. 

I guess as a side comment to this, I did misspeak -- when I built my project for Labview RT, it produced an ipk file (not an nipkg file), and NI package manager feed-create command noticed this .ipk file and produced a metadata entry in the Packages file (implying that it looked inside and understood the file).

[WesW]

Thanks for the clarification... Both an .nipkg and .ipk are Debian-format package managers, so they know how to process the feed and package control file (which I'm guessing is what you were seeing). However, they don't have the ability to install that package unless it's of the matching type. 

[WTangoF]

I dont know much about PXI.

But on a Rio Linux RT target, you'd have the base image and required software components installed on the target already.

Then you would FTP the .ipk file to the target, then SSH to the target and opkg install <path to ipk>.

I have never seen NI Max used in the way you're attempting to use it.  You would handle feed registration in the opkg config files on the target or via systemlink if that's an option.

But if you are actively developing for a target wouldnt you just plug it into your dev machine and run as startup from Labview?

[gregoryng]

Sorry for the late reply.  Yes, those are all valid options. 

The main point of this question isn't really about streamlining the developer experience, but for end users of the hardware.

In my situation, I have users who are unfamiliar with the Labview Development environment -- they just have a PXI system that provides them with measurement files on a hard drive.  I want to provide them with an update in the form of an application binary and a simple set of instructions for how to install that binary. 

Using the LabVIEW IDE is too much hunting and clicking for that, unfortunately.

Transferring the opk, ssh, and running a command is likely to be acceptable for our current users (who are familiar with using a command line), but if the method can be even more friendly to someone who doesn't consider themselves an "developer/engineer" then that would be desirable.  Of course I can write a wrapper around this that is easy-to-use for the end users, but I just want to make sure I'm not reinventing the wheel for something that NI already has an easier supported method.

Your message does make me think I can treat this more of an open Linux system than I did before.  Previously the Pharlap RT system seemed like a bit of a black box with only a few ways to get software in (i.e., MAX).  Whereas now I guess I can count on interfacing with this like standard Linux systems I'm more used to.