NATE

Would you be able to post this? I'm about to write my own script to do the same thing. The two provided on this thread don't handle projects, libraries, and classes. I know there are good reasons to not touch this setting on a project, but currently our whole code base is intended to be source-only. Somehow we keep finding more VIs with compiled code intact. Did some brief searching and didn't find anything online more complete than what's here.

I just experienced this with a method of a class in LV2013 SP1 f2. The other methods have a Remove from Library option, one didn't. No idea why. I renamed the method (since I was going to delete it anyway), and there's my menu item...

I had a great time tonight at the LAVA BBQ and Challenge the Champions. Was great to meet more people. Thanks to everyone who helped organize.

You still have time to enter the 7x7 lightning round competition and win a free pass to NI Week! This is your chance to show off some of the really cool projects you've worked on. Presentation can be high level or low level, no need to show code or anything prioprietary. We just want to be inspired by the cool stuff you've done! Email us if interested: nate@themoehrings.com and michael.aivaliotis@jki.net

This year's You Call It (aka Open Theme) topic has received a lot of positive response (see Likes and replies here) as well as some valid concerns. We've now had some time for people to submit presentation ideas and I've begun to group them into "mini-tracks". I hope that by declaring official mini-tracks I can assuage the concerns previously voiced about this year's Open Theme. I'm grouping these presentation ideas based on the number of Likes they receive and the summit topics that received the most Likes. So keep voting to help shape the Summit, I really do look at them! Here are the mini-tracks that are perculating for 2014: Security Frameworks/Software Engineering in LabVIEW Integrating TestStand and LabVIEW What defines a mini-track? Good question. I think the normal expectation people have when they hear the word track is to think "parallel content". However, the number of presentation submissions and how they align with these tracks will determine if some or all of these tracks occur in parallel or series and are simply grouped together roughly by time. I think its safe to say we'll have about 3 hours of content for each of these mini-tracks, give or take. Frameworks/Software Engineering in LV has the most presentation submissions, which I think is fair and appropriate. As we get closer to January 15th I'll start to really formalize the agenda based on the inputs we've received and available rooms in Mopac C. I expect we'll have a few parallel sessions, but not full parallel tracks. BUT WAIT, THERE'S MORE! In addition to these mini-tracks, this year we'll also be having an Embedded mini-summit! How's a mini-summit different from a mini-track? I'm glad you asked. The main difference is this mini-summit is being planned and executed by the NI Embedded team, not by the CLA community. NI's Embedded team expressed an interest in getting to know the CLA community better, as well as promote the CLED certification. This mini-summit will primarily be on Wednesday afternoon. This is an awesome opportunity to increase the value of the CLA Summit (as if it wasn't already smokin' hot), and if you so desire you'll have an opportunity to take a CLED prep class and the 1hr multiple choice portion of the CLED exam (with the expectation that you complete the 4hr practical exam within a year). Note that you most likely will not be able to take both the CLED(mc) and CLA-R exams at the CLA Summit. If you are not interested in Embedded, no need to stay for the mini-summit. With these 4 topics and 3 full days of content I think we'll have something for everyone AND get into enough technical depth to learn a thing or two. And yes, we'll still have time for "round table" discussions, always a popular part of the Summit. If you would like to post questions or comments, please do so here: https://decibel.ni.com/content/message/63785#63785 Salutations, Nate and Michael

We have some of the greatest jobs in the world! Not only do we get to tackle tough engineering challenges and make the world a better place, but we get to do it by drawing pictures in LabVIEW, fun! At the next CLA Summit, we want to celebrate your accomplishments. You're invited to take part in a friendly competition we're calling 7x7. In 60 minutes we want to hear up to 7 stories about how you're making the world a better place, the coolest technical challenges you have solved, the killer app, or the coolest feature you've created in LabVIEW. Here's the thing, you're limited to 1 minute of setup, 5 minutes of presentation, and 1 minute of tear down. If you go beyond the 6 minute mark (1 + 5), we will pull the plug on you. So be sure to practice giving the presentation in the allotted time frame. The format of the presentation is open: powerpoint, video, demo, soap box, you choose... At the end of all the presentations, the audience will vote on their favorite presentation. Voting is completely arbitrary, no scoring criteria will be provided, and each member of the audience will get one vote. The winner will receive a free pass to NI Week! (thank you NI!) Anyone wishing to enter the competition should submit a 1 slide abstract of their presentation to nate@themoehrings.com and michael.aivaliotis@jki.net by Jan 22nd, 2014. If we have more than 7 submissions for this friendly competition, Michael and I will evaluate the submissions and select the 7 that we feel are the highest caliber. We'll notify you of your selection status by Jan 29th. Participating in this competition does not preclude you from also giving a full presentation at the CLA Summit. We hope that this will be a fun and motivational experience for the CLA Community, and that it will stimulate dozens of conversations during and after the CLA Summit. If you would like to post comments or questions, please post them to https://decibel.ni.com/content/message/64060#64060 Happy New Year! Nate and Michael

CLA Summit 2014 Theme: You Call It We're going to try something different this year for the 2014 CLA Americas Summit. There was no clear winner in the topic selection voting, so we want you to present on whatever topic you're most interested in! From the presentation abstracts that are submitted, we'll look for common topics and schedule them together to form mini-tracks. Depending on the number of volunteer presenters, we'll either select those that receive the most likes on the forum, or we may decide to schedule tracks in parallel. See full post here: https://decibel.ni.com/content/message/62947#62947 Can't see the page? Please join the NI CLA Community page! As presentation abstracts are submitted, feel free to "like" them so we can gage community interest. Thanks for stepping up to present! I can't wait to find out what you have in store for the next CLA Summit. Should be exciting! Nate

You say the CLA summit has great return on investment, show me the money! We're looking for testimonies from past CLA Summit attendees on tangible ways you or your company have benefited from something learned or discussed at the CLA Summit: improved architectures, processes, bug fixes, new features. How has the CLA Summit made you more profitable? I'll be compiling your testimonies and based on the responses determine the best way to present them to the community. Would love to have people volunteer to share their experiences and savings at the next Summit. This might become a regular part of future summits. Email them to me at nate@themoehrings.com. Thanks!

If you are a CLA, we want your feedback, the call for topic ideas for CLA Summit 2014 is here: https://decibel.ni.com/content/message/60510 Can't see the page? Please join the NI CLA Community page! CLA Summit 2014 will be March 3 - 5. We have some great ideas in the works and think this is going to be a very exciting Summit. Looking forward to it already! Thanks, Nate

What is the impact of this Code Complexity threshold on built applications? I'm hoping that it has no impact, that when you perform a mass recompile or build into an application that all compiler optimizations are enabled, since the editor response time isn't really part of the equation. Can someone confirm this is true for me?

Coming to the Americas' CLA Summit 2013 on March 4-6th? Got some company spirit you'd like to display? Bring some company swag and we'll use them as giveaways during the summit! Looking forward to March! Nate

Dear CLAs, The time is almost up for presentation submissions for this year's CLA Summit, but we still want to hear from you. The topic is widely labeled "Delivering Professional Software". That's what we strive to do everyday so if you've got ideas on how to do that more effectively we want to hear them! Details are posted here: https://decibel.ni.com/content/message/44030#44030 Please do the following: Submit outline/idea to clasummit@ni.com Include 3-5 slides that will outline the main conversation points that you would highlight. If you are selected, you will be expected to submit your full presentation by Friday 2/15/2012 to clasummit@ni.com Technically, the deadline is Mon Jan 7. If you would like to submit, please at least send me a title or one paragraph about what you plan to present. If you need an extension, please let me know. I am really looking forward to seeing your submissions. The participation of CLAs like you is what makes the CLA Summit so great! See you at the Summit soon! Nate Moehring

I'm in!

I've posted a new and improved version of this presentation. I think this version is much better than the original, so even if you read the original I ask that you would consider looking at it again. https://decibel.ni.c.../docs/DOC-18320 Motivation for this presentation: At the 2011 CLA Summit, NI asked us what we thought was missing from LabVIEW or what needed to be improved. I already knew AQ’s position on this, but my feedback to NI and direct conversation with AQ was that I thought LabVIEW needed to be able to invoke methods on object references. At the time that I said this, I knew that I wasn’t 100% up to speed on all the different incarnations of by-reference architectures or messaging architectures out there, but I felt (and still feel) that this would be a powerful (if not necessary) evolution for LabVOOP in the future. Because I know AQ has spent a great deal of his life pondering these issues (for which I am extremely thankful), and discussing them with scores of brilliant minds around the world (like you if you're still reading this), I felt I needed to do some homework on these different techniques for achieving by-reference objects, if nothing else to improve my own skills, but also to strengthen or assuage my own position on this topic. The result is this presentation. Originally this presentation was merely a book report of by-ref OOP techniques that I was aware of. I tried to document the implementation details of each technique, the common pitfalls, and the pros/cons. Then I started providing justification for why by-reference support in any language was important, and demonstrated how problems that are simple to implement in other languages using pointers/references are more cumbersome in LabVIEW. Then I provided a summary of where I think LabVOOP could improve, what I’d like to see possible, and what we can do currently. Then I added suggestions on what methods and features by-reference classes might contain and how they can be implemented. Finally I provided recommendations for class authors to assist in the decision making of class implementation and utilization. I want to share this presentation with the LabVIEW community because I think there are probably very few resources like it available, a detailed discussion of object references in LabVOOP. If you find it educational or beneficial I would appreciate hearing that so I can get some validation on this topic for myself. To be honest this discussion is a bit out of my area of expertise, but I do think it’s an interesting topic and important to LabVIEW in the broader General Purpose Programming Language context. Thanks, Nate

Yes, but we all mentally compile that out of our thinking. We know that LabVIEW will only make a copy of the data when it needs to, so the part that is not immediately intuitive to me is that fact that wiring the branch to the Create DVR primitive is one of the rules LabVIEW uses to determine that a copy is required. I admit that it is internally coherent when you stop and really think about what pure dataflow is, but even though I've been using LabVIEW for 12 years I haven't really pondered all of it's finer implications. The majority of dataflow is very intuitive, that's why I love it.

Wow, thanks Daklu for this post. I know this post is 2 years old, but I was about to make the same mistake. Your Evil AQ explanation was a great revelation for me regarding the existence and limitations of references in a dataflow language. Really it just boils down to this: You cannot have both data and a reference to that data at the same time. When that happens, what you really have is a copy of the data (or an antiquated reference?). Changing the reference cannot change the data on the wire. Seems so simple and obvious now, but this distinction is not intuitive for those of us who have used references/pointers in other languages, and this distinction is very important to understand. I'll admit I haven't read all of the LabVIEW help on DVRs, is an explanation like this given in the LabVIEW help? Specifically that branching a wire into a DVR Create node will always create a copy of the data? That's counter-intuitive to what I expect when I think of creating a reference.

I'm sorry, you're right. In this presentation my Checkout method does leave the object in the SEQ. Again, this is because I don't want other read-only tasks to block waiting for a task to checkin the object back in. In other implementations I have used the traditional Dequeue Element SEQ technique.

Thank you for your comments. Our meetings are 2 to 3 hours, we try to limit them two 1 hour presentations, which some time for announcements and dialogue. A lot of this presentation is about the By Reference Object Manager which I created prior to DVRs, so I'll be glazing through the slides. I realize I'll be pushing my hour but it's okay if I go a little long. Yes, I realize my BROM is using SEQs in a non-traditional sense, and that's one of the reasons why I still have it in the presentation even though it is superseded by DVRs. I state this in the presentation. I believe that DVRs should provide a way to retrieve a copy of the data without locking the data. This implementation of the SEQ, having a "Get Latest" method that uses the Preview Queue element gives me that capability. This is useful for WORM type applications where you populate the data at start up and reference the data through out an application with numerous parallel tasks. I don't want those parallel tasks to block on each other just to read some data out when I know I have no intention of updating the data. Obviously the normal "Checkout" method still exists, preventing memory copies. Also you may have noticed the locking semaphore. This essentially implements the other half of the IPE in a DVR implementation, not found in most SEQs. The caller who performed the checkout is given a passcode, the checkin operation will fail unless you provide that passcode back to the BROM. Pretty cool I thought. And yes, wrt to using Notifiers instead of Queues, I was thinking of the Cancel Notification primitive to prevent memory copies. I don't know if there's inefficiencies in doing this or not. Like I said, notifiers have timing features that Queues do not, which makes me think they would be less efficient than SEQs. I was just trying to be thorough and list possible ways of passing data by reference. Thanks again for your posts, Nate

Messaging architectures aside, I think it's still important to have an easy way to access objects by reference independent of frameworks and addon tools. This thread motivated me to present this as a topic at the next Advanced Phoenix Area LabVIEW User Group (PLUG+), Oct 4th. Pulling largely from this thread, along with prior experience and looking into G#, I put together this presentation. I don't consider myself an expert on the topic, but I do consider myself a student. I would very much appreciate feedback from LAVA users regarding the accuracy and completeness of this presentation. I'll incorporate your feedback and repost the presentation after Oct 4th. https://decibel.ni.com/content/docs/DOC-18320 Thanks in advance, Nate Moehring

My app does use LabVOOP, but I'm using this method to systematically go through ever VI in my application, which includes all of my dynamic dispath VIs. But I think I'm having a problem finding all of the dynamic dispatch dependencies within vi.lib. It makes sense to me that this would be unknowable until runtime, and since parent classes don't know what children classes exist, there's no way for me to truly know what ALL of the dependencies of my application are by static analysis, I'd have to do run-time analysis, which is not convenient for an automated build tool. Thanks for the heads up. I thought I was safe but I guess it bit me afterall. Nate

Yep, that was it. The default setting in AppBuilder is to remove all Front Panels, but my application assumes all front panels are available for debugging and automation purposes. Thank you to everyone who fired a few neurons on tthis for me, whether you replied or not. Hopefully it will be smooth sailing from here, Nate

Also worth noting that when I build the EXE using OpenG Builder (which does not enable Remote Debugging), FP.Title works fine. And why is the EXE file size so dramatically different between AB (177KB) and OGB (65KB)? I don't know what OGB could be doing so differently than AB to get such big differences on an EXE that only contains 2 small VIs.

Here's another version of the same demo project with less complexity. Run Application.exe as is, get an error. Enable Remote Debugging and rebuild, no error. FP.Title Error 16 - smaller.zip

Correction, it's actually the FP.Title property that's giving me the error, not VI Path. I jumped to that conclusion too quickly. But other FP.Open works fine, as well as VI Name, Path, Exec.State, weird. More information to add, I'm using LV2009SP1 and Open Panel.vi is saved inside of my .exe. Here's a sample project that demonstrates the problem. I think it's a LabVIEW bug. Thanks, Nate FP.Title Error 16.zip

Under what circumstances will the VI Path property return error 16? I built an executable using the App Builder and when I have Remote Debugging enabled it works fine, but when I disable it, I get error 16 when attempting to read the VI Path from a reference to vi.lib\Utility\victl.llb\Open Panel.vi. I don't know if this error is really path specific, or if it's an error that occurs under a certain condition. I don't think it matters, but Open Panel does have Preallocate Clones set. Any ideas about error 16 or times when Remote Debugging should not be disabled?