06-22-2016 11:56 PM
Its a LV2012 application for a machine control deployed on a WIN7 PC ( 32 Bit) . Uses the DAQMx drivers for AI/AO/DI
Code running well in Design mode on any pc and also as an executable on my laptop ( WIN10) on which it was developed and compiled.
But when running on the client PC the excutable throws up the Error 2208 when a Test Report VI is run. The snippet is as below :
I searched the forum and came to know that .NET3.5 inclusion might help. Yet to try that as teh client machine is not available. In the emanwhile i right clicked the Virtual Project folder and chose the options of Items with no callers and Items incorrectly claimed by library
I was stunned to get a huge list in each case ( attached ) and without understanding i am scared to delete any of the files therein.
What do these two lists mean and are these causing my woes ? Is it OK to delete them as they seem to be useless anyway ( for this project that is !)
06-23-2016 02:22 AM
06-23-2016 05:29 AM
First : The Code is just to read from a cluster and print it on to a pre formatted test report.( The FP of which is a bit of a problem to share publicly.) The only function worth its name is the Easy Print.VI as you can see from the First stack of the Print value change event once you paste the snippet to a block diagnram.
Second : The error message as i told in the begining, happens ONLY in run time with a cryptic message saying it needs a Full Development System to fix. Nothing more.
Third : No idea which VI is offending. In any case it runs fine in both modes ( Design and Executable) on my PC and in Design mode on the client PC. Its only the Run time + Client PC that is a problem. So obviously the code is NOT the culprit ??
Fourth : I should not be worried about the list ? Fine - but what are these files doing in my project for which LV itself accepts there is no need ?
06-23-2016 06:23 PM
It looks like you are using the Report Generation Toolkit. That library actually calls things dynamically, so they will not be included in your executable. We found that you need to include the LVClass folder and NIReport.llb from vi.lib in your project and use the "Always Include" option in the executable build.
06-24-2016 02:03 AM
@crossrulz wrote:It looks like you are using the Report Generation Toolkit. That library actually calls things dynamically, so they will not be included in your executable. We found that you need to include the LVClass folder and NIReport.llb from vi.lib in your project and use the "Always Include" option in the executable build.
Thanks. Unfortunatley the Search in my laptop does not seem to work ( trying a fix for that !!)
So searched for teh folder and LLB you mentioned in C:\Program Files(x86) \ National Instruments and sub folders liek LV2012 , Shared Folders etc. . No luck.
Where exactly to locate them ??
06-26-2016 02:55 AM - edited 06-26-2016 02:55 AM
>> We found that you need to include the LVClass folder and NIReport.llb from vi.lib in your project and use the "Always Include" option in the executable build.
Located the above in the Dependencies folder. But cannot figure out a way to "Älways Include" them in the build. 😞
06-26-2016 12:49 PM
A couple of comments.
This code was largely developed in LabVIEW 2012, but about a year ago was migrated to LabVIEW 2014 (on a Windows 7 system). I can't absolutely say for sure whether I could simply use the Top Level VI in the LabVIEW 2012 version -- I think that was the case, but I certainly do not need to specify it in LabVIEW 2014.
Bob Schor
06-26-2016 11:19 PM
Hmmm
@Bob_Schor wrote:A couple of comments.
- LabVIEW 2015, I believe, is the only currently-available Version of LabVIEW certified for Windows 10. If you are developing using LabVIEW 2012, it just might not work!
- I have several projects that use the Report Generation Toolkit. When I build an executable, I do not need to do anything special, in particular, I do not need to put anything in the Always Include section of the Source Files in Build. Indeed, the only thing listed is the Top Level VI in Startup VIs (of course, it calls everything else, including the routines that call on the RGT).
This code was largely developed in LabVIEW 2012, but about a year ago was migrated to LabVIEW 2014 (on a Windows 7 system). I can't absolutely say for sure whether I could simply use the Top Level VI in the LabVIEW 2012 version -- I think that was the case, but I certainly do not need to specify it in LabVIEW 2014.
Bob Schor
Hmmm.... so its getting to that dreaded point. While the original Executable was made on a Win 7 machine, the revisions and quite a lot of them happened on Win 10 machine. The problem now really is the availablity of the Win 7 to do a recompile. Anyway if thats what will solev ethe issue will attamept that.
And just for inofrmation, installing .Net 3.5 did not help. ( There are other threads which suggest this as a solution )