Monday, September 18, 2006

Access Scope

When you give VIs to others to use, they generally fall into two categories: the VIs that they're supposed to call as subVIs (called interfaces), and supporting VIs that they're not supposed to call directly (which are subVIs of the interface VIs).

Pre-LabVIEW 8.0, you had no way to enforce that they didn't call your support VIs. When creating a new version of your VIs, you couldn't be sure whether or not you would break other people's VIs if you changed your support VIs.

In LabVIEW 8.0, we introduced the project library, which (in addition to namespacing) gives you the ability to set private access scope. Access scope lets you distinguish between your (public) interface VIs and your (private) support VIs.

If you're not yet familiar with project libraries (which we usually call simply libraries), let me clear up a common misconception. Libraries are not LLBs. LLBs are containers, where a single file on disk contains multiple VIs. Libraries are separate files on disk from their member items.

You can think of libraries like exclusive clubs. A VI can be a member of one and only one. Being a member gives the VI certain privileges, including the ability to call private VIs in the library.

In LabVIEW 8.20, we introduced LabVIEW Classes, which also have public and private access scope. (Classes are, in fact, a type of library). Classes, however, have an additional access scope called protected.

We used that name because it's used in other object-oriented languages and we couldn't come up with a better one. It is not, in my opinion, a good name. The obvious question is, "Protected from what?" So let me try to explain.

VIs that have protected access scope can be called by VIs in the same class or descendent classes. (That means classes that inherit from the class directly or indirectly).

There are cases in object-oriented design where you simply need this ability. For example, suppose you have a public interface VI for your class, and a support VI that it requires. What should the access scope of the support VI be? At this point, probably private.

But if you then make the interface VI dynamic so that child classes can override it, things change. If you want those override VIs to be able to call the support VI in the parent class, you can't have it be private. But you don't want VIs outside the classes to call it. So you make it protected.

Labels:

9 Comments:

Anonymous Anonymous said...

I have a seemingly random question.
I dont understand why LabView folks are afraid of saving / converting LabView code into something like a text representation?
Its so God-Damn hard for me to use LabView
to analyze anything.

My friends & other LV users in the grad school lab, suggest this as a default
law: Use labview for DAQ . PERIOD.
Use Matlab or Octave for analysis.

Unless you are going to be interoperable
with other textual languages, programming in G or 'drawing in G' is not a option, not for freelancers, not for open source enthusiasts not for people who like to keep their code, and develop it.

There are C++ -> Java -> Python Fortran -> C converters.

There will never be a LV to C converter,
because you guys are killing it.

2:01 AM, September 21, 2006  
Blogger Christina said...

Actually, LabVIEW is highly interoperable with textual languages. You can call DLLs from LabVIEW and you can build VIs into DLLs to call from other languages. In addition, NI has solutions for working with LabVIEW and Matlab.

I'm not sure why you think you need to convert LabVIEW to C. Some people have difficulty believing that LabVIEW is a "real" language, with its own compiler, and think that there's some kind of text language hidden behind the scenes. But there isn't. LabVIEW is a graphical, dataflow language. Converting diagrams to C is not as straight-forward as converting between different kinds of text-based, procedural languages.

If you want to discuss this topic further, I suggest you start a thread on NI's Discussion Forums, where experts (both inside and outside of NI) can address your concerns in greater detail.

Thanks for your comment.
- Christina

11:57 AM, September 21, 2006  
Anonymous Anonymous said...

I dont know, Im biased.
But thanks anyway, if you are
just listening. Im maybe paranoid
if my code I write will get
'stuck' within LabView. Thats
all. Thanks anyway.

11:20 PM, September 27, 2006  
Blogger BryCoBat said...

The problem (as I see it) isn't interoperation between LabVIEW code and C code, written independently. It's support for things like taking an XML definition of an entire domain and being able to generate skeleton classes or custom controls. LabVIEW's great, but there are some software engineering tools missing that can't be written without knowledge of what's actually inside a .vi file.

1:36 PM, October 03, 2006  
Anonymous SRM said...

Anonymous wrote:
> Im maybe paranoid if my code I
> write will get 'stuck' within
> LabView.

BryCoBat wrote:
> The problem (as I see it) isn't
> interoperation between LabVIEW
> code
-snip-
> It's support for things like
> taking an XML definition

Both of these authors are highlighting a concern I'd call algorithm/design portability. Suppose I code a really neat algorithm in LabVIEW. Now I'd like to use that same algorithm in another program written in C. The only tool I have is to write the C code myself while staring at the LabVIEW diagram. No automatic conversion. I can't even write a parser. LV is good about letting you call out to other routines or building LV code into a DLL that others can call into (interoperability), but not porting (translation).

Anonymous is talking about going from G to C code. The problem with writing a translator would be the thread safety. LabVIEW's code is inherently parallel. Simple math equations would end up having Posix thread invocations or something else weird, like a custom assembly address thread scheduling loop.

BryCoBat focuses on the other direction, generating G code from some system. Several tools for doing this do exist (see Endevo, OpenG or LAVA for several). A general API for scripting VIs has been talked about... you can read lots of posts about it on ni.com discussing the problems with the idea.

3:57 PM, October 03, 2006  
Anonymous Anonymous said...

How do we feel about this:
http://eaps.mit.edu/research/group/IGLab/data_sucker.html

Some people do really dont like it,
but unlike many I dont have a 'choice'.
feof() can be copied from stdlib in C.
It doesnt hurt to support C programmers.

11:39 PM, October 03, 2006  
Blogger Christina said...

I don't understand the point that the comment about the MIT application is trying to make. Could you please clarify?

11:57 AM, October 04, 2006  
Blogger BryCoBat said...

Endevo comes close to what I'm talking about. (OOP isn't everything, but it would help.)

I haven't seen anything in OpenG or LAVA other than VI scripting, which is not officially supported at all and requires that you have LabVIEW 7.1. If it were official, I could at least take that and write a half-decent generator on top of it. VI scripting is the sort of power I'm talking about. Basically, I don't want to be limited to the LabVIEW editor for my code, manually dragging wires from A to B ad nauseum. (Any repetitive task should be done by computers.)

In the meantime I'm settling for generating .Net stuff and calling *that* from LV.

11:07 AM, October 13, 2006  
Blogger Christina said...

Good points, brycobat. I'm glad you have a solution that works for now. I don't think I'm allowed to confirm or deny the existence of scripting, but I agree that there's an opportunity for either NI or another company to create the kind of tools you describe. You might consider starting a thread on the NI discussion forums to define what the tools should do, and inspire someone to try to build them.

4:16 PM, October 19, 2006  

Post a Comment

<< Home