jgcode

I'm pretty sure crelf was being facetious. There is a rumor that on more than one occasion our IT guy has throttled crelfs network because of torrents. I'm sure he was just downloading some large linux distro, and not any copyright protected video content.

Come-on, you can't expect me to be up on inside VI Engineering jokes!

I did think it was weird - I thought maybe the term was lost in translation form over here to there!

Thanks for your response.

As you say, perhaps I could register a separate application (App2) to my custom file extension with command line arguments enabled.

When a custom file is double-clicked App2 would need to either:

1. If App1 is not running - Open App1 and pass the filename with custom extension; or

2. If App1 is already running - Send the filename. An event would need to be triggered in App1.

I like the sounds of TCP/IP as opposed to DDE. How would this work? How would an event be triggered in the event structure upon receiving TCP/IP data (i.e. filename)?

Nice thinking.

Cheers,

Battler.

I am pretty sure VIPM would do something like this, with their VIPM File Handler.exe

You may like to ask on their forums for info too?

I think everyone's missing the point of the DVR. The biggest benefit of the DVR, IMO, is the ability to use the IPE (In Place Element) structure to read write data. Using the structure provides exclusive lock to the data access AND eliminates copies. Doing this with a SEQ (Single element queue) is a PITA and requires a whole bunch of lock and unlock code. On top of that you create extra data copies when you read the queue element.

Data Value Reference Read / Write Element Border Node

I was thinking PITA was some technical software engineering term, but I quickly realised you mean pass in the *ss.

I did not know a data copy is made with a SEQ on a read! Thanks for the info.

Diverging from commonly accepted OOP language is a big mistake IMO. There are lots and lots of books available on object oriented programming. There are no books available on Labview object oriented programming. Anyone who wants to learn how to do OOP in Labview is going to have to read one of the books that focuses on another language. Introducing different terminology confuses the issue and becomes an obstacle to learning. (Heaven knows it's already hard enough to translate design patterns into Labview.)

Great point!

I was not stating an opinion wither way, but I do understand its not going to hold 100% of the time - obviously with unique features (e.g. dynamic dispatching, and by value approach) and consequently a unique implementation - that are different from other languages (namely C++ and JAVA). I also guess thats why we have UML so that we can create objects in a universal language, abstracting the implementation (of language). But most of the previous vocab of LVOOP would have been out of the communities' control.

I guess with the Ideas Exchange we now get more of an input (if anyone is listening )

Cons: Windows XP embedded does not seem to be "officially" supported, although there are a few articles on running labview executables on there.

Hi Mark

I think this might have changed!

After all NI sells Touch Panel Controllers with XPe on it (albeit re badged) - we use them for our applications

I did inquire a while ago about running DSC from XPe which wasn't offically supported either but should have worked.

However I just found this: http://zone.ni.com/devzone/cda/epd/p/id/5956

What National Instruments Products are supported on XP Embedded?

Starting with LabVIEW 2009, LabVIEW Datalogging and Supervisory Control Module (DSC) is supported on XPe allowing you develop and deploy HMI/ SCADA applications to touch panels based on Windows XP Embedded. You can also develop basic HMI applications with LabVIEW Touch Panel Module which is also supported on XP Embedded. The industry-leading NI-DAQmx drivers are compatible with the Windows XP development system allowing you to build applications with Nis high speed data acquisition hardware.

Summary

Windows XP Embedded is an ideal OS for applications that require higher reliability and small footprint while maintaining the power of full Windows XP version.

I am glad I went looking for this and found this out!

I'm also trying! But I'm trying to convience damn print head to produce some droplets for me. I'm giving it such a nice waveform and the only thing I get is bzzzzzzz

Close.. but no cigar

I don't see why either of these would cause us not to use standard terminology for what seems like standard programnming features.

If we want LabVEW to be accepeted as a programming language, which at least some strive for, then we should use programming terminology when talking about it.

For people without programming experience, I don't think it makes any difference what we call it, as the name won't mean anything to them either way and they have to learn the concept.

Should it be a GHEER-MLB or a widget pointer? Which of these would you rather learn how to use?

But the point should be to get away from calling it native anything. Either is native and you don't need to call it that, or it isn't native and needs a different name.

Should they be NLCs* or just classes?

*Native LabVIEW Classes

I am for one am *proud* that LabVIEW has native object references!

And I don't think anyone is asking to complicate things more (e.g GHEER-MLB)

We are just asking for a (as in one) defining, LabVIEW universal term

I don't see the point in having a bunch of names to describe the one thing, or people creating there own (e.g. NLCs)

That IMO, will lead to confusion in the long run.

The fact is LVOOP with DVRs are in LabVIEW which means they are by definition native.

If using native helps distinguish from other flavours of object references (Endevo, Sciware, dqGOOP, SEQ, homemade etc..) then, that will just lead to clarification.

But thats should be up to the authors and/or the LabVIEW community to decide.

Which was the motivation behind creating the topic (that I was interested in what people have to say)

And well if its good enough for the authors to describe them like this...and the community agrees, than who am I to argue?

LabVIEW has mechanisms for creating references to data – uninitialized shift registers, global variables, single element queues – but the user must do more work to utilize these mechanisms than he or she would have to if we had a native by-reference syntax

http://zone.ni.com/devzone/cda/tut/p/id/3574

There is also a great section on the vocabulary in the LabVIEW Object-Oriented Programming: The Decisions Behind the Design - What considerations were given to vocabulary choice? - if people haven't read it, its a great read. LabVIEW is not C++ or JAVA, while it is nice that there is transparancy across languages, it will never be 100%, and needs not be, as LabVIEW will do things its own way - which makes it a unique language - and thats why I love to use it.

There were other smaller discussions on other terms. The chosen vocabulary of OO is a feature as much as any actual aspect of the user interface. In order to make OO accessible, every new concept had to be challenged. We could not assume that the C++ or Java name for a feature was the right name for LabVIEW

http://zone.ni.com/devzone/cda/tut/p/id/3574

I would look at other programming languages and see what they call their classes and objects.

Ahhh... But LabVIEW isn't just any other programming language!

And it's (native) implementation of OOP is very unique (thanks AQ )

Should we use standard terms of other languages?

I have seen arguments for this, and against this, on the forums

Does it hinder or help people learn, who may have or may not have other programming experience???

But I tend to agree - the term object reference sounds clear and concise.

Great point on LVOOP-DVR vs LVOOP-SEQ !!

I am thinking that LVOOP-DVR is the more native approach, as I can see DVR being the future of byRef OOP in LabVIEW, and as such warrents the term native object references IMO.

What do others think?

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

I see the new Advanced Courses are out!

http://sine.ni.com/nips/cds/view/p/lang/en/nid/207398

http://sine.ni.com/nips/cds/view/p/lang/en/nid/202648

Well done to you and Scott.

I don't know whether word "voop" is not too meaningful...

Dude, Kudos for that.

"Dude, why did you just voop my girlfriend?"

I've recorded a screencast and was surprised to see that the various menus didn't appear in the final product. Here's the video. Can you help me get this to work?

Thanks,

Jim

Hi Jim

I gave it a go using Jing and it worked fine.

http://www.screencast.com/users/jgcode/folders/Jing/media/bac74cd6-7641-4e97-9586-dc7a18df2658

Do you have Jing to try?

jgcode: mind connection?

Nice one!

What are you doing write now? I am trying out these Community Scope class with X-controls, are you ?

If you double click the lines in the error list (the picture that you posted) LabVIEW will automatically show you the errors on the block diagram.

The reason you have the errors are that when you use a case structure you must specify an output for each case for every tunnel.

At the very least you need to select Use Default if Unwired.

See how you go with the above information.

By the way, you are missing a subVI in your attachment "multiple time delay match.vi"

It is good to have a UI for the class data. But this could have solved also by allowing XControls to become members of a class. With this concept the XControl is tightened to the class and has direct access to the class data. But it cannot be used without the class any more. So there is no need to have this XControl outside of the class.

This is a great discussion

Was there a reason for (not doing) this?

(Off the top of my head) Is this related to / is there still a problem wrt LVOOP + XControls and infinite recursion??? - I remember AQ mentioned something in a post about a deep architectural barrier, and a problem but can't find the post.

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

No, coz the damn mouse is still jiggered.

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)

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

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.

Cool - thanks for this, this is exactly what I am after

Kudos

What's a "torrent"?

Free media from the net - as in bit-torrent

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

Hmmm, I should stick that on the office door!

And for the record, we didn't have any way of pronouncing "LVOOP-DVR" during development because DVRs are not specific to objects.

Far enough, but did anyone internal coin a phase when they put the two together?

Also what do you prefer?

Did you/where you involved in creating the DVR's?

There are a couple interesting things here in LabVIEW.

First, LVOOP class data is always private. This was a (very good, I think) design decision NI made. It promotes the use of accessor methods, which OO designers generally consider a good idea. (For more on this, see An Introduction to Object-Oriented Programming, 3rd ed., Timothy Budd.)

Second, LabVIEW 2009 introduces the concept of "community" scope (in addition to public, protected, and private). LabVIEW is probably the first language to use such a scope! Setting the scope to community for a class method specifically adds it to the list of methods that a friend can access. (By the same token, methods with community scope are the only methods of the class that the friend(s) can access.)

Hi Paul

Thanks for the links to the updated documents above.

Do you have any examples of where this may be used in a design pattern?

I see that the community scope needs to have static inputs which is interesting.

When pronounced, el-voop-dee-vee-are doesn't take too long

Just on a side note do people pronounce LVOOP:

el-ve-oop

or

el-voop (as Crelf above)

Is there correct way?

I may have been saying it wrong for the last few years

ok, I had the scales set up and added to each channel (as you illustrated), but I was not sure if there was a way to do it in real time.

I will just then start and stop the channels to change it, or maybe I will go back to just reading the voltage and then scaling it afterwards myself so it can be updated real time (the program is not for me, but the foreman on the floor, so the less steps the better)

Because of the need to stop the task in MAX it might be best to do something in LabVIEW.

You could easily update scaling parameter when the user changes the scale.

More flexibility, but more work.

I would just tell the Boss its not possible to do in real time from MAX.

LabVIEW performs cleanup on any references that were created within a VI that is no longer executing. So you need a way to keep your Launcher in memory until all your spawned vi's are closed. Possibly What I would do is feed each Spawned VI a queue ref that they can use to message back to the launcher when they are closed. When all spawned vi's have been closed then you can close the launcher. Perhaps a rendezvous may also work.

The Endevo SEQ avoids cleanup when the caller is no longer executing is because I think you must be running in debug mode. In debug mode the object references are kept alive by a background process, as I understand it.

Cheers - The launcher is very easily solved by calling the UIs as subVIs and using dataflow (sequence structure) to keep everything alive.

Your request/issue for Read Only is inline with Jim's above. Maybe an idea for the exchange forum?

Also I think I found where this new subVI fits in - I used this badboy to recover the data and retain dynamic dispatching - nice!

Is there any other use cases for it?

Is "LVOOP-DVR" is a little long winded

Does the LabVIEW community have a name for LVOOP-DVR'ing?

Is it too confusing to call it GOOP with Endevo, Sciware, DqGOOP etc already out there?

Was there a name that came up at NI Week 09 from NI?

Or is it too soon yet to have one? Can we vote on one?

With all the flavours it would be to be able to distinguish it when talking about it.

I did not see a place in MAX to do a "live" update to the scaling.

Can you point me in the right direction?

Hi dblk22vball

You can easily add scales in MAX, they appear as per below:

You can edit them whilst the global channel is running, but you have to stop and restart for the change to take effect.

There are no "friends" in LVOOP.

I don't understand. Are you able to elaborate please?

Cheers