Aristos Queue

The attached VI is saved in 8.5.1 (which means it will load into 8.5 just fine). The VI is still password locked, but I've added a new input to the conpane. Download File:post-5877-1213284663.vi

QUOTE (neB @ Jun 11 2008, 09:04 AM) No. It is perfectly legitimate to store a LVClass in any functional global, including action engines.QUOTE I ask because I have often read LVOOP as being an alternative to AE's and am concerned I am failing to get the whole LVOOP idea and am "just putting lipstick on a pig". What I suspect you've read is my ravings about a better way to write the action engine itself using LVClasses. That new, revised action engine still stores data just like the ones you've written for years, and it can store any LV data, including LV classes. But it is more extensible and reusable. If my guess is right, you think you've read "LVOOP is an alternative to AEs" when what I have said is "LVOOP provides an alternative implementation for AEs".

QUOTE (Eugen Graf @ Jun 9 2008, 04:21 PM) This isn't the kind of information I would ever put into a tutorial for beginners. It's theoretical information for folks who are interested in language theory. I can pretty much guarantee -- based on almost a decade of teaching LV to programmers of C++ -- that it would be very unhelpful to get any programmer to actually think of wires as variables. It doesn't work to think of the dataflow that way. You'll end up with people dropping controls as a way of "instantiating" a variable (i.e. giving a wire a starting point). Trust me on this. I've seen it happen more than once. LV is best explained as data which flows from node to node, and noting the wires merely as connections between nodes. Don't try to get into any "a wire is a variable" nonsense. QUOTE (Eugen Graf @ Jun 9 2008, 03:46 PM) So a tunnel will copy the data from one wire to other and is a node at all because of copy action ? Ok. A tunnel is neither a node nor a wire. A tunnel is a tunnel. And depending upon what structure that tunnel is on, it has different behavior. A tunnel on a sequence structure is a no-op. A tunnel on a loop is not. But you cannot define a tunnel in terms of "variable" and "function". It is a director in the dataflow. QUOTE Is a input or output of a subvi a node? Do it copy data? I think no, but I am not sure. A subVI call does not copy data, though it may be what causes a forking wire to decide to copy of data.

QUOTE (shoneill @ Jun 10 2008, 10:24 AM) The following is commentary from a developer who has never used IVI, never written an IVI driver, never looked at an IVI specification. I've just sat next to IVI folks for the last several years and overheard conversations. Many of them had input into how LV classes were implemented in LabVIEW.My understanding is that IVI, as a specification of an API, is not invalidated by OOP but rather it is fulfilled by OOP. We can now define the framework VIs that IVI calls for once, in a parent class, and then have each driver be a class which overrides the framework with the specifics needed for its purposes. This is an area where I personally believe LV classes could lead to a major reduction in the amount of code that a driver author has to write. I would be very happy to hear of any success stories that driver authors have using LVClasses in this manner.

QUOTE (Eugen Graf @ Jun 9 2008, 03:37 PM) Pass it through the conpane. LabVIEW will not make a copy just because you pass it to a subVI. As long as you are passing data using wires, you only have to worry about a copy being made if you fork the wire -- and LV will only sometimes make a copy then. If LV can avoid making the copy, it will do so. If you have a very large dataset, pass it into the subVI and then pass it back out again on the other side; don't fork the wire to pass to two different subVIs in parallel.

VIs that use dynamic dispatching can be public or protected, but not private. This is one of those decisions that could have been made either way and really comes down to my team's philosophy of design. There are good arguments on both sides (and, in fact, C++ made the opposite decision and allows private virtual). Our reasoning goes like this: A VI marked as "private" is contracted to never be called outside of the class. A dynamic dispatch subVI call chooses at runtime which of several VIs to actually invoke. Each of those VIs is at a different level of the hierarchy. There's no way for the contract of "private" to be kept if you allow dynamic dispatching to work -- somewhere there must be a caller that is not inside the class that is invoking the method, and thus is occassionally dispatching ot another level of the class. C++ made the opposite decision, under the argument that "private" for a virtual (aka dynamic dispatching) function means "only the parent class can call this method set, but each level of the hierarchy is free to define the behavior for that private call". Neither decision is wrong, but, in my not-so-humble opinion, one is a lot easier to explain to folks.

QUOTE (crelf @ Jun 9 2008, 10:15 AM) More exactly, the *act* of copying data can be considered a node. Wires are data. Nodes are actions. Specifically, nodes are actions on that data.

A wire is equivalent to a C++ const variable declared on the stack. In other words, it is a variable that you can only assign to once. Nodes are the functions that read those variables and write new variables. Having said that, a wire that forks is a bit different. This NodeA ------------------+----------------NodeB | | | +----------------NodeC is equivalent to this: NodeA ------------- CopyNode--------------NodeB | | | +----------------NodeC

QUOTE (jgcode @ Jun 8 2008, 10:17 AM) No. Although LV will let you typecast one into another, you'll find that it doesn't work as you would expect it to work. When you open a strongly-typed VI reference, the VI is actually reserved for running. Just typecasting will not do this reservation, and trying to use such a refnum with the CBR node will just give you an error.QUOTE 2) Is there any problems with having two refs open at the same time as I launch the plugin - should I clean up my refs a different way? (NB: I have to keep the VI in memory to keep the changes or I will lose them). No problem at all. Open the weak ref first, do your edits, then open the strong ref to do the CBR.

Yes, it would make a lot of sense to allow this for polymorphic VIs. Unfortunately, we didn't have the idea until late in the game and the architecture we use for testing scope has proven inflexible for making this work. It's a low priority desirable behavior.

QUOTE (marp84 @ Jun 5 2008, 11:17 AM) Marp84: I truly cannot understand the question you are asking here. I'm impressed that Neville was able to put together a reply. It would make communication a lot easier if you took the time to use some punctuation and grammer in your questions. Some users get upset at requests like these. I'm not trying to scold you like some elementary English teacher. I just want to be able to read the post. Otherwise I -- and others -- cannot help you. I make a lot of allowances for the non-English speakers who are using automated translation tools, but I'm pretty sure that's not your situation.

Hm... after hearing these comments, I'm starting to think you might not like the new "in person Clippy" that we were going to ship with the next version of LabVIEW. It's a hardware accessory -- a human-sized Add primitive with eyes, legs, arms, and, most important, a mouth. He'd hide behind your chair and every time you dropped a node from the palettes he'd jump out and say, "It looks like you're writing a VI!" It really seemed like a good idea, but you guys are making me reconsider it.

QUOTE (David Boyd @ Jun 3 2008, 10:03 PM) Use the NI Product Suggestion Center and recommend this as an option. http://digital.ni.com/applications/psc.nsf/default?OpenForm

QUOTE (Tomi Maila @ Jun 4 2008, 01:26 AM) Yeah, that's a primitive that really ought to have error in and error out terminals. It doesn't handle infinite memory allocation (which is what you've done here). Probably worth filing a CAR. Do you want to do that or should I?

QUOTE (Pollux @ Jun 4 2008, 06:15 AM) If you post a request, generally someone on this forum who owns the later version will voluntarily do "Save For Previous" to move an example back to your desired version, assuming that the example is one that your older version can support. Some features don't exist in the earlier version and so doesn't load.

QUOTE (Tomi Maila @ Jun 3 2008, 03:04 AM) Not really. I mean, there's no way to just continually get more and more allocation of memory on successive calls to the VI. There are two buffers. The first one gets large, gets swapped into the second. Then the VI runs again. The first one gets large and swaps with the second. When something small comes down the wire, it reduces the first and swaps with the second. Now something small comes down the wire again. Now both buffers are back to small. If you're in a case where this is really a concern -- ie, when a large piece of data comes through the system only very rarely AND the subVI doesn't get called again very often -- the Request Deallocation prim will deflate all your terminals.

I'm fairly confident when I say this: If you're not using dynamic dispatching, turning on this option can only hurt your performance. There may be some corner case use for it, but I'm not aware of one. All it does is force LV to treat something that wouldn't be a writer to be a writer.

I agree it seems like an odd choice on our part. Having said that, I can't resist pointing out that if you stop using clusters and start using LVClasses, you'll get a coherent data type. :-) [LATER] Ok. After a bit of thinking, I can explain why this was done, I think. By having LV automatically unbundle the top-level cluster elements, you have the ability to have items at the top level of your event handler, so you can have common elements between disjoint user events. In other words, I can have user event Alpha with cluster "A (numeric), B (double), C (path)" and user event Beta with cluster "A (numeric), D (boolean)". If I ever have a single frame of an event structure that handles both events, the left hand event data node will show only the elements that are in common. If we treated clusters as single elements, you'd have nothing in common between the two user events. But because we unfold top-level items, you'd end up with "A (numeric)" being available in the event case.

QUOTE (Cmal @ Jun 2 2008, 10:03 AM) Here's how: http://forums.lavag.org/index.php?s=&s...post&p=5194 You might also follow up with this link: http://forums.lavag.org/index.php?s=&s...post&p=5190

You need an actual driver update to make the NXT work with Vista. I've heard rumors of a driver update.... a bit of web searching turned up this on www.mindstorms.com : How do I run the MINDSTORMS NXT 1.0 software on Windows Vista?

Being able to run on RT systems is not the same as being able to run deterministically inside the real-time loop. I do not know whether any of the toolkits can run deterministically given that there is at least some data locking to prevent concurrent access to referenced objects. But I could easily be wrong. My point is that there's another question that needs to be answered by authors of the GOOP toolkits when we're talking about "working under RT".

QUOTE (eaolson @ May 21 2008, 05:44 PM) Ok. You got me. Now I want customizable badges too. :-)

QUOTE (neB @ May 21 2008, 01:35 PM) No need for a test. This is when LabVIEW, the sentient AI that sits behind all diagrams, decides that you're qualified to do civil engineering projects. LabVIEW *does* the certification. :-)And, for the record, if you don't like the badge options, there's always duct tape and construction paper. Of course, that sort of defeats the whole purpose, finding those who picked similar icons who might have similar interests. If the icon set is open ended, there's really no point to the whole thing.

QUOTE (Daklu @ May 20 2008, 02:14 PM) Open the List Errors Window. In the list of files, scroll to the very top. The items with a red X are the items that are really broken. Everything else is broken as a result of the red X items.

LabVIEW should be able to extend the same level of control over an external program that any programming language could do. In other words, if Poser has either a command line interface or a callback DLL that allows external commands to be sent to it, then LV can use that. If Poser doesn't have any such external interface, then you're not going to be able to control Poser no matter which programming language you use. For the command line interface, find the System Exec.vi in the palettes. For the DLL interface, use the Call External Library node, also in the palettes.