Developing for alternative, but similar RIO hardware

[altenbach]

I am trying to figure out the best way to develop code that can run on alternative, but similar targets using a single project.

I have three RIO systems:

1. cRIO-9076 (& modules for AI, AO, DIO)
2. sbRIO-9636
3. sbRIO-9637 (linux based)

(2&3 in the form of the old and new eval kit, incl daughterboard).

All hardware alternatives are sufficient for my application in terms of IO and power.

Typical scenario for the hardware location (mix and match!):

1. is deployed and connected to an old spectrometer, running the current version as startup app, controlled by a built desktop app.
2. is at home used for code development and testing
3. is at my desk at work used for code development and testing

Development is primarily on my laptop and I can easily move it between locations. The LabVIEW project contains all three devices and the same RT and FPGA VIs are located under each target, all pointing to the same file on disk.

My reasoning was that this way I can easily develop and test code improvements on whatever target is currently connected to the dev machine and the changes automatically are also applied to the other targets, which I can built later once connected.

When started, the deployed PC app checks what hardware is currently connected, then connects to it via TCP/IP and everything works great. (During development, I run the appropriate RT VI before running the toplevel VI). Streams and shared variables etc. are hosted on the RT target.

Questions:

• Is this a reasonable approach or are there better ways to do that? (If I would use multiple projects and change the name of the toplevel RT VI, I would need to open each project and make identical changes, another place to accidentally make mistakes)
• It seems that the project does not really function well in this scenario, for example if I am in files view and right-click a RT VI file to show it in the project view, it only finds one instance of the VI, while there are other instances of the same file under the other targets.
• What are "target folders" and how do they differ from virtual folders or plain targets? Do they have any special powers?

[Mads]

Working with multiple targets in the same project quickly becomes a headache as each target is not given its own application instance.

This means that if you have a class or library for example that is used on multiple target it will be permanently locked. I recently started using Delacor's DQMH framework in a multi-target project - and have given up on having just one project file 😞 I really hope this is resolved soon, as it is much more tidy and convenient to work with all the targets from one project (the fact that you *can* add multiple targets to a project kind of indicates that this should be a good methodology as well).

I have yet to figure out what the use case for target folders are. They seem to be have the same functionality as virtual folders, but why you would want to deal with it as a completely different concept (than virtual folders), without getting any added target specific functionality, I do not know(NI/anyone?). To me at least it just seems confusing and unnecessary (I'm prepared to be amazed though 😉 )

[WestOfEden]

As Mads pointed out, you could encounter limitations if you were using classes with multiple targets. That being said, it is the way the only way I know of to do what you're trying to do.

When you try to view the VI in the project/items view, it shows the instance that has been in the project the longest. I imagine it just wasn't anticipated or accounted for that there would be multiple instances of the same VI in the project.

As I understand it, target folders are entirely for organizational purposes, and don't actually have any special functionality. 

[altenbach]

Thanks. I don't use classes with this project so I am probably OK.

Since I noticed some limitations, I was wondering if this use is even safe. I guess it is. And yes there are probably improvents possible that  would make all this a bit easier. maybe I post some ideas at a later time 😄

[JÞB]

@CA

I've been looking down the same tunnel for a week or so.

My current schooling on the subject it that you need the power of DAQmx and the System API.  That dratted FPGA code does not travel well between targets!  cDAQ is RT cabable and those DAQmx objects are abstracted to the hardware.  For Condition Monitoring or "Test" benches, a configurable hardware layer VIA  any nuber of *.NCE files or even the <app>/*exe/NI-DAQ/folder ini's gives you a lot more control of what hardware really exists in this "A" of "x" hardware flavor.  SCADA gets a bit more challenging- you did not mention a need to controll!

The FPGA vi's need to know a super-set of the system capabilities for RIO and just chop them down to what is needed in this instance. Or, recompile to a new target!  THAT is a bit hard on the guy that needs to add features.  Adding or modifying a DAQmx Task/Chan/Scale programatically... can be done by a novice.

That being said! those FPGA's are essential for some applications!  But, this limits the flexability of the external hardware.  SO: where is the flexability needed?  A) I need to change FPGAs  B) I need to change the far end equipment list.

Again, I'm looking at CM not SCADA!  

Getting onto specifics:

"Target Folders" seem to be a series of stuff in the project file- that may or not be consistantly syntaxed as text.  Yet they work adiquatly for simple projects like the NI Configuration Wizards.  (Feel Free to post some awesome IE Ideas)

It seems that the project does not really function well in this scenario, &Is this a reasonable approach or are there better ways to do that?  Make a project template with a comment that "This" must be compiled to a valid FPGA.  OTOH-Thats what NI did with the shipping examples and template projects.  (Must, is a strong word but, I won't go there and point out a SW limitation by lack of HW spec)

[altenbach]

Thanks Jeff,

Part of the reason I am trying to go that route is the fact that I no longer even need DAQmx  (or any other "drivers" on the PC), which used to be that gigantic package. All the PC needs is plain ethernet (typically a second network card or the NI USB LAN cable). The nice thing is that I can distribute a lean installer for the PC and update the program often while I can occasionally distribute a new embedded image (~80MB). This makes the PC code completely OS indepdendent and all it needs is the LabVIEW runtime (+ the system configuration runtime to update the target, but that can be a seperate thing).

So, instead of having a generic NI PCI DAQ board, tons of drivers, and dedicated LabVIEW code, I can offload all "DAQ intelligence" to the RIO, using a simple custom API (a few streams and shared variables hosted on the RIO) to get everything I want done. All complex tasks such as tighly synchronized inpu&output, signal avaraging, and realtime monitoring happens remotely. I love ithe concept and it works well!!

One requirement of the application is that AI and AO run fully synchronized on the same clock. Much easier on FPGA that on windows.

(I did all that back in '96 using an NI ISA board and LabVIEW 4 on windows 95 and it was running continuoulsy for 20 years, but now the HD is dying and I needed to find an alternative. I spend a long time refreshing the UI code and translating the traditional DAQ code to DAQmx when it occurred to me that RIO would be so much nicer!)

Many years ago we bought a NI PCI DAQ card as potential replacement, but it is just an endless hassle. If the computer breaks, changing it is major work and has severe limitations. IT gave me a spare PC, but it was skinny so the card would not fit. They finally dug out an old full size chassis, but it was much slower. and older.

Using RIO, I can use anything (desktop of any size, laptop, netbook, mini PC, even something like this.)

---

@JÞB wrote:

Make a project template with a comment that "This" must be compiled to a valid FPGA.  OTOH-Thats what NI did with the shipping examples and template projects.  (Must, is a strong word but, I won't go there and point out a SW limitation by lack of HW spec)

---

Switching an existing project  to a diferent target architecture seems convoluted, but maybe I just did not look in the right place.

Case in point:

I had everything developed and running fine on the old VXworks based sbRIO-9636 and was trying to modify the project to be used for the new sbRIO-9637 (linux based) instead. Both boards have identical functionality  (just differ in CPU/FPGA/OS). All IO are the same and they have the same eval kit daughtercard.

You would think that I could just take the old project, right-click the embedded target, and change the type leaving everything in place, but I could not find any way to do that. I ended up adding a second target, moving all the VIs (RT&FPGA) over, then deleteing the old target.

Later it occurd to me that I could try to leave all the targets in the same project, each pointing to the same RT/FPGA VIs for "synchronized" development but encountered some rough edges, thus this discussion. 😄