Mike Le

Don't know if this is the right place to ask this, but I wasn't able to make it out to the CLA Summit this year. I noticed some presentations are being posted over to the NI Community, but sort of randomly. Anyone know how long it usually takes for all the presentations to be up there? (If all the presentations usually get uploaded at all...) Thanks.

Hey, just started using GOOP. Super happy with it so far and glad it's become an NI-official addon! I'm brand new to it, and I'm running into a problem using "Add Method" on an Actor. I select Override Method --> Actor Core -->GUI and Event Structure Template. When I attempt to create the method, the IDE crashes with the following error: I'm using LV2013SP1 and GOOP 4.7. I'm running GOOP from the project window. I can also see that the Actor Core.vi gets created and is placed in the correct folder, but hasn't been assigned to be a member of the class library. Any idea what's going wrong? Things I should try? In the meantime, I'm just going to create the override the old-fashioned way. Thanks.

Somehow I was able to get the result I wanted by the following procedure / magical ritual: Disconnected the typedef from the library. Saved ONLY the Enum .ctl file. Reopened the project, which now cannot find the .ctl file because it isn't part of the library as expected. Pointed LabVIEW to the exact same file location for the .ctl file. LabVIEW prompted me, warning me that there's a mismatch because the library was expecting the .ctl file to be part of the library, but the .ctl file wasn't expecting to be. Selected the option to resolve it in favor of disconnecting the .ctl from the library. Waited for the entire project to load, then checked the ~155 instances of the enum throughout the project. Found that none had been reset. Having to document every instance of the enum is sort of ridiculous. At that point, I think I'd rather use OpenG "select enum value by string name" primitive and implement Darin's "dare to dream" scenario. But that seems like it'd cause a ton of needless overhead...

I'm using LabVIEW 2013SP1 and am running into a similar issue. My compiled code is NOT separated from my VIs. I am trying to remove an Enum typedef (non-strict) from a class library. From the project window, I right-click on the typedef and select "Remove from library." Every time I've done this, it causes ALL the typdef's BD constants to revert to the default "0" value. This is enormously problematic, obviously. Clearing the compiled object cache as suggested here does NOT resolve the problem. I'm forced to revert to the earlier copy on source code control. But it's vital that I am able to remove the enumerated constant to untangle some undesirable code dependencies. Anyone have other troubleshooting suggestions?

Thanks for that, Ton. That makes sense. I do wish there were a level that combined 2D Charts and Graphs, though. They share so much common functionality and are a bit more common than the 3D examples (at least in my experience).

I'm creating some Subpanel Actors to act as reusable plotters. One of the things I'm doing is splitting from a parent class into two concrete instances, one containing a Chart and one containing a Graph. There are some abstract methods common to both Actors that could theoretically be handled in the parent class, except they require access to control properties like ActivePlot, Plot.Name, Plot.Visible, etc. I tried using a generic GraphChart reference, but found that it doesn't give access to these properties. You have to pass in a Chart OR a Graph reference. My solution has been to put the code into the concrete methods, but I find myself with essentially identical code in two places, accessing identically named properties, except with either a Chart or Graph property node. Does anyone know why the GraphChart doesn't have access to these properties? Anyone have a more elegant workaround? Thanks.

I'm traveling right now, but normally I'm based out of San Diego. I'll be returning in about 4 months. Before I left, there was a local LabVIEW User Group Meeting every 3-4 months. The level of discussion wasn't especially high and there weren't many "regular faces." People would show up, realize that the meetings weren't particularly educational/productive, and never come back. It also doesn't help that the meetings are somewhat irregular. In fact, I heard that a few months ago the San Diego group was putting the meetings on indefinite hiatus. I think there are certain "hotbeds" for LabVIEW development where active communities are taken for granted. Places like Austin or Orange County (California). But I know for sure there are places with great communities where you wouldn't expect it. I feel strongly that San Diego SHOULD have a strong, local community. The fact that the meetings could persist for so long, with such high turnover and virtually zero retention rate, shows that people ARE interested in this sort of thing. When I return in July, I'm going to try to dedicate some time to bringing the local meetings back and turning them into something interesting and valuable for local users. I know there are users here with decades of LabVIEW experience and I figure some of you must have come in on the ground floor of terrible to mediocre local communities that eventually became something great. So I ask: what was that process like? What worked as you were building up from nothing? How did you attract and retain programmers of different skillsets and levels, but especially enthusiastic programmers who want to participate in a local group? And for those of you who are currently participating in local groups: What hasn't worked? What has worked? What do you like and what would you like to see more often? Those of you who tried it out and never went back, what kept you from coming back?

On the plus side, the "Tags" functionality looks like it's more or less taken care of with 2013's Bookmark Manager.

Sounds good, thanks for the info, guys! I already sent Certifications an e-mail; I expect a positive response. Looks like I can slack on the recert worries for a while. EDIT: NI confirmed that I'm set until 2017. Score.

Does this apply retroactively? For example, I certified in 2013. Does this mean I'm in the clear until 2017? Or do I still have to recertify in 2015 since I took the exam before the change in policy? The white paper doesn't state either way. Retroactive makes the most sense, but since this is Certifications we're talking about, I don't want to assume anything.

It's not an ideal solution, but I've used it in the past. It's substantially simpler using LVOOP. In that case, you can use inheritance and deploy every subpanel with shared methods for starting up and storing their own GUI information.

Have you considered storing all the states in the central Controller GUI? Then when a subpanel is loaded into the main GUI, the state can be passed from the Controller to the newly spawned subpanel state machine.

Sounds interesting; how are you handling access to the DVR? Does a central Controller pass the reference to each subpanel state machine? Is it contained in an LV2? Do all parties have write access? It sounds a bit like a global, which I have a natural aversion to, but I'm not familiar with your architecture, so maybe it's the best fit.

That's actually a great suggestion, neil. I'll pitch it to the team and see what they think. Considering the frustration we're going through, this is as good a time as any to implement some proactive/preventative measures.

"Fastest" being a relative term, but a couple weeks recoding is apparently faster than getting LabVIEW to resolve what should be a totally elementary organizational operation. This would be one of the "troughs" in our love/hate relationship with LabVIEW.

Tom was able to track the problem down by painstakingly going through our source control and finding the point at which builds no longer worked. It turns out that it CAN be traced back to when we pulled the 20 abstract classes out of their library. We have no idea why this caused such an obscure and massively catastrophic set of errors from LabVIEW. Can anyone provide any insight on that? In the past, I've experienced some baffling and frustrating problems when pulling classes in or out of libraries. Nothing to this extent, but I'm wary of this operation (even moreso now!). Can anyone provide any insight as to why LabVIEW is so bad at handling what should be a simple organizational action? Additionally, is there any way to fix this without having to revert all our source code back to that point and "start over" with all our feature additions? It's over 2 weeks' of coding that we'd basically have to reimplement.

I also want to note that Parallels' breaking of Ctrl+Shift+Alpha commands means I can't summon the "Object Browser" that lets you track down "Insane Objects." So that's a really fun aspect of the Parallels bug.

Not strict typedefs -- do you have any strictly-typed VI references (with an LVOOP object on its conpane) statically linked to any code in your project? Ah, I see. The answer is no. I feel the pain, but give it a go. If this unintuitive workaround of deleting then undoing that deletion "fixes" your root prob, we're almost certainly seeing a related issue. Right now I'm moving all the classes in and out of libraries to reset the mutation histories. If that doesn't work then I'll try the delete block diagram / undo thing next. By the way, is there a more efficient way to delete class mutation histories? One final question -- is it possible you may have refactored data structures by changing owning library of a typedef'd cluster? Well, that's definitely happened now that I'm removing mutation histories by the dropping in/out of libraries. This also happened on occasion in the past when we'd move a class (and any associated cluster typedefs) into a new library. What's the danger of that type of operation? I would imagine this happens regularly to many programmers who use both libraries and typedefs, which is a category I think most people using Actor Framework would fall into.

Hey Jack, I'll answer your questions best I can. Was the source code originally created in LV2013, or a previous version of LabVIEW? It was originally LV2012. The build problems first manifested in 2012. I upgraded my machine to 2013 to try to fix the problem, which it didn't. My coworker is continuing to try to fix the problem in 2012. It's reproducible on both our machines, though the behavior is sometimes subtly different. For example, my crash might be totally catastrophic with no error popping up. His crash might lead to a failed build and an error returning, but not an entire crash of the LabVIEW environment. If he has time, he might drop in the thread and describe what he's seeing in 2012.Do you have strictly-typed VI references that contain LVOOP objects on the connector pane anywhere in your code? I don't believe this is the case. As far as I know, we only use strict typedefs for a handful of specialized GUI cases. Other cases are standard typedefs. In none of those situations are we using an object for any of our UI effects. It's possible something to switched to a strict typedef by accident, but I don't have a good way of checking this quickly in such a large project. Is the crash intermittent? Crash happens every time I try a build. Is the crash reproducible in all environments? (e.g., coworker's computers, other versions of LV) It's happened in 2012 and 2013 so far. I think we've only tried it on our two machines. Mine is a Macbook running Windows 7 on Parallels. My coworker's computer is a PC laptop running Windows 7. Are you using .NET callbacks anywhere? I don't BELIEVE so. I'll double-check. None of the code we wrote using a .NET callback but I suppose it's possible one of the drivers or extensions we're using might. What additional libraries (NI and third party) do you have installed? JKI State Machine, JKI RSC Toolkits Palette, OpenG (all libraries included in the standard package), the Debug branch of Actor Framework, the Missing Systems Controls UI suite, Is dev environment in a VM or on bare metal? Mine is a virtual machine on a Mac; my coworker is running Windows on a PC machine. If you run some other CPU taxing process in parallel on the same machine (in order to deliberately steal resources from LV), does the crash still occur? I haven't tried it. I have a build attempt running right now, I'll give it a shot after. If I switch LabVIEW over to a single CPU in Task Manager, would that be sufficient? Have you tried removing mutation histories from all LVClasses? Not yet. I'll add that to the list of things to try.If you open all offending VIs, then CTRL+A on the block diagram to select everything, then delete, then CTRL+Z to undo, does the problem still occur? The sheer number of VIs that returned "Insane Object" errors makes me loathe to try this. I suppose I can try it with one or two VIs on the list and see if they still return an "Insane Object" error on re-compile. Have you tried DETT in the offending context? I've never run DETT during a build attempt and didn't realize that was a potential debugging option. I can add that to the list of things to try. Have you tried Procmon filtering on LabVIEW.exe events? Had to Google this. Never used Process Monitor before. Is it pretty intuitive or is there something I need to know before trying to watch the build? I'm guessing there's some logging option.

Recently, something in our project has become corrupted such that trying to build an executable leads to a catastrophic LabVIEW crash. LabVIEW reports no errors in development mode and everything runs fine in development. We've tried a huge number of fixes with no luck. Upgrading to 2013, upgrading to the f2 patch, loading the manual fix from this thread, disabling large swaths of block diagrams, removing XControls and replacing them with classes, resetting the class hierarchies of suspected offenders, deleting the object cache, tracking down all disable structures with missing VIs and removing them, etc. We're on the verge of stepping back through our source control to find the last working build, but as it's been a long while since we last made an executable, we're likely to lose a ton of work and have to painstakingly add features back in one at a time. Trying to mass compile our code also leads to a catastrophic crash. I started mass compiling individual subfolders and removing any warnings. This is painstakingly slow and frustrating. I was finally able to mass compile one of the larger subfolders, containing a good chunk (maybe a fifth) of the total functionality. Before this, trying to mass-compile that folder would crash the LabVIEW environment. But though it didn't crash, the mass compile returned a very large list of "insane objects." It also suggested that the mass compile was terminated early by me, but I had left the machine to run over lunch and the termination was NOT user-initiated. I found this thread at NI Forums and may start playing around with removing the insane objects, but there are so many... anyone have any other suggestions? Here's the mass compile info: #### Starting Mass Compile: Fri, Feb 21, 2014 11:58:27 AM Directory: "C:RepositoryV12000LabviewDialogs" Insane object at FPHP+38C8E3D0, UID 3903, in "V12000 Utility Suite Config File LV2.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOFunctional GlobalsV12000 Utility Suite Config File LV2.vi Insane object at FPHP+222DFAC0, UID 4738, in "Settings Interface Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface Cluster.ctl Insane object at FPHP+CE6BC20, UID 512, in "Supported Mode Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeCustom ControlsNon-GUIClustersSupported Mode Cluster.ctl Insane object at FPHP+41DAFE80, UID 779, in "Convert Setting ID To Scale.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Scale.vi Insane object at FPHP+41DA17B0, UID 920, in "Convert Setting ID To Data Type.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Data Type.vi Insane object at FPHP+423F4660, UID 1386, in "Convert Array of Setting and Setting Value Clusters to U8 Array.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeData ManipulationConvert Array of Setting and Setting Value Clusters to U8 Array.vi Insane object at FPHP+41F704D8, UID 893, in "Check Mode Initialization.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsCheck Mode Initialization.vi Insane object at FPHP+2D157018, UID 1074, in "Settings LV2 Local Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings LV2 Local Cluster.ctl Insane object at FPHP+123797A8, UID 2393, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+1249DFD8, UID 2324, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface LV2 Cluster.ctl Insane object at FPHP+143ED200, UID 10245, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+230F3680, UID 11243, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceFunctional GlobalsSettings Interface_LV2.vi Insane object at FPHP+3E2D89C0, UID 1532, in "V12000 Utility Suite Config File Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOCustom ControlsV12000 Utility Suite Config File Cluster.ctl Insane object at FPHP+1C3F6E38, UID 2870, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+180F8BC0, UID 4692, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOSupport VIsRead Config File.vi Insane object at FPHP+423BFE80, UID 310, in "_Configuration Module (Parent).lvlib:Cluster - Task VUS Data.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentCluster - Task VUS Data.ctl Insane object at FPHP+34C89258, UID 427, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+313BFD60, UID 1667, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core Data - ParentLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+36A83358, UID 427, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+2CBD3328, UID 1667, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - DAQLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+3BBF6AA0, UID 427, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+39C35690, UID 1667, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Source ConfigLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+3B73F880, UID 427, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+3BEA7358, UID 1667, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Vent ConnectLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+3C811F70, UID 427, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+3C815070, UID 1667, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Validyne CalLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+3ECB3F28, UID 427, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+3ECB6E50, UID 1667, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - CustomLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+3EA17A40, UID 427, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+3EC41E70, UID 1667, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - VSALoad Module Data into VUS Task Cluster.vi Insane object at FPHP+4BC915D0, UID 2704, in "_Configuration Module (Parent).lvlib:Config Module Parent.lvclass:Return VUS Config Data from Module Array.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentReturn VUS Config Data from Module Array.vi CompileFile: skipping C:RepositoryV12000LabviewDemosConfig Dialog DemoConfig Dialog Error Demo.vi Insane object at FPHP+44085928, UID 310, in "_Configuration Module (Parent).lvlib:Cluster - Task VUS Data.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentCluster - Task VUS Data.ctl Insane object at FPHP+4E764318, UID 512, in "Supported Mode Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeCustom ControlsNon-GUIClustersSupported Mode Cluster.ctl Insane object at FPHP+4F7FD380, UID 4738, in "Settings Interface Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface Cluster.ctl Insane object at FPHP+4E79A040, UID 1074, in "Settings LV2 Local Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings LV2 Local Cluster.ctl Insane object at FPHP+4F826B48, UID 2393, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4F813440, UID 2324, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface LV2 Cluster.ctl Insane object at FPHP+4F6F6C68, UID 779, in "Convert Setting ID To Scale.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Scale.vi Insane object at FPHP+4F712698, UID 920, in "Convert Setting ID To Data Type.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Data Type.vi Insane object at FPHP+4F70CD78, UID 893, in "Check Mode Initialization.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsCheck Mode Initialization.vi Insane object at FPHP+4F76CD80, UID 1386, in "Convert Array of Setting and Setting Value Clusters to U8 Array.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeData ManipulationConvert Array of Setting and Setting Value Clusters to U8 Array.vi Insane object at FPHP+4E7E26A0, UID 1532, in "V12000 Utility Suite Config File Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOCustom ControlsV12000 Utility Suite Config File Cluster.ctl Insane object at FPHP+4E87E4F8, UID 2870, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4E858388, UID 4692, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOSupport VIsRead Config File.vi Insane object at FPHP+4E665268, UID 3903, in "V12000 Utility Suite Config File LV2.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOFunctional GlobalsV12000 Utility Suite Config File LV2.vi Insane object at FPHP+4F5458E0, UID 10245, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4F4F0FC0, UID 11243, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceFunctional GlobalsSettings Interface_LV2.vi Insane object at FPHP+37923628, UID 427, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+440AD550, UID 1667, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core Data - ParentLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+46057E20, UID 427, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+46043AE8, UID 1667, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - DAQLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+46EA4990, UID 427, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+46EEC480, UID 1667, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Source ConfigLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+4B8DECC0, UID 427, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4B8B8088, UID 1667, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Vent ConnectLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+4C006C60, UID 427, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4BFD3AA8, UID 1667, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - CustomLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+4C2AEB48, UID 427, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4C41C480, UID 1667, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - VSALoad Module Data into VUS Task Cluster.vi Insane object at FPHP+54840EF0, UID 427, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+548CC480, UID 1667, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Validyne CalLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+4F76CD80, UID 1386, in "Convert Array of Setting and Setting Value Clusters to U8 Array.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeData ManipulationConvert Array of Setting and Setting Value Clusters to U8 Array.vi Insane object at FPHP+4E7E26A0, UID 1532, in "V12000 Utility Suite Config File Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOCustom ControlsV12000 Utility Suite Config File Cluster.ctl Insane object at FPHP+4F826B48, UID 2393, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4F813440, UID 2324, in "Settings Interface LV2 Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface LV2 Cluster.ctl Insane object at FPHP+4F70CD78, UID 893, in "Check Mode Initialization.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsCheck Mode Initialization.vi Insane object at FPHP+4F5458E0, UID 10245, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4F4F0FC0, UID 11243, in "Settings Interface_LV2.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceFunctional GlobalsSettings Interface_LV2.vi Insane object at FPHP+4F7FD380, UID 4738, in "Settings Interface Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings Interface Cluster.ctl Insane object at FPHP+4E79A040, UID 1074, in "Settings LV2 Local Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceCustom ControlsSettings LV2 Local Cluster.ctl Insane object at FPHP+4BDC5698, UID 2704, in "_Configuration Module (Parent).lvlib:Config Module Parent.lvclass:Return VUS Config Data from Module Array.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentReturn VUS Config Data from Module Array.vi Insane object at FPHP+4BDC5698, UID 2704, in "_Configuration Module (Parent).lvlib:Config Module Parent.lvclass:Return VUS Config Data from Module Array.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentReturn VUS Config Data from Module Array.vi Insane object at FPHP+4F712698, UID 920, in "Convert Setting ID To Data Type.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Data Type.vi Insane object at FPHP+4E764318, UID 512, in "Supported Mode Cluster.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000Labview_V12000 Common Labview CodeCustom ControlsNon-GUIClustersSupported Mode Cluster.ctl Insane object at FPHP+37923628, UID 427, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+440AD550, UID 1667, in "_Configuration Module (Parent).lvlib:Module Core Data Parent.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core Data - ParentLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+46057E20, UID 427, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+46043AE8, UID 1667, in "DAQ Configuration.lvlib:DAQ Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - DAQLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+46EA4990, UID 427, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+46EEC480, UID 1667, in "Source Selection.lvlib:Source Config Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Source ConfigLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+4B8DECC0, UID 427, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4B8B8088, UID 1667, in "Vent Connect.lvlib:Vent Connect Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Vent ConnectLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+4C006C60, UID 427, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4BFD3AA8, UID 1667, in "Custom Calibration.lvlib:Custom Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - CustomLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+4C2AEB48, UID 427, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4C41C480, UID 1667, in "Vent Signal Assignment.lvlib:VSA Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - VSALoad Module Data into VUS Task Cluster.vi Insane object at FPHP+54840EF0, UID 427, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+548CC480, UID 1667, in "Validyne Calibration.lvlib:Validyne Cal Core Data.lvclass:Load Module Data into VUS Task Cluster.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesOther ClassesModule Core - Validyne CalLoad Module Data into VUS Task Cluster.vi Insane object at FPHP+44085928, UID 310, in "_Configuration Module (Parent).lvlib:Cluster - Task VUS Data.ctl": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewDialogsConfiguration ManagerModules_ParentCluster - Task VUS Data.ctl Insane object at FPHP+4E87E4F8, UID 2870, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO ) Insane object at FPHP+4E858388, UID 4692, in "Read Config File.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOSupport VIsRead Config File.vi Insane object at FPHP+4E665268, UID 3903, in "V12000 Utility Suite Config File LV2.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsFile IOFunctional GlobalsV12000 Utility Suite Config File LV2.vi Insane object at FPHP+4F6F6C68, UID 779, in "Convert Setting ID To Scale.vi": {tdname } (0x4000): Type Definition (DDO ) insanities in FPHP of C:RepositoryV12000LabviewV12000 Utility SuiteSupport VIsVentilatorRASP CarlsbadSettings InterfaceSupport VIsConvert Setting ID To Scale.vi CompileFile: user cancelled at C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesTest Case ConfigurationTest Case Configuration.lvproj CompileFile: user cancelled at C:RepositoryV12000LabviewDialogsConfiguration ManagerModulesTest Case Configuration SubmodulesVentilator Settings ConfigurationVentilator Settings Configuration MessagesReceive Ventilator Settings MsgDo.vi Mass compile terminated early #### Finished Mass Compile: Fri, Feb 21, 2014 1:44:00 PM

I found posted on another LabVIEW forum. Pretty entertaining!

Sometimes when I'm working with LVOOP, I'll break a class. When this happens, I could potentially end up with hundreds of errors - for example, if I've broken an Actor Core.vi. Sometimes when this happens, I want to look at the list of errors to see what's going on. But in these cases, loading the error list window can take a long time (minutes). Then once it's loaded, it seems like it's refreshing / updating itself rapidly with new errors, so the interface gets locked. Has anyone else experienced this? Any workarounds?

That's a shame, but at least you'll have that much more time to prepare. Good luck!

Have you taken the exam yet? If so, how'd it go?

Congrats Claude! One of just four CLDs in the Philippines? Aim to be the only CLA in the country next.