Aristos Queue

QUOTE (Mark Yedinak @ Jan 30 2009, 04:42 PM)

I have often thought that if NI were to market LabVIEW more as a pure development language and environment that "much smaller group" would grow much faster.

I have thought so too, but IANAM*.

*I Am Not A Marketer

QUOTE (PaulG. @ Jan 30 2009, 09:35 AM)

I was curious, tried it and it works ... created a subvi, cleared the icon and placed it on my block diagram. Invisible code! You could ruin a team member's day with something like that.

Try checking the VI Hierarchy window.

If you reeeeeealllly want to hide code, you need to make the icon blank AND mark the VI as a system VI so it hides in the hierarchy window.

QUOTE (jdunham @ Jan 30 2009, 03:22 PM)

Even NI Marketing knows that this dual nature of LabVIEW is mostly just a problem for them.

Except that it hasn't been a problem for most of our history. Our bread and butter comes from the zero-experience-with-CS engineers and scientists. Those of you who are skilled programmers and use LabVIEW as a "fully armed and operational battle station" are a much smaller group, though you're growing. But because the bulk of users are in that first group, we do tend to spin LabVIEW for only that first usage. Heretofore it has paid the bills well and we've spread in more advanced contexts by word of mouth and the lone LV user who smuggles a copy of LV into his/her circle of C++-using co-workers. It certainly will be a problem in the future if the "large, full applications" group starts eclipsing the "one while loop around three Express VIs" group, but my understanding is we're still a ways away from that inflection point.

If anyone wants to chime in:

http://tech.slashdot.org/article.pl?sid=09/01/30/1443203

QUOTE (crelf @ Jan 29 2009, 02:47 PM)

There's no "save instrument" method for that I can see for ctl references.

That's because a control is not an instrument.

A *control VI* is an instrument, and those you can save.

To highlight the difference, let me point out that you could open a VI reference to a control VI and then get a control reference to the single control on that VI's front panel. A control reference is always to a part of a VI, which is not a file in and of itself.

QUOTE (crelf @ Jan 29 2009, 04:44 PM)

You could also use methods for Copy Selection / Paste Selection to copy the control from one VI to another blank VI and then save that blank VI.

I suspect that if LV made you enter your password for every individual VI while you're developing -- say, when you double click on a subVI to open it, and then when you tried to open the next subVI, and the next -- someone would come to NI and shoot whoever made that change. It is DEFINITELY NOT A BUG.

QUOTE (Ton @ Jan 27 2009, 11:14 PM)

Maybe any of the http://wiki.lavag.org/Private_events' rel='nofollow' target="_blank">Private events?

Especially VI Redraw and VI Scroll, I think VI Redraw is the one you should study.

None of the private events fire for this. Events in LV are only for things within LV. To the best of my knowledge, none has ever been added for items outside of LV... and, believe it or not, window position is not "inside LV". It is a purely OS event that LV doesn't have to react to for any reason, so it isn't one for which LV itself registers, thus it isn't available to pass along to users.

I believe there is a MS Windows system call that you can make to tell the OS to lock two windows together. My memory says that I've heard another LV programmer use such a technique, but I know nothing more than that. If you're on non-MSWin systems, you might see if that OS has such a function.

QUOTE (jfazekas @ Jan 26 2009, 01:24 PM)

Do you know if it would help to typdef the array into a LV Class control?

Shouldn't have any effect -- if the array needed to be copied then the class will need to be copied. Basically, if you're doing something that requires a copy, then a copy is going to be made. Whatever it is, stop doing it. :-) Some things that would cause a copy:

* Using any sort of Global VI to store your data

* a functional global where you use get and set actions to copy the value out of the global and then back into it later

* forking the array wire to two write operations (such as Replace Element or Sort 1D Array etc). As long as you never fork the wire or fork to all readers or to a single writer and the other branches are all pure-functional readers, then you shouldn't have any data copies.

What are you doing in those analysis functions? Are they "destructive analysis"? In other words, do they do stuff that replaces values in the array, which would cause a copy to be made so that you can call the next analysis function?

By the way... could someone else check my work? I don't want to mislead anyone who reads that, and I just typed it from memory without actually working through the steps.

You say you're having trouble coming up with the inheritance hierarchy... here's an easy way that might not be optimal but would get you started:

Pretend you're writing the enum-wired-to-Case-Structure that you talked about initially, with one of your DUT VIs in each frame. We're going to use that as a starting point for the class hierarchy...

1. Create or open a project.
   
2. On "My Computer", pop up and select "New >> Class" and name the class "ParentDUT.lvclass". This creates the class and its private data control. Ignore the private data control -- we're going to leave it empty.
   
3. Pop up on ParentDUT.lvclass and select "New >> VI From Dynamic Dispatch Template". Edit this VI so that it has the connector pane of your DUT VIs, but leave that "class in" control alone -- it is going to be the placeholder for the typedefs that you were talking about in your original post. Leave the block diagram untouched. Save this VI as "DUT.vi"
   
4. Now, for each frame of that case structure that you were building, create a new class and name that new class one element of the enum. So if the enum has strings "DUTA" "DUTB" and "DUTC", you're going to end up with three classes named "DUTA.lvclass", "DUTB.lvclass" and "DUTC.lvclass".
   
5. Save the class -- save every one of these classes to a separate subdirectory. Common practice is to name the directory the same as the class without the .lvclass file extension.
   
6. Pop up on the "Whatever.lvclass" and select Properties
   
7. Go to the Inheritance entry. Click on the "Change Inheritance" button. Change the inheritance so that "ParentDUT.vi" is its parent. Hit OK to close the Properties dialog.
   
8. Double click on the private data control for "Whatever.lvclass". You'll get a control VI with an empty cluster on it. Fill that cluster in with all the stuff you would've put in the typedef. When done, save and close the control VI.
   
9. Pop up on "Whatever.lvclass" and select "New >> VI for Override..." When the dialog appears, select DUT.vi.
   
10. A new VI is created. Fill this VI in with whatever functionality you want for this type. You can unbundle that class wire to get at all the data that you packed into the private data control. Save the new VI -- LabVIEW will start you off in a directory and assume a VI file name. Just accept both the default name and location --- that will put each DUT.vi next to the class that owns it.
    
11. When finished, do File>>Save All.
    

Alright... there's your inheritance hierarchy. Now we need to invoke it...

1. Create a new "Run my tests.vi". In all the following, when I say "the VI", I'm talking about that one.
   
2. In the example code that you posted, you used the DUT enum to pick out a VI to load from your support\boards directory. We're going to do the same idea but altered just a bit. Given the value of an enum, build up a path to the class -- remember that each one is in a directory that is the enum string and is a file that is the enum string plus the file extension.
   
3. On your diagram, drop the "Get LVClass Default Value.vi", found in the same palette as the bundle and unbundle nodes. Wire the path up to the input.
   
4. Drag from your project to the block diagram the "ParentDUT.lvclass". You now have a block diagram constant of the parent class.
   
5. Drop a "To More Specific" primitive on the block diagram (also in the same palette as bundle/unbundle).
   
6. Wire the constant to the middle terminal of "To More Specific". Wire the output of "Get LVClass Default Value.vi" to the left input of "To More Specific".
   
7. Drop DUT.vi as a subVI (just drag any of the DUT.vis from the project tree to the block diagram -- it doesn't matter which one you drag).
   
8. Wire the output of the To More Specific prim to the input of the DUT.vi.
   
9. Wire up any other inputs to the subVI that you want.
   
10. Run your VI.
    

There you go. Dynamic dispatch magic over a VI hierarchy, generated, almost by rote recipie, from an enum and a set of typedefs.

Good luck!

QUOTE (Tomi Maila @ Jan 26 2009, 03:10 AM)

Is there an XML schema for VI structure used by NI internally?

Nope.

What is the annoying message? Can you tell? That might help identify something to be done about it.

QUOTE (Eugen Graf @ Jan 23 2009, 10:19 AM)

Yes, this info is exactly what I needed. Would you give me please a link, where inplaceness in LabVIEW is describen very well.

No. Because if I gave you such a link, you'd start caring about it. Stop caring. Really. Let LV make copies when it sees that your code needs copies and stop worrying about it. If you really hit a performance problem, you can dig into the topic further, but until then, let it go. It is almost never of interest to a LabVIEW programmer.

Last year, user vugie posted VIpreVIEW

http://forums.lavag.org/VIpreVIEW-Interact...iew-t10211.html

It allows you to create a Flash application from your VI, so you can post your VI to the web and people can still flip through the frames of the case structures to see all your code. Kind of neat.

Someone commented that it would be cool if you could record a VI running and create a movie playback of the execution highlighting. Well, that turned out to be a hard problem given the access you have into LabVIEW. So I slipped in a bit of code right at the end of the 8.6 release cycle to help with this situation. And then I forgot to post about it when we released 8.6. :-) So here it is... It isn't the easiest to use, but the runtime engine has a very restricted set of information available, so the hook I'm providing, while primitive, is about as advanced as you can hope for.

This is an .ini token you probably already know about:

DPrintfLogging=true

If this is in your config file, then LV will log a whole bunch of information to the same log file that DWarn dialogs get saved to. It's a huge amount of junk and most of the time you don't want to read through it. (Side note: Trust me when I say these logs are boring. I sometimes wish that customers would edit their log files before they send them to NI to include some salacious gossip or poetry or a really good joke just so that when I'm reading through the logs trying to debug something I could hold out hope that something interesting would be included instead of the mind-numbing stream of hex addresses and object IDs...)

I have added a new token. The new token only works if you have DPrintfLogging turned on. The token is

ExecHiliteTracing=true

When this is enabled, LV will print to the log file information about execution highlight drawing. Every line starts with this text:

ExecHiliteTrace

and is then followed by a single character that indicates how to interpret the rest of the information (described below).

When execution highlighting begins on a given VI, LV will print a line like this:

ExecHiliteTrace+ 0xABCDEF01 c:\foo\bar.vi

The hex number is a unique ID generated for each VI, guaranteed to be the same as long as that VI stays in memory. The path is the path to the VI that is highlighting. If the VI is unsaved, this will print out NULL, so the info is useless for unsaved VIs, unless you know for sure that only a single VI is currently highlighting. Reentrant clones will each have their own index, but the paths will be the same as the real VI. Note that this line may be printed multiple times while execution highlighting is running. This indicates that LV has switched back to this VI to update it some more. If multiple VIs are executing in parallel, you'll get one of these lines every time LV switches to a different diagram.

Every time that an execution hilite dot draws, we will print out

ExecHiliteTrace: 0xABCDEF01 x y

where x and y are screen coordinates where the execution highlighting dot drew. You'll have to figure out which signal is at these coordinates. A pain, I know, but there's not much I can do to help it because there's nothing else I can print out that has any meaning at the G level where this information would be parsed. I can't return any refnums because that would require allocating them, and that's not safe to do during exec highlighting.

When the exec highlighting needs to change which frame of a structure node is visible, you'll get this:

ExecHiliteTrace~ 0xABCDEF01 frame top left bottom right

where frame is the frame index that needs to display and top, left, bottom and right are screen coordinates of the corners of the structure node. I can't print anything that can be more directly mapped to which node -- you'll have to search through the struct nodes of the diagram and figure out which one is the one to change frame. This should always be a structure node that is already visible, which means there will always be a unique node that these coordinates map to. The only exception to this uniqueness could be if you're using lots of nested sequence structures -- we might have lots of sequence structures all flip to show frame zero at the same time. But honestly, I'm not too worried about making this work for people who have lots of nested sequence structures. :-)

When execution highlighting is turned off on a VI, you'll get

ExecHiliteTrace- 0xABCDEF01 c:\foo\bar.vi

Ok... so what do you do with all these print outs? Open the LV log file and remove all the lines except those that start with ExecHiliteTrace. "grep" is a spectacular command line tool available on Mac and Linux and you can download versions online for Windows. Now use the remaining lines to generate playback information for a VI. VIpreVIEW could use this to actually create a movie of the VI running. I've always wanted to build an exec highlighting flight simulator, where the nodes are shown in 3-D and you have a "first person view" of being the data going down the wire, with barrel rolls whenever you switch to a parallel wire, and the nodes exploding as you fly over them. Someone could use this info to build such a movie. You're free to brainstorm your own...

Summary:

QUOTE

+ starts exec highlighting for a given VI

: is a dot of highlighting drawing

~ is changing which frame of struct is visible

- ends exec highlighting for a given VI

Enjoy!

Just because the subVI gets the entire class does NOT mean that the entire class gets copied. If you pass a class into a subVI then unbundle a single element, the class is not copied at the call. If you then use that single element in a read-only way (for example, connecting it to the select terminal of a case structure) the class is still not copied at the call. If you use the element in a write operation (such as wiring it to the Increment primitive), the element is copied, but the class is still not copied at the call. If you then bundle the incremented element back into the class, the class MAY be copied at the call, depending upon whether the particular call itself is already set up for writing (for more details see the large body of documents across the WWW about "inplaceness").

Is that enough reference for you?

LV8.5.1 is free for anyone on the SSP, which was sold bundled with all copies of LV8.5, so you definitely had it at one time. So as long as your company has kept your subscription up-to-date, you should have CDs for it somewhere. The ni.com SSP download site *might* still have 8.5.1 posted -- you'd have to check.

QUOTE (Eugen Graf @ Jan 22 2009, 01:18 PM)

No, I didn't

Then where did the file path subVI come from? I've never used that subVI before to the best of my knowledge. Maybe it was introduced by the save-for-previous process to maintain some sort of binary compatibility?

QUOTE (Ton @ Jan 22 2009, 01:07 PM)

Yes we can!

However we can't really control them well.

If you open up a private context there should be a way of closing that context well.

Calling the "Close Reference" primitive ought to do it. I take it from your post that that doesn't close the context?

[LATER] I have asked Those Who Know and they say this: "If you create a temporary app instance and then you open a VI reference to a VI in that app instance and then you close the app reference, the still-open VI reference will keep the app reference in memory." In other words, you have to close all the VI references and all the app references in order to make an app instance shut down.

QUOTE (paracha3 @ Jan 22 2009, 01:08 PM)

@AQ, i tried your zip file just now, no changes made. When i run the VI, yes it works and i do see "Kid". Then i build executable, it says Parent when run. See attached screenshot of exe.

Hm... I'm running 8.5.1. Are you perhaps running 8.5.0? I don't know of anything that got fixed in that bug fix release that would affect this, but maybe there was something. Other than that, I have no idea what could be wrong.

Yes. 8.2.1 has exactly the same binary compatibility for the runtime engine as 8.2.0. Test your app first because there were runtime behaviors that were fixed, and if your app happens to need one of those fixes, you could have issues. But those are very rare and in all likelihood your app will work just fine with the 8.2.0 engine.

For the record, the same is true of 8.5.1 with regard to 8.5.0.

I just tried Eugene's 8.5 .zip file -- it works just fine in 8.5.

Eugene added a bit of extra code to it to make it more interesting... here's the 8.5 version stripped back to just my original example.

Download File:post-5877-1232650822.zip

QUOTE (Antoine Châlons @ Jan 22 2009, 07:25 AM)

The "links & relationships" between the LV app, projects and contexts is still a bit hazy for me, I'd have to dig into that when I get a moment.

..But if anyone has it clear in his mind I'd appriciate some explanations

a) The term "application instance" is used in all public documentation, but in the LV C++ code, those same things are called "contexts". Because R&D folks occasionally post to customers without tech writers reading over our shoulders, we slip up and use the other term. So you should generally regard those terms as interchangeable, but know that "application instance" is preferred for a long list of (very good) reasons.

b) An app instance is very nearly an isolated LabVIEW.exe. The VIs in one app instance cannot interact with the VIs in another context unless they do the same things that would be required to talk to a VI that was loaded on a separate machine entirely. So whatever you would do to talk to a network VI is the stuff you generally have to do to talk to a VI in another app instance.

c) Application Refnums are the references to an app instance. Prior to 8.0, you would open an app reference to an entire LabVIEW execution system. Now you open an app reference to one app instance within the execution system.

d) All LabVIEW files -- VIs, libraries, projects -- load into an app instance. The same file may be loaded into multiple app instances simultaneously. Editing one of the "reflections" (a term that R&D uses which is distinct from "clones" of a VI, which has to do with reentrancy) does not change the other reflections of that file until you synchronize the app instances (either by pressing that green arrow button that appears on the VI next to the Run arrow OR by saving the file).

e) Projects are loaded into an app instance, but they also manage a set of app instances. The "My Computer" instance is the one that the project is actually loaded into. If you add any targets to a project -- an FPGA target, RT target, etc -- those are other app instances. *All* of the app instances that a project creates, including the "My Computer" instance, are life-time managed by the project, meaning that when you close the project, you close the app instance, which closes out all the VIs and Libraries loaded into those app instances.

f) Any given app instance may be owned by zero or one projects, but not more.

g) LabVIEW has multiple private app instances, including the "NI.LV.Dialog" app instance which is where VIs from the Tools menu run. These private contexts allow tools written with VIs to run without interfering with the user app instances, so there is never a chance of one of those VIs cross linking with user VIs or keeping a user VI from being able to load because a VI of that name is already in memory. Various parts of LV will create temporary app instances -- for example, AppBuilder creates a temporary app instance which it loads all the source VIs into so that it can rename them, strip diagrams, etc, without touching the user's original source files.

h) Users can create their own temporary app instances. I believe the Open Application Refnum primitive can be used for this by providing a unique port number to the primitive. There are other methods as well. This is an area of LV where my knowledge is pretty weak and others may be able to fill in more details.

You know what might be better? What if we had a forum section specifically for *professors* to post their assignments, so that everyone in the community knows what the latest assignment is, so when a student asks a question, we all know it's part of his/her homework, and, further, there's a discussion thread that those students can all go off to to talk about possible solutions.

Here's a simple example that works.

Download File:post-5877-1232598869.zip