Using plug-in VIs on PXI RT Controller

[CoastalMaineBird]

LabVIEW 8.2 and RT 8.2.

My app collects 250-300 channels of signals at 10 Hz. SCXI, Digital IN, Counter, TCP instruments, CAN, you name it.

It uses "plug-in" VIs - VIs that the user creates in a particular folder and that perform particular calculations during a test.

For example, one plug-in might take the SPEED measurement and the TORQUE measurement and produce a POWER measurement, at each sample (10 Hz).

From then on, the POWER signal is just another channel to the user; he can graph it, record it, set alarms on it, just as if it were a measured channel.

I have a mechanism to sort these out and execute them in the correct order. If some other plug-in needed POWER as an input, then it's important that the POWER plug-in runs BEFORE the one that uses the POWER value.

Currently, the DAQ cards are all PCI, on the host, and that all works 100%.

Now we are moving all the DAQ stuff to PXI. I have all the types (except CAN) working there, and now I need to move the plug-in types over. As part of this, I need to send the actual VI files from the host to the PXI for execution, just before the test.

I am looking to minimize the amount of disk writing I have to do, and the time it takes to prepare thes things for the test.

---- QUESTIONS ----

1. Is there a way to avoid writing the VI to actual disk storage? Since the code has to reside in RAM anyway, and I don't need the front panel, can I accept the VI file (via TCP connection), and tell the VI server to execute this chunk?

   I seriously doubt this, but thoughts are welcome.

2. Is there a RAM DISK for PXI that I could store the plug-ins on?
3. The plug-ins might use other VIs for things like units conversion. These support VIs might or might not be already in memory at the time of plug-in loading. In either case, the path will be different from the path that the plug-in used on the host. What kind of problems will that cause?

   If necessary, I could establish a static reference to these support VIs, I think that will eliminate the searching that it might otherwise have to do?

4. Does LV have to re-compile a VI when it is moved from the host (windows) to the PXI box?
5. Would it make sense to implement some sort of hash/checksum thing to check if the plug-in on the host is different from the plug-in on the PXI, and only go thru this transmit / store / re-compile / store cycle if absolutely necessary? IOW when the plug-in has actually changed?

Thoughts?

[CoastalMaineBird]

Anybody?

[Nadim R]

Hi,

1. Is there a way to avoid writing the VI to actual disk storage? Since the code has to reside in RAM anyway, and I don't need the front panel, can I accept the VI file (via TCP connection), and tell the VI server to execute this chunk?
   The VI will have to reside on the disk, however data structures, such as arrays will reside in your volatile memory until written to disk.  If you are worried about speed and performance issues if you do open up the front panel on a remote system, I would use Remote Front Panels, which will connect to your FP on the target via http.  Here's a link as to how to do remote front panels. 
   
   
   
2. Is there a RAM DISK for PXI that I could store the plug-ins on?
   I am not sure what you mean by RAM Disk, but I do not think that our PXI systems have that.  The VIs will have to reside on the HD.
   
   
3. The plug-ins might use other VIs for things like units conversion. These support VIs might or might not be already in memory at the time of plug-in loading. In either case, the path will be different from the path that the plug-in used on the host. What kind of problems will that cause?  If necessary, I could establish a static reference to these support VIs, I think that will eliminate the searching that it might otherwise have to do?
   Path problems may occur if your do not save your files with the same path directories on the PXI system.  This is why people usually use executables, which then include those VIs that are loaded dynamically. 
   
   
4. Does LV have to re-compile a VI when it is moved from the host (windows) to the PXI box?
   No, when you deploy your VI to the target, the target will not need to recompile the VI.
   
5. Would it make sense to implement some sort of hash/checksum thing to check if the plug-in on the host is different from the plug-in on the PXI, and only go thru this transmit / store / re-compile / store cycle if absolutely necessary? IOW when the plug-in has actually changed?
   This question depends on your application.  If you are worried that the VIs on the target will be different from the VIs on the host, then yes.  There are a few ways to do this.  One way would be to have your host programmatically download the VIs and then use the Compare VIs tool.  Another way would be to programmatically check the file size on the target vs the host.

I hope this helps,

Regards

Nadim
Applications Engineering
National Instruments

[CoastalMaineBird]

The VI will have to reside on the disk,

I had expected that, as I see no VI SERVER functions except using PATHs.

---

I am not sure what you mean by RAM Disk,

A RAM disk is a piece of software that acts like a disk driver. It uses a chunk of RAM, and sets up a file system on it. You can then address it as any other drive: make folders, read and write files, etc. Programs don't know the difference, but the speed is much faster. Of course it's volatile when power goes off.

---

Path problems may occur if your do not save your files with the same path directories on the PXI system.

Actually, I'm already part way down this road. The VIs that were already in memory were found easily by the plug-ins. Others were not found at all, until I included a STATIC VI REFERENCE in the main code, to force those to be loaded as well.

---

This is why people usually use executables, which then include those VIs that are loaded dynamically.

That's fine for a finished product, and I intend to do that, but for development, it's way more hassle than I need.

No, when you deploy your VI to the target, the target will not need to recompile the VI.

OK, good to know. I hadn't tested this. I was afraid that loading the VI would cause a re-compile. I could have gotten around it by storing the VI again, I suppose, but it's nice to know I don't have to.

---

If you are worried that the VIs on the target will be different from the VIs on the host, then yes. There are a few ways to do this. One way would be to have your host programmatically download the VIs and then use the Compare VIs tool. Another way would be to programmatically check the file size on the target vs the host.

I didn't know the COMPARE VI tool was available programmatically.

I have implemented this with a HASH function to detect differences. The FILE SIZE idea is not good enough, in the case that somebody changes a constant from 3.2 to 6.9. The hash will detect any changes.

So the host sends a VI name, and a HASH value to the RT. The RT checks its local copy of the VI, and its local copy of the HASH value. If the VI doesn't exist, or the HASH value is different, the download occurs, otherwise it's not necessary, and I've saved some wear and tear on the disk, and a few mSec as well.

Thanks for your help.