LabVIEW classes and mass compile

Just wondering if anyone out there has found any problems mass compiling LabVIEW classes, as I am having what appears to be totally un-resolvable issues - I get a list of VIs that either say BadsubVI or BadVI all of which I have verified are error free.
The only thing I can round it down to is the use of the lvclasses, and in particular the fact that I'm making extensive use of the inheritance functionality, and also a few override vi's.
It wouldn't be such an issue except that I'm calling some of these vi's from TestStand, and am unable to get a deployment to work without a successful mass compile.
Appreciate any responses,
David Clark
CLA | CTA
CLA Design Ltd
Hampshire, England

I'm not sure if it's the same problem but I had a vi that would compile into an unrunable exe. I found the problem by mass compiling the project, which came up with a bad vi and bad subvi's that used that vi. Turns out my problem was that I had two classes with the same name (even though they were in separate lvlibs). And renaming one corrected my problem. LabVIEW 8.5 gives a warning and renames the compiled vi's (so if you could try 8.5, that might help you find the problem quicker assuming it's related). It seems to me that the name spaces provided by lvlibs go away when compiled into an exe or by the mass compiler (It may just affect lvlclasses).
Matt

Similar Messages

Mofcomp.exe failed, delete the classes and retry compiling, 0x8004400a unexpected token at file scope, Primary DP will not validate

I have SCCM 2012 R2 CU3. Before when I've had DP problems it was always with secondary DPs. Now I've got an issue with my primary DP. Content will not validate on the main DP, called DP1. In Monitoring Distribution Point Configuration Status there are repeated
errors about "Failed to validate package ABC12345\\fqdn". On the site server in distmgr.log this entry repeats over and over:
"Mofcomp.exe failed, delete the classes and retry compiling E:\program files\microsoft configuration manager\bin\64\smsdpprov.mof
Failed to compile MOF file. Error code 2."
The problem is I don't know what classes it's talking about, nor how to delete them, nor can I find anything directly applicable about this error. I did run "mofcomp.exe smsdpprov.mof" anyway but I get the error "error syntax 0x8004400a: unexpected
token at file scope. Compiler returned error 0x8004400a."
This DP1 was working fine until a few days ago. We haven't made any upgrades/changes to the server either.
We sent a package just to DP1 and it did deploy the content, so it appears that it just can't validate.
Thanks for any help.
Ben JohnsonWY

Hi,
About the error in Mpcontrol.log, you could try to uninstall the MP, reinstall IIS components, then install MP to see if it can resolve this issue.
If not, please have a look at the following blogs.
Support Tip: ConfigMgr 2012 Management Point fails
with a 500 error after working fine for a short period of time
SCCM MP Internal Server Error ISS Call to HttpSendRequestSync
failed for port 80 with status code 500
From you description above, you reinstalled the DP. Did you reinstall the IIS components during the DP reinstallation? If not, please try to reinstall the IIS components.
Best Regards,
Joyce
We
are trying to better understand customer views on social support experience, so your participation in this
interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place.

LabVIEW crashes during mass compilation every time

Hello All
I have installed a new LabVIEW 7.1 from February on Win XP.
Every time when I try to mass compile LabVIEW, after few files it crashes, and only one thing I can do is to send a report to Microsoft.
It looks like it crashes in a moment when it can not find a subvi in the directory structure.
What is wrong with it?
Thanks in advance.
Pawel

I hope you are not trying to mass compile the entire LabVIEW directory. I will definately choke on several of the files it will find. If you have upgraded to 7.1.1, you should mass compile the vi.lib, instr.lib, user.lib and examples directories.
You could also have an error with the Paths settings. If it is searching an invalid path to find a subvi, that might cause the problem.
I suggest that you start small and try a single subdirectory like user.lib, then move on to instr.lib, then examples.
Michael Munroe, ABCDEF
Certified LabVIEW Developer, MCP
Find and fix bad VI Properties with Property Inspector

I try to convert LAbview 2.2 VI to Labview 3.1 for MAc using the conversion Kit. Labview 3.1 mass compile cannot find several VI like "open file, open folder, wait(ms), al_config"e.t.c. How can I manage this problem?

It looks like Labview 3.1 has different names for these VI.

It has been a very long time since I worked with such an old version but version 3 was a major upgrade that made the MAC and Windows versions much more compatible. One of the changes was to make the VI names the same on both platforms and another was to make the locations the same (i.e. the name of the llb that the functions were stored in. You should be able to find the equivalent functions in 3.1. Open the app in 3.1 and when prompted to find a VI, browse around until you find it. If you have a list of the VIs that couldn't be found, before opening the old app, create a new VI. Use the palette to find the functions and place them on the diagram. Then, when you open the old VI, those functions with the same name will get replaced by the new ones. For ones w
hose name changed, you'll have to manually replace those one by one. I also seem to remember a compatibility llb that was available back then. It was a set of VIs that was not part of version 3. I have no clue as to whether it's still available from NI and whether it included everything you might need. The good news is that once you're past this conversion, upgrading becomes a lot easier.

Command line: Mass compile and LLB Conversion

Using LabView 8
Using a script (Perl or VBScript) I would like to extract some VI from our source control,
mass compile them to be to the current LabView version and then create a LLB from that directory.
The need for this is to have a synchonisation between 2 applications.
Since this needs to be done from a script, I need a way to perform this from the command line.
(The other solution we have, is to perform this manually every time a modification is made to the original files,
But sometimes memory can be defective and then .... )
Any suggestions, ideas...
Thanks
EricG

Eric,
That sounds like quite an undertaking, but I think you might be able to implement it (or at least most of it). LabVIEW does not have command line arguments for all that you want to do, so I would recommend building a VI that does what you want and then building that VI into an executable that utilizes command line arguments.
In this VI, opening VIs and mass compiling them can be accomplished through VI Server in the form of an Invoke Node -- these functions are methods under the Application class. Bear in mind that mass compiling can only bring VIs forward in versioning, not backward. For the LLB functions, you can use the Libraryn VIs that ship with LabVIEW -- they are "hidden" in the LabVIEW root directory under vi.lib/Utility/libraryn and are pretty intuitive. As far as the source code control, you are on your own, as that will be dependent on the specific SCC software you are using and will most likely require using ActiveX.
Once you have a VI built that does everything you want and you are ready to build it into an executable, you will want to configure it to accept command line arguments. There is a great online Knowledgebase on this subject, which I have linked here. And of course, if you run into any specific problems along the way you can get help from this great online community!
Best of luck!
E. Sulzer
Applications Engineer
National Instruments

Internet Toolkit for G5.0 crashes Labview 8.2 during Mass Compile

I have just received my Labview 8.2 update and installed it my system along with all my toolkits. When I tried to Mass Compile Labview 8.2 directory I found that it would crash labview consistantly as shown in the attached image.
I traced this to the vi's supplied with the Internet Toolkit for G5.0.
The workaround is ...
1. Re-installed the Internet Toolkit for G5.0 into Labview 8.2
2. Mass Compiled ...\project\_config\authcfg.llb using Labview 8.0
3. Mass Compiled ...\project\_config\authcfg.llb using Labview 8.2
and there wasn't any more Labview 8.2 crashes during mass compile. As Labview 8.0 was able to mass compile the internet toolkit vi's without crashing I am suspicious that Labview 8.2 might not be completely compatible with Labview 5.0.
I posted this just in case anyone else sees a similiar issue.
David
Attachments:
Labview 8.2 Mass Compile Crash with Internet Toolkit.png ‏34 KB

David,
I was able to reproduce the crash mass compiling authcfg.llb or just trying to open the VI named 'Directory Configuration'. That code is saved in LabVIEW 5.0.1 and must have something that LabVIEW 8.2 chokes on, I'll have to get someone to investigate it. Your workaround of saving that .llb or even that one VI in 8.0 first (or probably even 7.x) is the only way I see around it with 8.2.
I do want to mention that in Q1 2004 we released version 6.0 of the Internet Toolkit and it does not exhibit this behavior. So the official solution for this crash is to upgrade to the latest Internet Toolkit.
Kennon

How to get a LabVIEW class object to expose an invoke-node method?

Hi,
      I like the property/invoke-node "paradigm" used for interacting with "objects". Can LabVIEW-class objects expose their properties and methods this way? Can one or more LabVIEW-class objects be compiled into a library or "assembly" (or other distrubution format) that allows the property/invoke-node usage?
I've looked at (but not completely understood) "Creating LabVIEW Classes". Have also searched for related posts.
The pic below shows an invoke node wired to a class with a Public VI "VAT.Status.Hello.vi". I'd like to see VAT.Status.Hello show-up as a Method. (I just tried "Select Method", and selected "VAT.Status.Hello.vi" but dialog's "OK" button stays greyed-out.)
Cheers.
Message Edited by tbd on 03-29-2007 03:15 PM
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Attachments:
VATStat.JPG ‏54 KB

Hi Aristos,
      Thanks for the reply!  It was a bit dissappointing, though.
It appears the LabVIEW-class object will be moving away from (what seems to me) a convenient object-interface presented by the invoke-node/method paradigm - which allows us to interface with a large set of "objects" (.NET, ActiveX, LabVIEW GUI, VISA Resource, ?) in a similar manner and independent of the object's origin. Being able to read the methods and parameters that appear in these nodes is also helpful for understanding diagram logic!
I do like the option of dropping a friendly "VI looking" icon on the diagram, but perhaps an optional - even default - VI-icon representation for a class-object invoke-node is feasible - so the LabVIEW class-object could be the more generic object first, but with a traditional-G representation(?)
Given the answer "We would like, someday, to support the property node"
and "in the next version of LV, wiring the LV class to the property/invoke nodes will break the wire so we'll avoid confusion in the future",
... I guess you'll break the wire in the next version, but (perhaps) allow it again - if support of the property node is ever implemented?
Regards.
P.S. For the record, huge THANKS to whoever it was that straightened-out enumerated-types (somewhere) between LV4.1 and LV6.1.  Every time I add or remove an enumeration in a typedef, I silently give thanks to the bright and thoughtful soul(s) who made this valuable tool work so well!
Hello. This is your friendly neighborhood R&D guy for LabVIEW classes.
Regarding your request about property and invoke nodes as relates to LV classes....
Short story: We would like, someday, to support the property node. We have no intention of ever supporting the invoke node.
Long story: As we were creating LV classes, we had to evaluate the right programming interface for these things. We wanted LV classes to behave as new data types in LV. A developer should be able to create a LV class, then give it to someone who doesn't even know OO programming, and that second programmer could use the new data type without learning a lot of new concepts. From this principle, we held fast to the idea that the programming interface should be subVI calls whereever possible. The invoke node is really nothing more than a VI minus the icon. If you want, you can popup on any subvi node and uncheck the option "View as Icon". This will make the node display in a way that has the terminals listed as text, like the invoke node. So, at the end of the day, the invoke node is simply a subroutine call in LV that is language dependent, as opposed to the language independent iconography of LV generally.
The property node is a slightly different story -- the functionality of a property node is actually different than an invoke node as its terminals are various subsets of the properties available, not a fixed list of parameters like the invoke node. The property node provides a nice interface for setting multiple properties in a block and only having to check a single error return. Very friendly. Our intent is to allow you to create a VI that has 5 terminals: object in, object out, error in, error out, and either a single input or a single output of your chosen type. VIs with this conpane could be marked as "properties" of the class and would show up when you wire the class wire to the property node. We would call the subVIs behind the scenes as needed to get/set the properties.
This is on the longer term roadmap because it is "syntactic sugar" -- it sweetens the programming style, but it is not necessary to program effectively. You can get the same effect by writing those same VIs and stringing them along on a block diagram "railroad track" style. We'll probably get around to it in three or four versions of LV -- there are some major user requests that impact functionality that have to get done first.
PS -- in the next version of LV, wiring the LV class to the property/invoke nodes will break the wire so we'll avoid confusion in the future of people thinking there's a way to use these nodes.
Message Edited by Aristos Queue on 04-02-2007 09:56 AM
Message Edited by tbd on 04-03-2007 12:39 PM
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)

Mass compile operation keeps on looping

hi,
when i do a mass compile on my project , it keeps on looping during a save operation
and it does that may be a 50 times & eventually ends also without error.
the curent file remains the same
Attachments:
mass-compile-loop.PNG ‏15 KB

Just as TiTou said: it looks like recompiling each VI which depend on any class hierarchy makes LV recompile each VI of this hierarchy, and then each VI of this class makes recompilation of each other VI, etc... As a workaround you can try closing the project and mass compile project folder from Tools->Advanced menu. I noticed this does not loop as much as there are not all dependencies loaded, but there are many more factors to this (i.e. how you managed libraries and classes dependencies). Furthermore, this might not give you exactly the same effect as mass compiling the project (same reason - not all dependencies are loaded).

Save Labview Class to file?

Hi there,
I am playing around with the new Labview classes and i am thinking working with classes is pretty cool.
But i am not able to save the objekt to a binary file load them and use this data to initialize the Object with this data.
Its no problem write the state of Class to a binary file oder flatten the state to XML.
But i got a lot of troubles load them back.

I changed the example so that it works.
Please have a look.
Attachments:
saveclassdata.zip ‏37 KB

Complete hardware simulation using LabView, Multisim, and MAX (easy answer accepted!)

Hello, all!
Sorry, I'm new, but I've checked around for a definitive answer on this, but I'm not 100% sure. I'm learning LabView for an upper-division Physics class. We're using NI hardware (DAQ-MX) and a mix of lab hardware - primarily basic stuff such as voltmeters, oscilloscopes, and breadboards with simple components. I'm also doing some work with NIM instrumentation, but that's secondary to my needs here. So, when I'm away from school, is it possible to do a complete simulation of my classwork using LabView, Multisim (for my breadboard), and the Measure and Automation Explorer (for the DAQ-MX)? I know that I can create a circuit and drop it into Labview, but I'm not so sure about the DAQ. I'm hoping for something that's a "seamless" recreation of what I'm doing in class. I can take a simple "yes" or "no"; as long as I know that it's possible, I can look for the solution.
Thanks for the help!
Solved!
Go to Solution.

I have an easy answer and a harder answer:
Easy Answer
You can simulate almost any NI instrument in MAX. Right click the Devices and Interfaces item in the left pane and select Create New... Unfortunately, this limits you to whatever the driver designer thought would be a good signal. It is good for simple testing, but you will rapidly run into its limitations.
Harder Answer
Use LabVIEW classes to make a hardware abstraction layer. This my seem like an advanced topic for a beginning LabVIEW programmer, and it is, but it also neatly solves the problem of switching between simulation VIs and real acquisition VIs without writing a bunch of switching code. In short, you create a LabVIEW class which has the interface you want for you data acquisition. This can be your simulation code. You then create a child class which has exactly the same interface, but uses the DAQmx/NI-SCOPE/NI-DMM/etc. that you really want to use. Switching between the two is as simple as selection the class you want to use at run time. This is a lot of info in a short time. If you want to go this route, read the LabVIEW help on LabVIEW classes and work through the examples. I would encourage you to do this, since the sooner you learn how to effectively use object-oriented LabVIEW, the easier your life will be.
As a further bit of information, most of the measurement instrument groups (e.g. NI-SCOPE, NI-FGEN, NI-DMM, etc.) allow you to simulate an instrument if you use the open with options VI instead of the standard open VI. The inputs are rather arcane, but get the job done.
Let us know if you have further questions.
This account is no longer active. Contact ShadesOfGray for current posts and information.

LabVIEW 8.0.1 on Windows 8 wants to mass compile every time I start it?

My Windows 7 machine took a dump and I installed LabVIEW 8.0 on a new Windows 8 machine. I then installed the 8.0.1 upgrade and did the mass compile. I then installed NIVPM and attempted to install the openG package which some of my vis depend on. Only a few of the openG modules installed without dependency issues or somesuch. Now every time I start LabVIEW it is as if I never did the mass compile and it wants to do it all over again. I don't recall having any such issue when I installed labVIEW in Win7 (or Vista, or XP). Am I missing something? Can someone help... please???
In case it matters the machine is an HP Pavillion G7-2240US laptop, Intel Core i32370M @ 2.4 GHz, 6.00 GB RAM

OK, I get it. You are irritated that you can't do something you wanted to do. I can't understand what bug you are talking about. LV8 doesn't run on Win8? That's not a bug. By your logic I should be able to dig out the old V4 disks I have laying around and run them on my Win7 computer. Or better yet, I still have an old Mac488 GPIB interface box made by IOTech. Should I be expecting NI to come out with DAQmx drivers for it? They did after all buy out the company.
I got two words for you: obsolete happens. V8 was a good version in its day, but its day was 6 years ago. Someday LV2013 will be obsolete - heck someday you will be obsolete. It just happens, so my suggestion is to go buy yourself a pair of big-boy pants and stop whining.
Mike...
PS: If you found any of what I just said offensive, please reread my last suggestion.
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Upgrade labview project that has classes and subVi's

We have a LabVIEW project in LV 8.5( freated by a different developer) that has classes, and various Vi's , subVi's.
I am looking to upgrade it to LV 2014. To be safe, I wanto to copy everthing into new classes( renamed from old ones), rename all the Vis( I hav ealready done that in Windows explorere, though not yet added them to project), and use them with renamed subVI's.
The old classes and VI's should remain in the same folder.
What is best way to do that?
I found something here
https://lavag.org/topic/17741-the-nightmare-that-is-renaming-a-class-and-its-folder/
but this basically suggests many methods, and then, would delete the old structure.
Also, what happens to the "controls" that show up under "private" folder?
I have never worked with LV classes, so pardon any lack of knowledge.
sed_y

4) All the subVI's that are being used and reside in different directories, will be made copy of into their own subdirectories, with the originals zipped.
That's the one you need to be careful of. If you have any shared code or re-use libraries outside of the project folder then these will get loaded and saved in LV2014. Use the 'files' tab of the project folder to see which files aren't in your project subdirectory.
Anything that is in user.lib you can copy from the 8.5 user.lib to the LV2014 user.lib folder and your project will automatically find them.
There are some useful tips here about working with LabVIEW projects and keeping all of your code in sensible locations. Anything relating to your project should be within the project subfolder and any shared code should go in the respective user.lib/vi.lib of the appropriate LabVIEW version - this does mean that you have a copy of the VI for each version of LabVIEW so you will need to be careful about making sure if you change it in one version you change it in the other. Even better still is to make your shared code into VI packages - then you can install them for any LabVIEW version and it will automatically save/compile them for the appropriate version. We used to have all of our re-use code in user.lib but it made moving between LabVIEW versions a pain so we started using VI packages and haven't looked back.
Certified LabVIEW Architect, Certified TestStand Developer
NI Days (and A&DF): 2010, 2011, 2013, 2014
NI Week: 2012, 2014
Knowledgeable in all things Giant Tetris and WebSockets

Problems with mass compiling for LabVIEW 6.0.2

When mass compiling the LabVIEW folder after installing 6.0.2, I get a Log file telling me "Bad VI" for 8866 vi:s. Have looked specifically at two of them, and the broken arrows are fixed by pressing and clicking the broken arrow. Somehow I don't feel like doing this for 8866 vi:s.
What is wrong, and how do I fix it?
Attaching the Log.
//Martin
Attachments:
MassCompileLog ‏1263 KB

Yes, it definitely appears as though you need to reinstall NI-DAQ. You can receive this error when the VIs which are being mass compiled depend upon other VIs which are either not present or have been incorrectly updated. Make sure that you have installed NI-DAQ support for your new version of LabVIEW. This is separate from installed NI-DAQ by itself. You must install the LabVIEW support files also. You can get these off of NI's website.
Also, if you did a complete install of LabVIEW, you may have installed a newer version of NI-DAQ without realizing it. This could cause a problem if there are two versions of NI-DAQ on your computer. Make sure you only have one version.
J.R. Allen

Problem with combination of LabVIEW classes (dynamic dispatch), statechart module and FPGA module

SITUATION:
- I am developing a plug-in-based software with plug-ins based on LabVIEW classes which are instanced at run-time. The actual plug-in classes are derived from generic plug-in classes that define the interfaces to the instancing VI and may provide basic functionality. This means that many of the classes' methods are dynamic dispatch and methods of child classes may even call the parent method.
- Top-level plug-ins (those directly accessed by the main VI) each have a run method that drives a plug-in-specific statechart.
- The statechart of the data acquisition plug-in class (DAQ class) calls a method of the DAQ class that reads in data from a NI FPGA card and passes it on to another component via a queue.
PROBLEM:
- At higher sampling rates, an FPGA-to-host FIFO overflow occurs after some time. When I "burden" the system just by moving a Firefox browser window over the screen, the overflow is immediately triggered. I did not have this kind of problem in an older software, where I was also reading from an FPGA FIFO, but did not make use of LabVIEW classes or statecharts.
TRIED SOLUTIONS (WITHOUT SUCCESS):
- I put the statechart into a timed loop (instead of a simple while loop) which I assigned specifically to an own core (I have a quad-core processor), while I left all the other loops of my application (there are many of them) in simple while loops. The FIFO overflow still does occur, however.
QUESTION:
- Does anybody have a hint how I could tackle this problem? What could be the cause: the dynamic dispatch methods, the DAQ statechart or just the fact that I have a large number of loops? However, I can hardly change the fact that I have dynamic dispatch methods because that's the very core of my architecture...
Any hints are greatly appreciated!
Message Edited by dlanger on 06-25-2009 04:18 AM
Message Edited by dlanger on 06-25-2009 04:19 AM
Solved!
Go to Solution.

I now changed the execution priority of all the VIs involved in reading from the FPGA FIFO to "time critical priority (highest)". This seems to improve the situation very much: so far I did not get a FIFO overflow anymore, even when I move around windows on the screen. I hope it stays like this...

Compiling Nested Classes and Interfaces

I am looking for documentation about compiling nested classes and interfaces. I have found something in the JVM Specification, but there does not explain how a nested class is compiled and what is included in the top level class to mark a "place holder" to the nested class. The JVM Specification in this topic cite the web page http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclasses.doc.html that does not exists any more.
My root problem is that: I am compiling a class with a private nested class, but in the class file generated TopLevelClass$NestedClass.class the class does not have the private modifier. So I am not understanding why the "private" modifier was removed during compilation.
I performed the same test with a protected nested class and the result was the nested class with the public modifier. So I am not understanding why the "protected" modifier was changed to "public".
Thanks in advance,
Mardoqueu.

This should not be happening. What compiler are you using? If it's a reasonably recent Sun compiler, could you post a minimal example?

LabVIEW classes and mass compile

Similar Messages

Maybe you are looking for