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

Ditto Shaun! Ditto crossrulz! I can't echo enough these sentiments and the recommendation from NI to properly exit programs using a Stop button or some other exit mechanism. If... 1) You can't make them see the value in this and they still complain, and 2) crossrulz's suggestion of using Windows "X" window close button is not a good enough compromise for them (FWIW, I like to implement a Stop button and handle the window close event) then you could always resort to trickery and skullduggery... Implement some button that look just like the LabVIEW IDE buttons. Hide them when the VI is not running and show them when running. Really, you just need to educate them to the potential hazards of using abort and that is why you don't show it. -Scott

Here's an alternate version that ships with LabVIEW, though you can't find it on the palettes. Works across a network just fine. -Scott

Create a property node from one of the array elements and use the "Data Entry Limits:Maximum" and "Respone to Value Outside Limits:Maximum" properties. All the array elements will use the new maximum *but* they will keep any old value outside the new max until the user attempts to change that particular element. In other words, they are not immediately coerced; if you want all elements to immediately update, you'll need to do it yourself. -Scott

Huh??? I don't tend to disagree with Chris, but I just don't buy the argument in this case. It may be "better form" to use 'Mouse Up' if your mechanical action is NOT 'Switch/Latch when Released' to avoid double events, but in my opinion, the best form is to use 'Value Change' in conjunction with the 'Switch/Latch when Released' mechanical action. There are always exceptions depending on what you're trying to do, but for me this combination is the best method when using buttons on a GUI in most cases. I am after all changing the value. 'Mouse Up' certainly works, but you can get quirky behavior. Have you ever considered that you can click a blank area of the panel, move the mouse over a button, release the mouse button, and BOOM... fire an event! Hardly desired or intuitive action. And if you are concerned about the user changing his/her mind, the 'Switch/Latch when Released' provides the capability to drag the mouse off the button and release without firing the event. In fact, the button displays its previous indication when hovered off as an indication to the user that the action won't be performed. This is standard operation for most, if not all, Windows (and I assume MacOS) buttons. Just my opinion, and as in anything I'm open to discussion and possible persuasion. -Scott

Ditto all the congratulations!

See below, but first a couple caveats. 1) Proceed at your own risk! (okay, it's not really all that risky) 2) May the LabVIEW gods forgive me for stirring up and digging through the bones. Please don't smite me! I agree that talking to Jeff would be the better, official way to go, but... for those who like to play around, I offer the following: After digging around the VIs in the PreferencesDialog folder, you can see the inputs to the Preferences Dialog VI: You'll notice the inputs to the VI, which presumably are passed from the LabVIEW IDE when the dialog is launched. Three of them seem to be of particular interest: props, page VIs paths, & initial page VI. The two path inputs are pretty self explanatory, but props is an unknown. If you create a constant from it, it is identified as a TagSet/PropertyBag refnum, so presumably it is some type of property collection. As these inputs come from the IDE, it doesn't seem possible to add our own page into the list, until you stumble across this VI: It has those same three inputs. Hmmm... We can't edit this VI, but we could rename it and substitute our own in its place. Yea, I know, that's a little sneaky So making several assumptions we can try the following steps: 1) Rename optionsFrame_GetPageTitles.vi to something else 2) Create a new VI and call it optionsFrame_GetPageTitles.vi 3) Call the original version from your new custom version 4) Create all the Controls/Indicators from the original, use the same connector pane, and wire them up 5) Create your new property page from the template. 6) Through whatever mechanism you choose, insert the path to your new page into the page VIs Paths input Save & close the VIs. Open the prefs dialog. Ha! Failure. You get an error saying the page VIs Paths array and the props array are not of equal size. Well, what to do now? Not knowing what goes into props and a loss for anything else, I added the following step: 7) Index off an element of props (I used 0) and add it to the end. Save and Close. Open prefs dialog. Success it would appear! My page now shows up in the list. This is all the farther I investigated. I didn't try to make any custom page, I just used the template as is. I didn't try and see if I could get any settings saved and have them loaded back in. In fact, I get an error when closing the dialog. So I don't know if you can get the framework to take care of saving/loading settings for you without digging further into it. You might need to manage the load/save yourself. But at least you can have your custom settings page accessible from the built-in preferences dialog. Good luck and let us know if you find out anything more. -Scott

As François mentions, "Spreadsheet String to Array" would work well here. An alterantive approach, just to get you thinking about different possibilities uses "Scan from String", which is also on the string palette. -Scott

Absolutely if you aren't already typing a case name in the selector and you only want to add 1 case. But what if you want to add 5 cases... or 10? I guarantee you when you need to do that it is much faster than switching back and forth between mouse and keyboard, right-clicking, selecting, etc... The key is that you can do it over and over again while typing your case names.

I guess this would make a good nugget as well (if it hasn't already been covered). Allow me to explain. If you are editing the case name in the case selector with the text tool: Shift-Enter will give you a new blank case. Ctrl-Shift-Enter will give you a duplicate of the case you were on. In both methods, the new case becomes the active displayed case with the text tool active in the case selector. Type a new name and hit the key combo again. You can rapidly prototype up a bunch of empty or duplicated cases.

WOW! And here I thought it was common knowledge. Incidentally, this is true of any button if you release the BooleanText and move it off the button. Clicking the text will still activate the button. I wouldn't advocate moving text off the button as standard procedure for anything other than Check Boxes or Radio Buttons, though. So does everyone know about shift-enter and ctrl-shift-enter on case structures?