Error in Get LV Class Default Value when opening default printer

[Denver_Al]

I am trying to use Easy Text Report vi to print some text to the default system printer on a Windows XP Embedded touchpanel PC.

When I run the simple VI I wrote (attached) I get a File not Found error 7 in the Get LV Class Default Value vi when New Report vi is called.

The path into the Get LV Class Default Value is odd-looking; here it is:

c:\Torqo\USB Printer Example.exe\1abvi3w\vi.lib\Utility\NIReport.llb\Standard Report\NI_Standard Report.lvclass

The first few path elements look OK - C drive and the Torqo folder I'm running from and the application name. Then it looks really odd.

I am using remote debugging onto the XP Embedded touchpanel but it has the same error if I just run the .exe on the touchpanel

I can open Internet Explorer on the touchpanel and print from it to the default system printer (It's a receipt printer from Epson).

It kind of smells like some DLL package or runtime package is not loaded on the touchpanel - but what could it be ?

I have loaded the LV 2010 Runtime Engine LVRTE2010std.exe and the VISA runtime visa503runtime.exe

My vi runs normally on the Windows XP SP3 development system with no error.

Alternately is there a simple way to imitate printf or serial port printing inside Labview, only to a USB port ?

I just need simple ASCII text sent to the USB connected printer.

Any ideas for me ?

What's with the odd Class path ?

I'm a fairly new LV programmer but a longtime Windows .NET programmer.

Thanks in advance.

[tst · Accepted solution]

I have no experience with using LV with XPe, so I can't help you there, but I can talk about the path - the EXE is basically a folder structure which has been compressed into a single file. Inside that structure, LV places the shipping VIs in a folder called 1abvi3w so that they can be refered to using a logical path (the 1337 is to avoid potential collisions).

The only thing I can suggest off hand is that you go into the build spec and explicitly include the report class in the build by adding it to the Always Include section. Theoretically, this should happen automatically when you use the class, but maybe something is working incorrectly? Maybe XPe doesn't allow paths inside EXEs or dynamic unzipping of the EXE?

If all that doesn't work, you can also change the build spec to place the report class at a specific location outside the EXE or go to the advanced page and set the build to use the 8.x-style paths, which might help you, as I believe it should usually place the report classes outside the EXE.

[Denver_Al]

First a couple of updates: The same error occurred in the .exe on WinXP SP3 as on the Touchpanel - so NOT a touchpanel or Windows XP Embedded issue. It was late Friday and I failed to build and run te EXE on the development system...

Second thanks to tst for pointing the way, the solution can be viewed at

http://digital.ni.com/public.nsf/allkb/8A0E6274D9BD7B1986256F62006AD402?OpenDocument

which talks about forcing inclusion of the class library into the .EXE file.

To me this seems like it is / should be a bug in the Build operation - if the class was in the Dependencies (it was) and the build was set for the Dependencies to Include if Referenced, the builder should include the class without making me go thru some extra steps.

Thanks for the help.

[dacad]

This condition still exists in LV 2013 loaded on Windows 7.

The knowledgebase link above addresses the fix for the issue but I agree that this seems to be a workaround and the Project should know to include these references when you use vi's that call on them.

Is this listed as a bug?

Update

After I did what the knowledgebase described, my executable more than doubled in size from ~ 6Mb to 15Mb.   Is all that really necessary?

Is there not a way to add only the files actually required for the calling vi's versus the entire population of both folders?

[Cavarval]

This is not exactly a bug but a requirement when calling VIs dynamically, in which case, it is necessary to add the VIs to the executable regardless of where is the VI from. Please check the following document under Configuring Build Specifications:

http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/build_checklist/

The LabVIEW Report Generation Toolkit's VIs are called dynamically, hence making necessary to add them into the executable manually. If you know exactly which VIs are needed, after including the folders in the project, you can just add the required VIs to the executable instead the whole library. If you miss any, the executable will not run.

[dacad]

I understand the dynamic calls and how that works, what 'bugs' me is that if LV won't add the called vi's to the project automatically, there should be a straightforward way to isolate the required vi's so you would know what to include, even if manually.  Having to include the entire folder is like calling the big dump truck to haul two shovels of dirt.

I'll do some searching but if anyone knows a way to log the vi's that are being called while the app is running and the commands the drive the dynamic calls is being used, that would be great.

[Cavarval]

As far as I know, there is no automatic way to do that, but it is possible to do it programmatically as a workaround. Please refer to the links below:

http://zone.ni.com/reference/en-XX/help/371361K-01/lvconcepts/using_labview_projects/

http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/adding_items_project/

https://decibel.ni.com/content/docs/DOC-35139

http://forums.ni.com/t5/LabVIEW/Error-when-programmatically-adding-item-to-LabVIEW-project/td-p/1225...

I didn't really test it, but the community example looks very promising. You would still need to reference the VIs though, but it should be also possible to find the path to a VI programatically and using that on the example. The following links might also be helpful for you to figure how to do that.

https://decibel.ni.com/content/docs/DOC-7658

https://decibel.ni.com/content/docs/DOC-22973