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.

Mwuhahahahaha! Three config tokens have escaped your grasp! ...  Do they guard any great secret of LabVIEW? I'm not telling!  But you can have fun pouring through the code and looking for interesting bits and trying to figure out what you need to put in your config file.

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

Ok, back on a PC - here it is...VI Server is the issue.

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".

I think there is cross-talk between the two implementations "8.2, 8.6" and 2009!

Indeed. But I like the discussion and will need to catch up on the thread before putting in my $.02.

-Scott

[8.2 vs 8.6 SEQ FGV] I am pretty sure AQ has posted this already on LAVA. From what I recall he said there was an issue with the 8.2 implementation that prompted the fix for 8.6. And that he did not recommend using the 8.2 version. I guess he is the best person to answer.

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.

FWIW the 2009 DVR implementation rocks. I really like the simplicity of it.

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.

DVRs and SEQs do not function identically.

DVRs (when used with LV classes) require you to explicitly verify the data type when you write the in place element structure. This is done using the preserve runtime class VI. This means you cannot change the data type of class (from one child to another or child to parent.)

You can change the data type of a class in a SEQ, as long as the class is a child of the original data type.

~Jon

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.

DVRs and SEQs behave identically (except DVRs have a clearer locking scope because of the IPE structure).

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.

I'm assuming that in 8.2 the example looked different than it does in 8.6.

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

Correct me if I'm wrong,

I have all scripting features enabled (as far as I can see)

the supersecretestuff=true flag hasn't done anyting in a lone time.

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.

could you send the VI for that. (that property is also a super secret public)

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

That would be the Application:MenuLaunch:VI

Darn, you're quick!

Congratulations on 1000 popsts!

-Scott

Isn't the LV 8.6 one prone to a race condition? (Imagine two VIs trying those queue operations at the same time; if the timing is unfortunate, the two would interfere).

I believe that the in-place element structure (IPES?) has an internal semaphore mechanism to prevent such race conditions.

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

Thanks for the reply, but no, the code itself is pretty large and not revealing. My question is more along the lines of given this situation, what debugging techniques do you use? I have used the standard execution highlighting and single-stepping, but they don't seem to be working here. Is there any more sophisticated techniques?

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

does anyone of you know the meaning of this appendix?

thank you in advance,

Vivante

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

Yes, I tried picture Ring ,but the issue is that the items(images) are changed one by one and i couldn't make it like what it is shown in attached image ( all images are visible and user can select one among them)

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

I have an array[6] of controls (SGL data type) and need to reassign the 'max value' of all 6 elements so that the user cannot exceed this value. Normally I would set the 'max value' in the data entry box and be done with it, but this has to be reassigned dynamically once the user has determined this value on the fly. I cannot think of any other way to do this except to use a 'value change?' event to compare the entered value to the present desired 'max value' and force the display to adjust the displayed value as necessary. Anyone have a simpler way to do this?

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

Anyway, I think it's better form to use "Mouse Up" <- this is the more accepted practise (allows the user to change their minds after the mouse down by dragging thier pointer off the button). There are exceptions to the rule though: use "Mouse Down" for links and anything that's related to stopping something so it happens as soon as possible.

I second this idea. I always use mouse up for push button events.

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!

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

Maybe it's just me, but wouldn't it be just as easy to right-click on the case structure and select "Add Case After" or "Duplicate Case"?? I must be missing something here...

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.

Doesn't seem to do anything for me (LV2009) ...

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.

Yep - I didn't know about it.

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?