smenjoulet

My opinion: VIs should be called VIs when not in the context of an application or hierarchy. I think that referring to VIs in general as subVIs is incorrect and would argue for re-education of the confused. Maybe it's nitpicky, but it bothers me when someone asks me if I have a subVI to do such and such. If I catch myself (because I admit it's easy to let it slide), I'll respond "No, but I've got a VI that does that and you can use it as a subVI." To me subVI still makes the most sense in that context. The only alternative that comes to mind is "called VI", but I suppose that could cause confusion with call and forget scenario discussed by mje and chris754. If you start trying to apply different names to different scenarios, i think you'll end up confusing more people in the end.

Not fair! not fair! It isn't fair, my precious, is it, to not tell us what it's got in it's nassty little pocketsess? Wicked, tricksy, false!

Texas Instruments is looking for a dynamic individual to fulfill the role of Senior Lab Automation Lead in our Santa Clara, CA office. The candidate should have a strong background in using GPIB as we deal with a lot of stand alone benchtop instruments. PXI and DAQ will also be an important part of your skill set. You should at a minimum be at a strong CLD to CLA level. If interested, you can send your info to Marvin and Scott at ti_automation_lead_opening@list.ti.com Required Experience 5-10 years of LabVIEW development (architect-level skill set preferred) 3-5 years of Teststand experience 3-5 years of experience developing professional-grade automation solutions 3-5 years integrating automated solutions in a heavy R&D lab environment Experience training and mentoring engineers in the area of lab automation Experience directing and managing an offshore development team Job Description: This is a technical lead role with heavy and active involvement in the definition, development, deployment, training, maintenance and support of automated lab solutions built on National Instruments languages and tools, primarily LabVIEW and Teststand. A primary responsibility is to engage with all Analog teams at the TI Santa Clara site with the goal of helping them deploy TI’s standard Lab Automation infrastructure and methodology in a way that they can become self-sufficient including a healthy partnership with the necessary EDA teams. This heavy customer (internal to TI) facing role is crucial. The individual needs to not only be strong and confident technically but also work very well with a broad range of users and build very important mentorships partnerships. This will also include the responsibility of deploying a vendor-enabled services model to ensure the necessary scale across the entire site. This model includes management of US-based senior engineers from a partner company and the India-based development team supporting Santa Clara projects. This individual will also be a key part of the worldwide EDA System Design infrastructure team. This means that the candidate needs to be able to grow, over time, beyond the NI-centric toolset. Expertise in non-NI languages and tools are not a prerequisite but ability to make that kind of move when/if required is very important. Looking for someone that is very passionate and motivated about doing what is necessary to help Analog teams become more and more successful with automation in a lab environment by leveraging strong and healthy partnerships with Analog EDA. Also posted on NI Forums Regards, Scott

Jon - My interpretatin of that statement was that this applied to the updated 8.6 implementation, and actually any implememntation that "checks out " the class and passes the class wire between class methods. This would be a problem in the 8.2 version as well. It also had checkout/checkin components, though the actual usage example didn't use them and was "wireless". Indeed. But I like the discussion and will need to catch up on the thread before putting in my $.02. -Scott

Yea, that's what I had hoped, but I couldn't find anything here or on the NI forums that specifically discusses the 8.2 implementation. Maybe I'm not searching right, but all I get is that the original 8.2 example is "flawed" or a "bad idea", but no discussion of why. Right! That's why I think the same implementation in 8.6 but substituting an SEQ for the DVR would be better than the shipping example, but I guess no one really cares about it any more. It's more of a thought experiment and wondering "Why?" at this point. There are more interesting discussions of OOP going on than what to do with the singleton pattern in 8.2 or 8.6.

I guess Yair and I could have been a bit more explicit when stating DVR's and SEQ's function identically. Of course there are differences, but we were referring specifically to the locking capability, not type handling. From the locking perspective, they function very much the same. Though as Yair points out, the scope of the lock is clearer with DVRs becasue of the IPE structure. Try saving some basic DVR code to 8.6. What do you get? An implementation based on SEQ.

Yes, I agree. That is what prompted the latter part of my post. Why wouldn't this be the example of a Singleton that ships with LabVIEW (SEQ for 8.6; DVR for 2009+). Currently the example is a class wrapped in a library that uses a checkout/checkin mechanism to provide the locking. The checkout/in is still based on an SEQ, even in 2010. AQ had stated that he had wanted to see how DVR's were accepted before proposing his DVR method become the shipping example for 2009. OK, I'll give benefit of the doubt on that one. But why wasn't the example updated for 2010. There are diferences between the 8.2 version and current version, but both are based on SEQ+FGV. The current shipping example is the same for 8.6 through 2010. Actually the 8.2 version is somewhat closer to AQ's DVR implementation and the alternative for 8.6 using an SEQ that I mentioned above. The major difference is that the class is wrapped in a library and the public API is in the library and it wraps the class functions. The class is private to the library. There are still checkout/checkin VI's but they aren't actually used in the example or the other API functions. It's almost like they were an afterthought or that you were expected to use them even though the othe API examples don't. The API examples dont have class inputs or use the checkout/in; they just get the SEQ from the FGV and dequeue/enqueue the class. It's an inconsistent message. The 8.6 and up version is pushing you towards explicit checkout/in. The class is still wraped in a library and the public API is part of the library and wraps the private class functions. But the public API has class inputs so you have to do a checkout to do any operation and then checkin. The public API does not checkout/dequeue or enqueue/checkin internally like the 8.2 version or the DVR version. The user has to do that and then call the API functions. That's what is prompting these questions. The fundamental mechanism is the same whether it is SEQ+FGV or DVR+FGV. The fact that the original 8.2 example is a little closer to the DVR+FGV version that AQ posted makes me question what issues were encountered with it. Is it the wrapping library (still used in the "better" 8.6+ versions)? Is it the inconsistency? Is it the fact that the public Get method uses Preview queue vs dequeue? Something else entirely? I'm attaching the original 8.2 version for those that don't have 8.2 and want to see it. I'm also attaching an 8.6 version that duplicates the DVR implementation but using an SEQ. The DVR version by AQ is linked above and I assume everyone can get the current shipping example in 8.6 or higher. -Scott SingletonPattern82.zip SingletonData 86.zip

There were two ini keys, one for scripting and one for additional private features. True the scripting key hasn't worked for some time as NI switched to requiring activation for scripting and then making it publically available as option that can be an enabled. The other key still works for some of the additional private items. However the scripting workbench that Francois points to may be a better option for you depending on your needs.

Refer to the bottom of this post to see how to enable the private properties/methods.

Darn, you're quick! Congratulations on 1000 popsts! -Scott

It's not clear in the images, but I mentioned in the post that this is based on an SEQ (single element queue). The process of dequeueing the class will cause any other parallel operation to wait at it's dequeue until the class is enqueued again. This proivides the locking and serialization mechanism. The IPE handles this imiplicilty for DVR, while the class developer has to be cognizant to do the proper dequeue/enqueue operations for the SEQ implementation.

So I was re-examining some design pattern postings and ran across this statement again (and other similar ones) about the Singleton example (based on SEQ and FGV) from LabVIEW 8.2: An example of this implementation shipped with LV8.2. That version turned out to be a bad idea.Haivng never looked at this example originally, I loaded up 8.2 to see what the fuss was about. I also searched for an explanantion or discussion of what exactly was bad or what the issues were, but couldn't find anything. So without straining my brain too hard this late at night, what exactly were the issues that people found? And comparing the shipping Singleton example from 8.6 -> 2010 to what AQ posted here, I prefer the DVR version as I think most people would. Having said that, if one was stuck with LabVIEW 8.6 or earlier (no DVR) and needed a singleton pattern, why would you use the shipping example vs. doing the same thing the DVR implementation does, but with an SEQ: You get many of the benefits AQ mentioned in the post referenced above: No wrapping library, no replication of VI's,... Am I missing something? I would think this would have been the shipping example, but is this conversion from DVR to SEQ so simple I'm overlooking something. I don't think so, but intersted in your opinions. -Scott

You say you are single-stepping, but are you stepping into the various subVI's or just stepping over the subVIs. It sounds like it may be stuck in a dll call. Are you communicationg with any hardware? DAQ, GPIB, that sort of thing? Normally, during execution highlighting, the currently executing subVI(s) should have a green arrow overlayed on top of the icon. Can you seen that anywhere when the execution appears stuck? Can you post at least a screen capture of the top level diagram so we can see what is being used? -Scott

You're using Express Vi's in your application. This is the naming you'll see for express VI's when you list them out. -Scott

You were probably clicking the increment/decrement (up/down) arrows for the ring control. Just try clicking on the picture itself. You will get a thumbnail of each picture and you can select the one you want. If you're expecting it to look like the picture you posted, i think you'll be disappointed. If you want that, you'll have to do a bit more work with either a picture control (not picture ring) or an XControl. If you're on Windows, you might also be able to find an ActiveX or .Net control that would work. -Scott