How to discover the bitfile deployed on a target

[Phil_Blaze]

How can I discover what bitfile is deployed on a RIO? 

I've juast started at a company whre I am the sole LabVIEW guy. I've inherited a code base and a whole slew of RIOs, and very liitle documentation as to what exactly is deployed where. I'd like to be able to use some of the hardware, when it's not being used, to test new ideas, but I need to be absolutely certain I can restore it to original condition. I can download the RT layer code via FTP, but so far haven't been able to figure out how to discover which bitfile is deployed. Any help? 

[Hooovahh]

I don't know how it exactly is on RT, but on Windows when I make an EXE that uses an FPGA, the bitfile has to come along with the EXE.  Because when if I run this EXE on machine with an FPGA that doesn't have the bit file on it?  It needs to download it to run it.  So what I would assume (not knowing for sure) that the bitfile used on this FPGA is probably on the RT, in a support folder with the RT EXE.  By backing up the RT code, aren't you also backing up the FPGA bit file?

[Phil_Blaze]

I don't want to assume anything. I have inherited multiple revisions of the same project, each with one or more build specifications. I want to know explicitly what has been deployed by recovering that information from the hardware. It's tempting to assume it's the latest revision, but I'm not going to take a chance on getting burned like that.  I tried cross referencing the date stamp of the deployed startup.rtexe on the target to something in a project, but the date stamp of the file on the target is in the 1970's.

[nathand]

As Hooovahh mentioned, bitfiles are built and deployed as part of an RT application; the bitfile doesn't exist on its own anywhere. Some RIO targets do allow you to load a bitfile into onboard flash so it will run at startup; I don't know how widely used that feature is but I think it's used mostly when the FPGA needs to run standalone, without an associated RT application, and even in that case there's no way I know of to read the bitfile back again.

I'm not sure if it quite solves your problem, but take a look at the Replication and Deployment Utility, which you can use to image a cRIO, and later restore that image if necessary. It won't tell you what version of your software is currently installed on the cRIO, but at least it will allow you to go back to the exact configuration that was in use prior to any changes you make.

[speleato]

As has already been commented here, unfortunately, there isn't currently a way to discover what is actually programmed to a running FPGA.

I wanted to suggest posting on the NI Idea Exchange. My guess is that this kind of functionality would be useful to a lot of people, so I'd think you could get some traction there.

[Phil_Blaze]

I agree. IMO this is a big hole in the maintainability of the RIO family. If everything is done correctly, every RIO deployment is fully documented, hardware and software records are kept, projects are backed up, etc. In the real world though, undocumented changes happen, people leave with no notice, records get destroyed or lost. And after one of these unforeseen events we need to know for certain that our process is going to run the same today, as it did yesterday. 

Really, how hard would it be to automatically write a text file to a folder under  ..\ni-rt\system when a build is deployed? Write the LabVIEW project file name and date, a build specification descriptor, the name of the bitfile that maps to the FPGA, etc.

My $.02

[Hooovahh]

---

@Phil_Blaze wrote:

Really, how hard would it be to automatically write a text file to a folder under  ..\ni-rt\system when a build is deployed? Write the LabVIEW project file name and date, a build specification descriptor, the name of the bitfile that maps to the FPGA, etc.

---

Not hard at all, of course it wouldn't solve much either.  Having the project which is just an XML describing the files used in the build, but not the actual source code isn't very useful.  Especially considering you should only use one project, and one build for each target in most cases.  So my text file is just going to say "Project 1.lvproj -- RT Build" or something.  Of course knowing the name of the project doesn't tell you what source was used, or what changes were made, or how to reproduce the build.  That's the purpose of SCC.  It's on the developer to do software development right, not the IDE.

[Phil_Blaze]

In life, there's principle and there's practice. Sure, the guy before me should have done things differently, but it’s not on him anymore. It’s on me. And more importantly, it’s on the people who will be using these control systems and depending on them to work as expected and keep them safe. I have several dozen projects with multiple code revisions, multiple build files and multiple bit files in them. I could assume that the latest of each are the ones to use, but they might have been dead ends, or half finished. That assumption could hurt someone.

I have all the code, I just don’t know which versions to use. A simple plain language file, stored on the target, listing  the components that went into each deployment would be of great value. If I have to, I could probably find the correct startup.rtexe using file compares. The only thing that’s truly opaque is the bit file that maps to the FPGA.

Here’s a scenario for you. Let’s say you want a widget made and you’ve found a company to manufacture it. They have their own LabVIEW guys and they code the system.  They submit the code for review before production launch and you OK it. How would you know they didn’t later tweak the code at the FPGA layer to adjust some of the test criteria or data in their favor?

There are a lot of reasons why automation code should be explicitly identifiable and auditable from the target.

[Hooovahh]

---

Phil_Blaze wrote:

There are a lot of reasons why automation code should be explicitly identifiable and auditable from the target.

---

Yup, totally agree, I have tools that automate this to some extent.  Oh and the build process can be more verbose, listing all the contents of a build, but I don't think this satisfies what you are talking about.  If you add this to your LabVIEW.ini it adds a bunch more information in a text file next to the project after a build is made.

NI_Appbuilder_logging=True

With this it can describe more of what components go into a build.

[thoult]

A little late to the party, but I'm sure nobody will mind me adding my tuppence worth.

I use a combination of System Configuration API VIs and FTP / WebDAV to figure out what's going on with my target. I only do this with locked (password protected) sbRIOs, so your mileage may vary...not sure how an anonymous account works.

Backing up images to and from the RT

- I discover all available RT systems using Find from the System Configuration subpalette under RT > RT Utilities (nisyscfg.lvlib/Find.vi)

- I list all systems by Hostname (IP), allowing me to select the system I'm after

- Passing this IP to Initialize Session.vi allows you to read a variety of properties back from the resource, as well as Get Image and Set Image. I tend to save these to a file on the network when I set up a system.

- Images contain the following (thanks RAD documentation!😞

When replicating applications from one target to another, the application image is retrieved from one RT target and copied to another.  An application image is comprised of the contents (all of the files and directories) of the hard drive of an RT target which define the behavior of the RT target, as well as any bitfiles set to deploy to FPGA flash memory

- My image contains an RT executable, set as startup, which opens an FPGA reference by bitfile. Not sure how other flavours of deployment work, but this way I can control what's on the device.

Discovering the FPGA bitfile in the image

- FTP/WebDAV into the device

- Check the file listings in /ni-rt/startup/data/

- Here's a screenshot of my FTP list results with project specific information redacted to protect the innocent:

- I can now use this bitfile to compare to a master bitfile. I can make a couple of comparisons between versions...after all, they're just XML files. If I've made a change, I'm pretty sure:

• The SignatureRegister, SignatureGuids and SignatureNames targs in the bitfile should differ
• The BitstreamMD5 will differ
• The Bitstream itself will differ...but this is pretty long

I was hoping to get a specific version number out of it, but I'm not entirely sure this is recorded in the bitfile itself. Hope this is of some vague help. I agree that LV should make it a helluva lot easier, but in the meantime rolling one's own remains the only approach I can think of.

Edit - for clarification, I could probably use RAD, but I'd rather roll this functionality into my own commissioning tools so that an installer can commission a new platform itself, without much in the way of user input.