nhollenback

IMO I think it is very important to have a defined term so it can be mentioned and people know exactly from the get go, the topic (whatever that topic is, design patterns, oop etc...).

Alright - cool then in summary...??

We are still LVOOPing regardless of using either the native byValue (original LVOOP) or byRef (DVR with LVOOP) so if it is agreed by the big wigs I am going to call them native object references, or object references for short.

Can we get a NI whitepaper?

Thanks

Nice summary!! I think everyone would concur on the need for a defined term. We used to have LV2-Style globals, action engines, VIGs, USRs and now we simply have FGVs

Here is a thought from a discussion I had last night with someone who knows nothing about LabVIEW. Perhaps in the quest for the perfect "name" we focus less on OOP and more on a name that reflects the benefit of the technology. For instance, the dynamic dispatch just rocks. In essence we now have intelligent wires. What if we follow that line of thinking and see what pops. Perhaps I'll have a chance to return to last night's conversation.

Regardless, "object reference" was in several comments above. I tend to make the mistake of overly tying DVR with LVOOP when much of the LabVIEW community will use them without classes.

I will check "on high" with the "big wigs" and at least weave a few paragraphs into the Advanced Architectures in LabVIEW course.

So far I have fought the act of sounding silly by saying

Labvoop or lavoop or anything of the sort.

It makes it much easier just to say

I'm going to develop my application with 'native classes' or 'native objects'

and then it just becomes a matter of native class references or native object references

although VOOP is about as close as it gets to something that I would actually bring myself to say with a hope of someone knowing what I'm talking about.

I suppose if I really want to, I'll just make a whitepaper doc on ni.com and that'll be the end of the discussion ~,~

So, I think the object is the entity that is actually created at runtime. And the reference would be to the object. So as Jim Kring said, object reference is the best technical term.

The class refers to the collection of the .lvclass file, with the definition of the private class data, and the methods that act on that data.

And, I think that with the maturity and prevalence of LVOOP, we are at that stage where we can drop the term "native." When I use the term class, it now implicitly refers to LVOOP

So perhaps it is VOOP and VOOP'R.

And since when did you shy away from silliness? (I probably not doing a good job of getting an invite to the editorial board for your white paper)

Why? You just use the SEQ directly to store the data itself. DVRs don't offer anything you couldn't do with a SEQ. They do offer better guarantee of inplaceness and less chances of causing deadlocks, but the functionality is the same as you would get with a SEQ (except you can obtain a SEQ by name and preview its data, which you can't with a DVR).

As for your other question, DVRs are also typed, just like queues and notifiers.

Thanks! My sentiments exactly, you just beat me to the reply!

I wouldn't count on it. NI already has enough named ref-based options to deduce that if they didn't add it to this feature, they did that (or should that be "they didn't do that"? ) deliberately.

The most obvious reason for such a decision is that it would make creating deadlocks too easy. Today, to create a deadlock using a single DVR, you need to bring it over the boundary of a structure where you're using it or pass it inside using a non-dataflow means of communication (local, global, etc.).

If you had named DVRs, you might be tempted to encapsulate the Obtain DVR code in specific VIs and then call them one inside another, ultimately leading to deadlocks without the ability to see where they came from.

I specifically heard at NIWeek that we could get DVR now with out names, or wait for a later release to get DVR and the names. I am glad we have DVR now and will patiently wait for the names.

And I want this flexibility, even if someone may make a mess of it in their code.

BTW - I don't TIVO, or DVR - I Hulu

ame='jgcode' date='16 August 2009 - 05:33 AM' timestamp='1250397189' post='64255']I don't think I could live without it. That and torrents of course![/qupte]

What's a "torrent"?

Thou shalt not progam LabVIEW wilst the missus is watching TV.

But cans't thou post to LAVA while the Missus is watching TV?

One of the purposes behind "friends" is to tighten the relationship (pun intended) between XControls (a type of library) and LVOOP classes. So now there is greater protection in setting up an XControl as the UI for the class data. Prior to this, the XControl would have to access the class data through public VIs. As such any other VI could access the data through those public VIs.

Now, the class can declare the XControl as the friend. Thus there is protection of the class data for anything other than the XControl friend (or other descendants through protected methods).

Hope this helps.

My thinking: LVOOP objects are "data values", so a DVR to an LVOOP object is an object reference.

I concur, it is an object reference.

But... I like acronyms and we've needed one for this amazingly powerful toolset (LVOOP and now the DVR). Why not just VOOP. And when I'm coding it I'm VOOPing. And those who are real good at it are SOOPer VOOPers. And then LAVA can be come LAVOOPA.

Okay, maybe it's just an object reference

My solutions usually come to me in the shower.

Ditto - and on Jim Kring's suggestion, I know keep tub crayons in the shower.

Now I need a way to easily capture ideas when I'm out for a long run.

If you really want named DVRs, just store your DVR in a single element queue and then use preview queue to retrieve it. You could put together a very simple set of VIs to implement this. I used to do something similar with single element queues and variants.

Be sure not to destroy your DVR without freeing the queue or you might end up with Totally Invalid Value Objects, or TIVOs.

But if I'm going to put the DVR in the SEQ, then I will just bypass the DVR and just use the SEQ

And I am TIVOless and hope to remain so

Hi guys

We're working on it and are into to the final testing phase of it.

This should be done by next week.

I hope you can wait one more week.

Cheers,

Mikael

Looking forward to it and happy to do any testing!

I recommend contacting Endevo directly. I would fully expect a release reasonably soon.

As you know they still include some very nice UML to LV and LV to UML code generation features.

Best,

N

Mark is correct. Your first step is to fully understand the Producer/Consumer with Events design pattern that is in the templates browser. (Select File>>New... ).

I highly recommend the Basics 1 &2 and Intermediate 1 courses from NI - no I don't work for them . These issues are addressed in the B2 and I1 courses.

I hope this helps!

Best,

N

data reference is what i like!!

Me too! But I really want named DVRs. Maybe next release.

I really liked the Desktop Execution Trace toolkit. It identifies references that are not closed at run time. When I used it, the only references that were used in the code were for queues. I was very impressed by this feature. But, I cannot speak for every other entity in LabVIEW that may open a reference (ie. property node that might open a reference to a front panel).

Also, I used it in the Dev system. So you may want to return to your source code to identify the problem.

Also again, I'm pretty sure you would have to upgrade to 8.6 (or 2009 now) and it comes at a fee

My advice - check with your local NI Sales Rock Star. And Mark above also has some great ideas!!

Best,

N

Hi Tomas,

I have worked on several DSC projects but have not experienced this yet. First, how are you deploying the shared variables? Second, can you provide some additional information. How did you determine that you had to do the reinstall to get the SVE working again? What other options did you try? What did you see when you launched the Distributed System Manager?

Also, the Colorado LV User Group (ALARM - Advanced LabVIEW Architects of the Rocky Mountains) has spent some time with NI R&D at a recent meeting and we'll be continuing some technical disucssions next week. Check out our community page for more info: http://decibel.ni.com/content/groups/alarm . The current plan is to allow others to remotely join the May 7th meeting.

Nancy

QUOTE (Anders Björk @ Apr 6 2009, 10:05 AM)

Does any of you have experiences in creating a callback on a click on a specific point in a graph using LabVIEW or Measurement studio? An example we calculate RMS values of time series and have plot with these RMS-values. On clicking on a point I would like to make a new window with that time-series. Any hints are valueble.

Is your question directed at the specific use of a VI Callback? Or is it related to determining the appropriate event for the event structure. If it is the latter, perhaps you should use cursors and create an event for the Cursor Release when the user releases the cursor on the point in question (unless someone else has a better idea). If it is the former, what is the scenario that is driving the use of the VI Callback as opposed to a standard Producer/Consumer type design pattern?

Nancy

My LabVIEW Basics II class is quite pleased that they have destroyed LabVIEW productivity world wide. As they are the ones who tipped me off.

And I just happened to show them LAVA after you made this post. :thumbup:

My LabVIEW Basics II class is quite pleased that they have destroyed LabVIEW productivity world wide. As they are the ones who tipped me off.

And I just happened to show them LAVA after you made this post. :thumbup:

QUOTE (Eugen Graf @ Jan 5 2009, 03:25 PM)

Is it possible? I need it to work with other programming languages over TCP/IP. I mean C++ don't really know how a LVOOP Class is flattened (to a binary string), so I want to convert it to a binary data string (Cast).

Thank you, Eugen

Perhaps the new feature in 8.6 that allows you to write an object to xml is what you need..

http://forums.lavag.org/What-s-new-for-Lab...-86-t11549.html

QUOTE (Ben Zimmer @ Jan 4 2009, 04:50 AM)

Tomi,

Thanks for the suggestion.

Would anyone out there (Tomi!!) be willing to donate a bit of their time to write up a quick step-by-step for high school kids to setup SCC with free hosting for LabVIEW? It doesn't have to be simplified or by any means dumbed-down, just complete.

I would be happy to create a video blog based on that document, and link back to the originator's site/blog/company, if you would like.

Thanks,

Ben

Hey Ben, I might have some bandwidth for this. And as I'm starting a FIRST Lego League at my son's school in a few months, the timing is perfect!

Your best source for exam preparation is the LabVIEW Basics 1 and LabVIEW Basics 2 manuals. If there is anyway to borrow these, do so. Pay close attention to the quiz questions at the end of each lesson. These are similar to what you might find on an exam. It's important to prep with NI material, because NI writes the exam and you want to become familiar with the terminology that they use. If you can't get the manuals, scour ni.com for study aids and the practice exams.

Best of luck!!!

QUOTE (normandinf @ Dec 2 2008, 08:07 AM)

Nice... and especially the mood ring.

LOL - and I like the one on good wine!!!

QUOTE (D. Ackermann @ Dec 2 2008, 08:31 AM)

Hello

I am working on a DSC project and am having trouble to find a way to programatically change the citadel logging path of a shared variables libraray.

The application has to run as an Exe. So using the Project properties won't be a solution I guess.

I hope someone can help me on this.

Thanks

Dermot

Dermot - what is the overall big picture? Will this be programmatically changed periodically? Will you need to detach a database at the end of a test?

In my 8.5 DSC application, we first called "Delete Process" before we created the new database. We ran into a few issues that were mostly resolved. Later today I'll dig up the old code and see what else we did that may help you.

Make sure you thoroughly test this!

Your methodology is exactly what we teach in the LV Advanced I course. And I'm not aware of any other solution at the moment (though I am not completely up on anything that may be in 8.6 ). Your solution really is the only way to do it. But, are you also modifying the cluster in the Convert State for Save Ability. Just redefine the cluster with out the ref before you save the VI and then do the reverse on the Init.

I'm teaching LV Adv next week, so I'll try to reproduce your error (Xcontrol remaining in memory) and get back with you. I'll also look at the event name issue on some of my XControls.

But personally I think your best shot is to stick with the dead chicken! :thumbup:

Nancy

Hi Jim,

I have a friend who lives and breaths System Engineering and writing and refining requirements and he recommends the following text:

"Writing Better Requirements" ISBN 0-321-13163-0

But that is just a book - consider starting that conversation with crelf!

Best of luck!

Does anyone have LabVIEW GUI: Essential Techniques? What is your take on the book? BTW - is available on Amazon for $234 :thumbup:

I usually have several folders rather than just one. Devise a process (what ever it may be - www.thinkinging.com has good article) for tracking all VIs that may go into a reuse library. I also have a "Not Used" folder for prototypes and misc code that is no longer currently part of the project, but something that I don't want to toss.