myRIO excel

[hackview]

I'm trying to use Excel sub vi's from the report generation pallette in my main Vi which has to work on ni myRIO. I use Labview myRIO 2015.

I am getting the following error details: (attached are the pictures of the errors too)

One or more of the set of VIs which this dynamic dispatch subVI or property item may call are broken. Each LabVIEW class may own a VI with the same name as a VI owned by the parent of the class or older ancestor. The dynamic dispatch subVI or property item will call one of these VIs, chosen when the subVI or property item actually executes. If any of the VIs are broken, then this subVI or property item also is broken.

My question is :

Do these Report Generation pallette Vi's not work on LabView myRIO?

If they do not work, why does Labview show them and waste the users time for a Vi that is in a myRIO Project !

Any help would be appreciated.

Cheers

[Jacobson-ni]

My understanding is that the report generation VIs use ActiveX calls to interact with Microsoft Excel so I would not expect it to work on the myRIO which is running Linux.

[mikeporter]

No they don't work. The myRIO is a real-time system -- many thing to not run on it because it is real-time. In terms of your second question, you are going to be doing development on a PC that does support report generation, so it's not exactly wasting time. Besides NI probably figures people will read the documentation...

Mike...

[hackview]

Thanks for the reply, I reckon only a few features for file saving work with the myRIO, like the write measurement file and simple file I/O. Have to try and figure out a way to use those. 

[hackview]

it is true that we do the VI development on a PC that supports report generation and in that scenerio it would be totally logical for the user to have all the functions.

However, it would be cool if NI had a way of automaically supressing Vi's / functions that are not supported in myRIO while designing in a myRIO project setting as this would make the programming much more clearer, as the user would automtically have only the supported features, leaving the the other ones out. 

[Bob_Schor]

You are confusing Software (code) with Hardware (where the code runs).  LabVIEW Project allows you to develop programs that can run on multiple platforms, such as the Host PC, a PC running a Real Time OS, a RIO running some flavor of Linux, even FPGA.  One nice thing about LabVIEW is that the basic code structure doesn't change -- the Developer can write the same For loop to control the repetetive execution of, say, array functions and deploy this to multiple hardware/OS targets.  The Development system doesn't know (or care) what Target you might use to deploy the code, hence makes tools and functions available that might not run on a particular platform, depending on the Developer to "know the difference" (for example, you wouldn't use FPGA code on a Windows PC deployment).

What you are observing is a Feature, not a bug.

Bob Schor

[Jacobson-ni]

I'm not sure how difficult it would be to not have the report generation toolkit show up when it is in the context of an RT target but the palettes do change depending on what context you are in (FPGA targets give you a very different palette). If it isn't already, I would put it on the idea exchange at least.

[Hooovahh]

As you've discovered not all toolkits work on all palletes.  Ones that rely on ActiveX aren't going to work on an RT target.  But what you can do is send data to a host to be logged, or log locally using a method that is supported.  Using the write to spreadsheet will make a CSV file that can be opened in excel but lacks some of the report like features you might be expected.  One alternative might be to look into the XLR8 toolkit, which reads and writes excel files using file I/O primitives instead of ActiveX.

http://sine.ni.com/nips/cds/view/p/lang/en/nid/212056

[Bob_Schor]

Yes, you could do these things, but one point of a LabVIEW RT system is that there are (usually) two connected systems, the Host PC, with keyboard, display, large(r) hard drive, Internet connection, etc. that "Runs Windows and Plays Well with Users", and an RT system that is fast, deterministic, does not run Windows, but talks (usually via TCP/IP) with the Host.  The Host is optimized for doing File I/O, interacting with Excel and databases, etc., while the Remote is optimized for getting and not "losing" the data.  Under this model, handing the data to the Host for doing "fancy file I/O" is in keeping with its mission, it seems to me ...

BS