Aristos Queue

There's a tools>>options setting that will change it for all Express VIs. I believe your VI will be broken until you visit the node and configure it.

Create a non-dynamic subVI that has a call to the dynamic dispatch method on its block diagram. Then use VI Server to call that subVI.

Try this menu item: File>> VI Properties >> Protection >> Password Protected

QUOTE (Jo-Jo @ Oct 13 2008, 11:49 AM) An application reference is an instance of the *LabVIEW* application space itself, not your particular VI hierarchy. You can have many top-level VIs open in each application instance. Every Project Window that you open is a separate application instance. If you launch a new labview.exe on another machine, that's another application instance.

You should allow multiple developers to simultaneously check out .lvlib, .lvproj, .lvclass, .xctl and .lvsc files. These files are text files that can be easily merge integrated. They were explicitly designed such that adding a VI to the files makes a purely localized change in the file (ie. there's no "total count" value that has to be kept consistent, and there aren't multiple sections of the file that change as the result of adding a single identity). If the programmer is going to make a change such as moving the file to a new location on disk, then he/she should actually lock the file.

QUOTE (Daklu @ Oct 9 2008, 12:33 PM) Sure... I don't deal with the event structure except for App:Exit and Panel:Close. I don't deal with the front panel except for the LVClass control (and I wrote the alignment grid years ago). I know much about the Project Window but I really try not to work on it except when LV classes require it. I could probably make code changes in VI diff/merge/profiling, but you'd want someone else to check my work. I stay completely out of the PDA, DSC, DSP and embeded modules. The hardware APIs (DAQmx, GPIB, etc) are foreign territory. I don't know shared variables nor timed loops. I don't think I've ever made even a bug fix in an add-on toolkit. And I definitely cannot help you with installers or licensing.LabVIEW is a vast product. LAVA happens to have a high interest in the areas that I work on: the block diagram, debugging (error feedback), the compiler, queues, LV classes. Getting LV to support classes required a pretty broad reach across the LabVIEW landscape, but even as far afield as my team went for that, there are still many areas of the code I've never had to visit. QUOTE (Daklu @ Oct 9 2008, 12:33 PM) I've had this error occur a couple times in the past and I have never had the missing vi show up in the project window, either in the class it is missing from (else it wouldn't be missing) or in the dependencies (as there are no other vis that are dependent on it.) Weird. Ok... my memory of versions may be blurring here. I know LV8.6 reports the missing VIs in a class. I am nearly certain that 8.5 does. And I really thought that 8.2 did. If you have a project in 8.6 that doesn't show the missing file, I'd be interested in looking into that as a bug.

QUOTE (Tomi Maila @ Oct 10 2008, 01:12 PM) No. But in my opinion, your explanation is useful. See, your pictures are of something you'd like to see, but along the way, your text -- by negation -- generally explains how things work today.

Option 1: Create a subVI that uses an uninitialized shift register. As long as the subVI stays in memory it will retain its values. If it leaves memory and gets reloaded, it will have the default value for that shift register. So if every top-level VI calls the subVI, that subVI will stay in memory as long as any of their runs overlap each other. They can put their names or a reference to themselves or something into that subVI and take it out again when they stop running. The other top level VIs can query that subVI for "who else is in memory?" Option 2: Assume that all your top-level VI have some consistent naming convention. Use the Application property "All VIs in memory" and check the list for any other top-level VIs. Option 3: Obtain a single element queue by name and use it to share a list of names and/or references to the top-level VIs. Option 4 (probably closest to what you're looking for): Don't shut down your application. Make what you currently have as top-level VIs be sub components that are loaded and managed by a real top-level VI.

Disclaimer: This is not my area of expertise. If others know better, they may very well contradict what I post here. How much memory you can use is different from how much memory you can allocate in a single block. The limits for LabVIEW should be the same as for any other program that runs on your operating system. Limits for total program memory: If your OS supports virtual memory (and most do), a program can use about as much memory as it has space on the hard disk to use for virtual memory. Limits for a single block of memory: How much you can reserve depends upon whether you have a 32-bit or 64-bit operating system. On a 32-bit system, the largest block you can request is definitely capped at 2^31 bytes or roughly 2 gig. You cannot address more than that in a signed 32-bit number, which is generally what the memory addresses are represented as. There may be reasons why the number is capped lower than that, depending upon how much of the OS can be swapped to virtual memory. If the OS has determined that some part of itself must always be resident in memory then your largest block is 2 gig minus that OS locked up portion. On a 64-bit system, the address space is much larger. Much much larger. And you can request commensurately larger blocks. At the time of this writing, there is no 64-bit version of LabVIEW, but it has been highly requested by customers and NI is aware of the desire for such a version. QUOTE (ragglefrock @ Oct 10 2008, 08:55 AM) Just to be clear: the array (single block of memory) is the one that has the "random access" feature, and the linked list is the one that has "serial access" feature. Linked lists can be built in LV using LV classes. You can find an example program here:http://forums.lavag.org/post-a7270-LinkedList.zip Detailed explanation of how it works can be found here: http://expressionflow.com/2008/01/07/recur...ures-type-safe/

To the best of my knowledge, there is no way to do it directly. You would have to write a new DLL that calls that one. The new DLL would need to export a C function for LV to call.

QUOTE (Pollux @ Oct 8 2008, 03:45 AM) a) The event structure is *the* way to do UI programming. Polling loops or any other style are not recommended for a host of reasons. Any examples you saw that claim to be demos of user interface programming that are not using the event structure are antiquated. b) I found a whole lot of example programs that use the event structure. Just use Help>>Examples and search for "events" keyword.

QUOTE (Daklu @ Oct 8 2008, 12:17 AM) The project window should show you the missing VI, with a bright yellow symbol next to it to make it easy to spot. But beyond that, I do agree with you: that error message should include the file name. Believe it or not, at the point where that string gets generated, I no longer have access to the object itself to get that file name. The interface, written many many many years ago, only passes an error code and some option flags, not an error string. I'm still trying to come up with a creative way to preserve that information without having to refactor the entire error reporting mechanism. It has bugged me since LV8.2.

QUOTE (normandinf @ Oct 7 2008, 07:24 AM) It isn't actually patented any more. The patent expired on Valentine's Day, 2007. But that does still leave the question: How could it ever have been patented? Story Time! When I started working at NI, Jeff Kodosky, founder of company and father of LabVIEW, gave a presentation to the new hires about how NI tries to only apply for valid patents and tries to avoid filing for the silly patents that have plagued software development over the decades. We don't always have the option because in the current patent system, if you don't apply for something, a competitor may apply for it and put you out of business. But by and large, NI has been good about this. A couple days later, waiting for a long compile, I was scrolling through the list of NI patents. And I found a patent on "use of rectangles in a graphical programming language." The patent had Jeff K as the author. And I went to Jeff and I said, "Really? Rectangles? You can't believe this was a valid patent!" As Jeff K explained, the titles on patents never tell the full story. :-) Here's the background: In the late 1960s and early 1970s, the concept of a dataflow programming first formed in various academic settings. A number of papers were published talking about how useful these languages could be in expressing parallelism. There was just one hitch -- no one could express a loop. My understanding (from Jeff) is that the syntax notation for a loop eluded everyone for over 10 years. People tried dotted lines along wires, codas (like in music to jump to a different point in the score), and a host of other things. Nothing could satisfactorally express a loop until Jeff K came up with the idea of structured dataflow and expressing the loop as a rectangle or other enclosing form. In retrospect it seems obvious, but according to Jeff it took him a full year of doodling (and not getting much else done for the young NI corporation) to hit upon the idea. The ideal was novel, clearly non-obvious at the time of discovery, and a significant R&D investment. Thus it justified being patented. The patent actually covered the concept of structured graphical data flow programming, the idea that a region of code -- not a particular wire segment or dataflow instruction -- was how programmers should specify flow-of-control notation for the program. And that's how you get a patent on For Loops.

Using VI Server you can do recursion. It is not as simple as "drop a subVI on its own block diagram" but it does work. See previous post from user pdc for details. For the more direct recursion, you need LV 8.5 or later. (In LV8.5, see <labview>\examples\lvoop\recursion\ for details.)

QUOTE (Paul_at_Lowell @ Oct 3 2008, 05:14 PM) Is that something that ships from NI or is that a third party tool?

QUOTE (Yair @ Oct 4 2008, 01:25 PM) Because many of the class refnums will refuse to cast to each other (wires break) in order to prevent exactly this sort of thing from happening by accident. You really have to think about to consciously decide to do this.

LV R&D only locks binary files. The text files are easy to integrate. [This statement applies to both our C/C++ programming and our G programming.]

If the generic probe did that, there would be riots over it taking up too much screen space. We created custom probes so that everyone could build what they needed/wanted/can't believe LV R&D didn't give them.

Use the Type Cast node to cast your refnum to an int32. Then use the Type Cast node again to cast that int32 to any refnum type you desire. Warning: After you do this, when you pass the resulting refnum to various functions in LV, you may or may not crash LV. It depends upon the operation. After all, you're giving a function a reference to one thing that is actually a reference to something else. Some work, some don't. Caveat emptor.

QUOTE (Rick @ Sep 30 2008, 12:34 PM) Try this: Write a dyn disp function on the parent class that takes in the object (the dynamic input) and an array of parent, and outputs an array of parent. The parent implementation does nothing. The one child that you're interested in does a Build Array to put the object onto the end of the given array. Now call that subVI in a loop to build the desired array.

QUOTE (test001only @ Sep 26 2008, 06:36 AM) Using a dynamic dispatch method in every class is the recommended way of handling this, although the recommendation is to create a method that does whatever it is you're trying to do. I'm guessing that you're thinking of a dynamic dispatch method that returns a name or ID of the object so you can say, "Is it equal to this? Ok, then it must be this class..." and then you do Action X if it is that class. If you write a dynamic dispatch method ActionX.vi and then override it appropriately, you'll save yourself on performance and have much easier time for code maintenance in the future. You can also use the To More Specific node to test if a given object can be downcast to a given type -- this allows for inheritance testing as opposed to the name or ID comparison that only does type equivalence. If the To More Specific node returns an error then it is not of the destination type. So your options are (in order of preference): * dynamic dispatch method that does the action * To More Specific node to do type testing * dynamic dispatch method that returns name/ID of the class of the object * Get Path of LV Object.vi (shipped in vi.lib in LV 8.5 but not added to the palettes until LV 8.6)

QUOTE (jlokanis @ Sep 23 2008, 12:44 PM) You'll have to find a new champion for that. Font runs and string controls are an area of LV I don't typically work in these days. :-)

Nope. Doesn't quite work... The problem is that "Text.Font" comes back as "bold", which is not true of the entire string, just a portion of it. Here's the problem VI if you want to work on this: Download File:post-5877-1222181619.vi

This was reported to R&D (# 127394) for further investigation.

Just to follow up... A lot of the questions you're asking are "system design" type of questions. NI has an army of folks trained in answering those sorts of questions over on ni.com. If you prefer to actually talk to someone, call 888-280-7645. They can route you to someone who can help you choose hardware that will server your project and help identify any issues so you can judge the possibility/impossibility of the idea.