Aristos Queue

QUOTE (candidus @ Apr 24 2009, 03:54 PM) I think you miss something. This library covers all LV types.

QUOTE (Yair @ Apr 24 2009, 04:20 AM) Good catch. I botched question 2. I meant it as follows: http://lavag.org/old_files/monthly_04_2009/post-5877-1240605989.png' target="_blank">

QUOTE (rolfk @ Apr 24 2009, 02:52 PM) vi.lib\Utility\VariantDataType

Having just explained this to someone, I thought this might someday be a good question for the CLD exam. Note that although the question is being asked about Notifiers, it applies to Queues, VI refnums and, indeed, every refnum type in LabVIEW. I'll post the answer as the first reply so that the answer isn't visible on the main LAVA page.

I've been asked about queues on RT a few times this year and I gave the wrong answer, so I want to correct that here because (a) I don't remember exactly who I was talking to and (b) I don't know who else in the community may have heard my answer from those original people. If you call Obtain Queue and give it a maximum size for the queue, on RT the queue will go ahead and allocate its buffer to be the maximum size. I was incorrect that you need to have an initial loop to allocate space in the queue before you use it. The "allocate space on RT" behavior goes back to LV 7.0. Only in LV 6.1 did you have to have an initial loop to allocate the buffer. I apologize for anyone that I misled.

QUOTE (Mark Yedinak @ Apr 22 2009, 04:58 PM) A non-trivial task? Really? So, in other words, you'd be impressed if LabVIEW could do that? We're always looking for features that would impress our customers... I'll let some of my developer buddies know that you'd like to see that in the August 2009 release... :ninja:

Unfortunately the VI changed between 85 and 86, so it isn't as easy as just saving for previous.

On the case structure, ask for the Diagrams property of the case structure. For each diagram, get the subVIs on that diagram. Repeat recursively for any nested structure on the diagram.

QUOTE (orko @ Apr 21 2009, 01:18 PM) Suppose I have X.lvclass which as a member VI Y.vi. Normally Y.vi takes the class in and does something. I now create WrapperY.vi which takes as input an unsigned 32-bit integer (uInt32). On the block diagram of WrapperY.vi, I either give that uInt32 to an LV2-style global that indexes its contained array and returns an object to me [the obvious way of coding this -- using Index Array -- will create the overhead of a copy of the object out of the array, but that can be avoided by swapping a default value object into the array... see online help for the Inplace Elt Struct in combination with the Swap primitive.] OR type cast that uInt32 as a refnum of some type -- perhaps a queue refnum, perhaps a GOOP refnum, or something else entirely -- that is the data storage mechanism that I've chosen to hold onto my object, and get the object out of that data storage mechanism. With the object now in hand, I call Y.vi. If Y.vi passes the modified object out, I store the output back into my LV2-style global or my refnum architecture. QUOTE (mesmith @ Apr 21 2009, 02:25 PM) Of course, this presumes that class member VIs that don't include class types as arguments can be used as interfaces to DLL's - I don't see why not, but I haven't tried. Yes, that works just fine. QUOTE (orko @ Apr 21 2009, 03:01 PM) Is it me or doesn't this seem like something that would be able to be done programmatically within the App builder? The whole "Build me a DLL from this class" concept. If you'll notice, the architectures required to do this vary wildly depending upon requirements and desires. There is not a cannonical solution to this problem. Indeed, the only thing that R&D can assert is what we already assert -- you can't build a DLL with a class directly in the interface. You have to be inventive...

QUOTE (Charles Chickering @ Apr 21 2009, 02:26 PM) The post I gave above is the instructions for creating an override VI from an existing dynamic dispatch VI. To make a new VI do dynamic dispatching, you just need the part of the instructions where you change the conpane terminals.

Are you having trouble setting the connector pane to be dynamic input and/or output? Start with VI reference... get the Conpane reference... use the method/property (I don't recall which) on conpane to set the desired terminal to Required/Recommended/Optional/Dynamic. If the input is set to Dynamic, boom, you've got yourself a dynamic dispatching VI. As for how to create the override VI, sorry, but that isn't exposed directly. The long route is to take the source VI, do Save As on it, then Select All on the block diagram, unselect the FPTerminals and delete the remainder. Then replace any Parent class inputs/outputs with Child class. The VIs to do all of this ship with LabVIEW but you'll find that they're private members of a library, so you can't invoke them directly.

You're not going to like these two solutions but I'll mention them anyway... Those are the best solutions I can offer. It's a hard to manage problem.

QUOTE (JFM @ Apr 20 2009, 02:05 PM) I concur. That's probably the problem.

QUOTE (normandinf @ Apr 14 2009, 05:47 PM) The long future, not the short future. Short = 2 years.

QUOTE (Paul_at_Lowell @ Apr 13 2009, 05:55 PM) It doesn't defeat the purpose. The XML form of an object is meant for preserving the object as the object. If you want to change it to a different object -- and that includes changing to a different object in a different language -- you would go through some sort of stabilized, exported interface, such as creating a non-object structure (aka cluster) and serializing the information. That's pretty much standard procedure for any sort of export/import operation. That leaves you free to still change the private details of your object -- add fields, remove fields, etc -- without changing your import/export format and thereby creating incompatibilities with the importing system.

The LabVIEW queues are circular buffers. You enqueue data at one end, dequeue from the other. All the mechanics of circular buffering are handled for you. You can bound the queue to a particular size or have it grow if it exceeds the current buffer size. See the online help for the Obtain Queue function to get started. This works for in-memory buffering. If you really need to go to disk, you'll need to do something like the examples you posted. Why isn't something "out of the box" supplied? Because generally the in-memory solution works, and when it doesn't, almost always some custom solution is required to manage the data because of the size and scale -- there's usually some custom requirement about how the buffering works, when is it acceptable to toss data and when is it required to hold, what kind of compression can be applied, etc.

QUOTE (JustinReina @ Apr 8 2009, 12:29 PM) Hypocrisy, guilt and tedium, and tools that NI provides for reducing all three of these. Specifically, we will be discussing practices that all of us software engineers should (generally) be doing on every project (to varying degrees depending upon business need and risk profile), including architecture planning, documentation and testing. We will discuss the lip service we all (myself included) are tempted to pay to these practices, the guilt that we can feel at knowing we're not doing them right and admitting to ourselves that a large part of why they're not done is that they are mind-numbing and tedious. And, so that we don't all leave feeling depressed, we're going to talk about a number of NI and third-party tools that can be used to decrease the pain involved so that these tasks (necessary and ultimately beneficial to ourselves, not just other programmers on our teams) can become part of our regular workflow and let us get back to the sexy part of our jobs -- connecting generally rectangular graphics together with pretty vertical and horizontal lines... man, that sounds so much cooler when Marketing says it... something about "designing algorithms that support business, science and engineering and change the world." Yeah, that's what I meant. ;-)

Jdunham and bsvingen: Is there a difference -- in your opinion -- between unrevealed features in the editor, unrevealed features in the runtime engine and unrevealed libraries of VIs? Because your arguments (and I'm still contemplating their validity) only have applicability to unrevealed features in the runtime engine itself, and there are damn few of those (I am not sure I can think of any to be honest, but I'll keep trying to think of them). In other words, that which you use, you use, and is documented, and your final application has no reliance on unrevealed things. Does that lessen your objections?

"I only want to see the important parts, but it keeps showing me every play-by-play. I thought this was supposed to be execution highlights."

Join the beta program. Or wait for the next release... ;-) QUOTE And yet, it is the option I and a whole lot of people use. C++ has burned too many of us too often with optional parameters, so I've always been reluctant to use optionals in LabVIEW (by which I include both Recommended and Optional since neither requires the terminal be wired). After a bad experience with someone changing the default value of an unrequired terminal a couple years ago, I decided I wanted this option. I polled a lot of other folks and found huge support for it. And when I needed a training feature for some new members of the R&D team, I used the opportunity. Note: it makes all new terminals required inputs except for the error code cluster.

Paul: I suspect you will -- believe it or not -- NOT want to use the Flatten to XML primitive for the LV Objects directly. Rather, I suspect you want to add a member VI to the class that outputs a custom XML format of the data within the class. Why? Because you're using it to move from one platform to another. The XML format of objects is designed to be mutation and version aware in LabVIEW. There are many shortcuts that the format takes that are not comprehensible without the .lvclass file. For example, if the output XML is just the class name followed by a version number of 0.0.0.0, that means unflatten this as the default value of the class. But without the .lvclass file, how can you know the default value at all? Any time you're going to be leaving LabVIEW, the standard format of XML for objects is not going to be useful. Instead, build a cluster of the data that you want in the XML and then flatten that cluster as XML. That will give you a format that is completely LV independent to read in your JAVA code. -- AQ

None of the XControls events will fire unless the FP is loaded into memory. If this is a subVI, it won't be normally -- but if you use any local variables in your diagram (for the XControl or for anything else), that will cause the FP to load into memory. Once the FP is in memory, then writing the value -- using the terminal or the Value property -- will fire the update functions of the XControl.

Austin apparently has a radio station KOOP. I can't believe LabVOOP has never been asked to present. I mean, what else could they possibly talk about with those call letters? Stroustrop and C++ are all the way down in College Station, TX!

The NI Developer Days 2009 conferences are going on in various places around the country. This is one of the few events each year where R&D folks from NI get a chance to meet customers other than NI Week. I will be traveling next week to the Portlant, OR, event on Tuesday and the Seattle, WA, event on Thursday. You can still sign up to attend the events if you are interested: http://www.ni.com/devday/ DevDays are targeted to customers who are know LabVIEW and are interested in stretching their skills a bit. Each one has a slightly different series of presentations depending upon the interests of customers in the area and the areas of expertise for the R&D staff attending the event. For Portland and Seattle, I've circled the presentations I'll be giving:

QUOTE (Yair @ Mar 24 2009, 12:55 PM) By high school, I was programming around 2 to 3 hours every day on my own, and let me tell you, if I'd had a copy of LV, it probably would've been dissected like just about every other piece of software that passed through my hands in those days. And I could point to a number of my friends who would've been right there with me. I find it totally plausible that flarn is 16, which is why as much as I'm willing to answer his questions, I'm also raising questions for him about the whys and wherefores of doing it -- there's a lot more illegal aspects to reverse engineering these days than there were 15 years ago.