Aristos Queue

QUOTE (Eugen Graf @ Jan 23 2009, 10:19 AM) 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 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) 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) 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) 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) 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

Did you tell the project to put the class files inside the EXE? The only ones that are inside the EXE are those that are used by the Source files. If you want other files to be included in the EXE, add them to the bottom section where it says "Always Included".

QUOTE (paracha3 @ Jan 21 2009, 01:33 PM) The .lvclass file is inside the .exe, along with all the other VIs. You should be able to do dynamic loading of it by taking the current path from your top level VI and appending "..\classname.lvlcass" onto it, just as you can for creating the path to any VI inside the .exe.

*grumble grrr* LabVIEW's expected behavior is "if we detect two VIs of the same name in different classes then just assume that those go in a folder next to the EXE, with subfolders for each class." You shouldn't have to specify any paths to save the VIs to special locations -- including the class in the build should be sufficient and LV should handle the saving to a folder beside the EXE. And you will get the build warning that the VIs were put next to the EXE instead of inside the EXE. Disadvantages 1 and 2 are thus expected behaviors and there's nothing you can do about it. As for disadvantage #3 QUOTE Try to name the VIs that you want to dynamically load by a unique name so they get packaged inside the EXE. That's all the help I can offer. Now, having said that, I am sick and tired of this behavior, and I will seriously contemplate doing everything I can to hold the LV CD from being shipped to customers if the next version of LabVIEW doesn't allow multiple VIs of the same name to be stored in the EXE. The feature/bug fix (depending upon your point of view) is finally getting attention. I still can't promise it will be fixed because unforseen difficulties can put the kabosh on any new development, but I'm putting all the pressure I can to get this fixed.

QUOTE (Dave Graybeal @ Jan 16 2009, 02:39 PM) It won't be documented in any of NI's buglists since that option does not officially exist.

QUOTE (Dave Graybeal @ Jan 16 2009, 02:39 PM) It won't be documented in any of NI's buglists since that option does not officially exist.

I asked your question of the person who developed the File I/O functions for LabVIEW. The answer: "Unfortunately there isn't any built in way to do that. The suggestion he already got (to use system exec.vi) is the easiest way I know of."

QUOTE (jpdrolet @ Jan 15 2009, 11:24 AM) You speak of "OS" singular. There are many OSes, and not all of them treat shortcuts as files. LV's behavior is consistent across all the OSes that we run on.

QUOTE (jpdrolet @ Jan 15 2009, 11:24 AM) You speak of "OS" singular. There are many OSes, and not all of them treat shortcuts as files. LV's behavior is consistent across all the OSes that we run on.

QUOTE (Omar Mussa @ Jan 15 2009, 02:18 PM) CAR 140811

QUOTE (Omar Mussa @ Jan 15 2009, 02:18 PM) CAR 140811

Another NI employee who read this post has just let me know that, yeah, he saw something like that once, in LV8.6. He also cannot reproduce the issue, although in his case, it happened to many classes when he did some batch processing on them. This isn't enough info for me to even file a CAR much less debug the problem, but I'll keep my eyes open when I'm working on other CARs related to saving and/or property editing for problematic code snippets.

Another NI employee who read this post has just let me know that, yeah, he saw something like that once, in LV8.6. He also cannot reproduce the issue, although in his case, it happened to many classes when he did some batch processing on them. This isn't enough info for me to even file a CAR much less debug the problem, but I'll keep my eyes open when I'm working on other CARs related to saving and/or property editing for problematic code snippets.

I've never heard of this bug. I could not replicate it in 8.2 or 8.6. Is there something special about the particular class that you are updating?