how to make a project that allows for many instances of the target

[Eric_Pope]

I'd like to know how to make a project that doesn't define beforehand how many instances of the RT target will be connected to the PC. I'm working on my PC level VI that can send and receive data from my RT target. I'm thinking about launching two instances of the PC level VI when I have more than one RT box in the lab. So far, I've figured out how to launch two or more instances of a PC level VI using this method.

The best scenario I can think of is where my project defines all the target settings, but the user user inputs the target's IP address (or DMA name, etc.) into each new instance of the VI. The user could launch the VI several times either as a subpanel or a separate VIT window. Each time it would require a reference to another target and run independently from the other VI instances.

Is there a good example of a project like that? Should I be researching how to modify my project settings programatically like this example? I think I could make that work, but I'd like to know if there is a simpler alternative.

For now, I'm assuming my targets will have identical hardware.

[CoastalMaineBird]

How are you communicating with your target?

I have not done what you seek, but it seems like I could - all I would need is the IP address of each target.

BUT

--- I never use any settings in the Project.

--- I do not use shared variables (too slow).

--- I do not use ANYTHING in the project, that I can avoid.

--- I use EtherCAT and I configure EVERYTHING in code.

--- I have my own TCP connections to the program on the PXI.

I don't actually know what the RT program actually uses from the project settings.

I do know that I have complaints from the DEPLOY procedure about the SCAN ENGINE settings - it doesn't like it when I programmatically set the scan engine, and then don't change the project.

But I think all that is overcome-able.

So I don't see an obstacle.  But, as I said, I haven't actually done it.

I don't know how the supervisory stuff works.  Or even IF it works in an RTEXE.

Have you tried?

[Eric_Pope]

I'm communicating with the target using network-published shared variables. They aren't too slow for what I'm doing, but I'm open to suggestions for improvement. Could you elaborate on how you avoid having any settings in the project? How do you get your RT code compiled and deployed?

[CoastalMaineBird]

I do have to compile it from a project. 

But you can make an RTEXE, and then FTP it into the PXI box into the STARTUP position (you have to rename the one that's running though).

Then reboot, and you're running the new version.

I don't know if that will work using Shared Variables, though.  I suspect not.  The Shared Variable Engine has to know about who has variables and where.

Unless you can programmatically inform the SVE about your new instance, it won't know about it.

Whether you can do that or not, I don't know.  I've never used Shared Vars, other than to try them out.  I avoid a lot of the NI "easy-to-use" stuff, because it's too confining.  As you are finding out.

How big a pain is it for you to convert your program to standard TCP operation?  Just have each instance contact the host with an "I'm Here" message, and go from there?  Might be trivial, might be enormous.

Another idea: is it feasible to pick a number (say 32) and put 32 targets in your project?  Maybe not all of them are there, but you can work with that.  Have some naming scheme where you can figure out IP numbers from the Name.

[Eric_Pope]

The 32 targets suggestion sounds like a nightmare I had once! ヽ(ﾟДﾟ)ﾉ But the part where you said that you compile the RT in a separate project and deploy it on-demand sounds great. That keeps the PC level project independent from the RT level project.  If you give a little more detail about this method, then I'll mark this thread answered!

I think I can continue to get by with shared variables if I switch to programatic access. I can string concat together the name for the shared variable and pass it into the read or write variable VIs on the Shared Variable Palette. Here's a link to the advanced shared variable documentation. It doesn't say so on the page but these VIs also accept a normal string type as the "Shared variable refnum". So that's good.

For example: ni.var.psp://my_target_number3.hightech.com/network_var_lib/network_var the red section being the target's DNS name or IP address which I will modify per each target instance.

[CoastalMaineBird · Accepted solution]

The 32 targets suggestion sounds like a nightmare I had once! ヽ(ﾟДﾟ)ﾉ

Hey it's a thought.  You can copy and paste them.  It's not QUITE as rdidiculous as it sounds. But it's not ideal obviously.

But the part where you said that you compile the RT in a separate project and deploy it on-demand sounds great. That keeps the PC level project independent from the RT level project.  If you give a little more detail about this method, then I'll mark this thread answered!

In my case it's not really in a separate project. It's the same project as the host (Win) program.  But it can be separate if you like.

Here's what I do, involving updating ONE program on ONE PXI system.  It seems to me that it can be expanded without too much trouble.

The thing is to make a Build Spec in the PXI part, that builds an RTEXE.  Take control of where it puts the RTEXE - by default it will put it in a simulation of the PXI disk folder structure (Project \ Builds \ C \  NI-RT \ STARTUP\Whatever.rtexe), or something like that).  I didn't want that, so I trimmed the destination path to put it where the Host program can more easily find it (Project \ PXI Part\Whatever.rtexe\ 

You have to figure out where on the PXI you want to put it.  If you want to leave it in the default NI-RT \ STARTUP folder, that's OK, but I didn't want to, so I had to change NI-RT.ini to point to where I put it.  Using the default is easier, and looking at it now, I think my reasons for moving were bogus. 

You can put this update logic in a Post-Build VI attached to the Build Spec (where it will update the box every time you build), or in a separate program.  That depends on how you want to deploy it.  Given that you're deploying to multiple targets, the second option is probably better.

When you want to update from version 1 to version 2, you ...

1... Send a signal to the program (it's YOUR program version 1 that's running) that it should quit.

2... Wait for a signal that it has quit, or allow it time to quit. It has to quit completely. (note 2)

3... Establish an FTP session to the box (using FTP VIs).

4... Rename the existing WHATEVER.RTEXE into WHATEVER2015.0905.0800.rtexe (make a backup copy with the date and time)

5... FTP SEND the new WHATEVER.RTEXE into the same place the old one was.

6... Send a REBOOT signal (there is a VI for this)

7... Reconnect, and ask for the program's version.

NOTE 2:  If it's the first time up, your version 1 is not running, so it cannot respond to you.  Allow for this error.

NOTE 4:  If it's the first time up, the WHATEVER may not exist on the box.  Allow for this error.

You can make whatever backup policy you want. Keep only the last 5 or don't keep any, it's up to you.

If you want to be a tad more thorough, you can check versions. My host program will keep multiple builds around (arranged by version). 

You update the box once, and check the version.

If the version isn't up to date, you update AGAIN, using the next version on the host.

You check the version again, and update until you are done.

The idea is that one version may possibly create some folder or something on the PXI that a later version needs. 

I wouldn't worry about that, until you actually need that.

That's all there is to it.  You need to look up how to do FTP sessions with VIs and how to reboot the thing.

You need to have your WHATEVER program respond to requests for VERSION number, and to QUIT.

If you have a policy where all your targets are 192.168.0.100-192.168.0.199, then you can have 100 boxes out there.

When you run the UPDATE procedure, you can find out who needs updating and who doesn't.

How to update 100 boxes IN PARALLEL AT THE SAME TIME is left as an exercise for the reader 😉

(it's doable, but probably not worth the effort).

Again, I don't know anything about how to make shared vars work this way.  I communicate with TCP connections.  It's just easier for me.  And when Shared Vars first came out, I timed them at 100x the TCP delay. (TCP = 100x as fast).  That may have improved since then, I don't know.

[natasftw]

Why would the target need to know anything about where the SVs are?  If we are wanting to reach a wide number of targets from one PC, it wouldn't make sense to host the SVs anywhere except on the targets.  At that point, you could have 32 cRIOs all hosting the variable "bob."  If your host PC allows you to enter an IP, you can reach IP\bob and read that variable on your cRIO of choice.

That's not "confining."

[Eric_Pope]

Thanks! I think that's what I needed.