Aristos Queue

QUOTE(Jim Kring @ Apr 13 2007, 09:36 AM) Does using the Type Cast node help? If you pass in the exact same data type to both inputs of Type Cast, but the top input has the wire name that you want, you might get the desired behavior. It seems odd to suggest type casting to exactly the same data type, but given that the wire name is part of the data type, this strikes me as something I would try.

QUOTE(wwbrown @ Apr 11 2007, 10:54 AM) CAR 45E85U1Y was fixed in LV8.2.1.

QUOTE(BrokenArrow @ Apr 10 2007, 04:05 PM) But if you give us enough time, it'll be written in G. We've been pushing that direction for a long time now. The entire Project interface is G. The LEGO MINDSTORMS NXT uses a version of LV -- and the entire compiler for the LEGO brick is written in G. It can be done...

QUOTE(BrokenArrow @ Apr 9 2007, 07:26 PM) You don't recall it because those other languages aren't that friendly to graphics files. ;-) One of the neater parts of LV, IMHO, is to be able to make a block diagram constant of a picture. Read the .png file into a picture indicator. Now change that indicator to a constant. Easy as anything. ;-)

Perhaps LAVA and NI.com are to blame (credit)? If the information about LV is becoming more centralized, such that people know where to go to find help, then they're not using the search engine as often. They simply visit the site. I don't know for sure, but I don't think that NI.com doesn't use google for its internal search, so any searches going on there wouldn't show up in the trends. LAVA does use google for its internal search, but that's a recent change. Anyone who has heard of LV through other sources and decides to look it up might already be armed with "ni.com" -- it is one of the very few two letter domain names, and easy to remember. QUOTE(Tomi Maila @ Apr 8 2007, 10:43 AM) Again, I don't think I'd draw too many conclusions from the google numbers. LV sales are increasing steadily the last several years, not just raw numbers but also percent of market share, and number of industries with interest in LV. It is popping up all over universities, guaranteeing that the next generation of engineers/scientists are going to have trained on our tool. I don't know what creates the trend on google, but I can say with confidence that interest in LV is definitely growing, and growing very well. Here's an interesting set of graphs to compare. Search terms are LabVIEW, National Instruments, dataflow, NXT, Mindstorms And, whoa, NI is doing pretty good to have LV trending so well considering this graph. Terms "programming", C++, and JAVA are all trending down very heavily, much worse than LV. My final conclusion -- this tool is still *very* much in beta, and I'm not sure its data means much at the moment.

No, there doesn't have to be a way to do it. Well, not directly. If you want to script an event structure, I recommend creating a VI that has the event on it that you want and then using scripting to copy/paste that event structure into the VI that you're scripting. A lot of scripting can be done by creating a set of template VIs to use as either starting points or partial pieces that you'll copy into your final creation. Doing that is frequently faster than scripting each individual element. For example, if you're scritping a dialog, I wouldn't start from a blank VI and try to script it up from nothing. Start with the dialog template (See File>>New... for the design pattern templates that ship with LV... the dialog template is in among them) and then add to it. This doesn't solve all the use cases that you might have, but clever use of templates, copy/paste and replace can get you a long way. As an aside: I'd like to see a list of tags - are there a lot of them? What do they do? What are their prototypes? So many questions... I assume you're referring to the "tags" that can be placed onto a VI that save with the VI using the magic scripting functions. You'll never see such a list because there is no list of tags that can be put on a VI. A developer comes up with a name that he/she hopes doesn't collide with the name invented by any other programmer. There's no central registry, listing or whatever. Honestly, I've never really worried about it. It isn't like error codes where people like to use ranges and we want to avoid stepping on each other. There's a central registry for error codes (though prior to LV6.1 there wasn't, which is why the GPIB codes stack on top of LV codes for a small range, for example). But not for tags. Given the range of values for strings, if you pick something unique enough it is highly unlikely that anyone will accidentally stomp on it. Of course, the other reason for wanting such a list would be to know the complete range of functionality that has been hidden in the tags. But if we did that, where would we hide the easter eggs? So no list.

I sent Jim an e-mail that should brighten his day. I'll mention it here... Jim found a bug in a VI that ships with LV, filed a bug report and attached a fixed version of the VI. That VI was "reviewed and not found wanting." So it is going to replace the existing VI in the next version of LV. Jim will then be able to say that he has code that ships with LV. I expect this to turn into, "Use of the OpenG tools is pretty widespread. I'd bet every LV user out there has installed at least one of my VIs..." :laugh:

8.2.1 is not yet generally available.

> Thoughts and wisdom, oh wise ones? Wisdom? No. Thoughts? Yes. I rarely program for RT, and have never done more than superficial testing with it. All I can offer is theory. My thought is this: You're attempting to do something that is inherently not deterministic... the time needed to parse any given math expression is completely based on the particular math expression. It has no relation to the length of the expression or number of terms in the expression or anything else that you might count for determinism. Given that, you can't possibly be wanting to do this inside the RT loop. Given that, why not use the stack base approaches? Yes, you try to avoid such things on RT, but if you really need them, they are there (to varying extents on the different targets).

Just a warning: All of the advice I've read above is good. But you'll see a lot of VIs from NI that use rings and think "surely they should've used an enum for this!" The trouble is that enums change datatype when you change their text. That means recompiling the VIs. When we localize VIs (translate to foreign languages), we want to be able to export strings, translate, and import the strings right back into the VIs without changing functionality or needing to mass compile afterward. So we use a lot more rings than we might otherwise do. This bothers the heck out of me from time to time -- rings as block diagram constants or wired to case structures aren't nearly so useful as enums -- but various suggestions for how to improve the situation have been poor at best. Most users don't face this problem. When you write a VI, you can cleanly separate the front panel that your end user will see from the block diagram that you use internally, so you can easily follow the general rule of "use a ring on the FP, then use a single VI to translate ring values to enum values and work with the enum on the block diagram" that a lot of G developers use. But for NI, our customers are the programmers, and we have to allow for localization even of our diagrams. So we end up with rings where anyone else would use an enum.

Go to VI Properties>>Execution. Change "Preferred Execution System" to be "user interface." Now benchmark it.

Three breakpoints on this diagram: http://forums.lavag.org/index.php?act=attach&type=post&id=5389 The outermost will break when the VI is called as a subVI. The outside of the loop will break when the loop is first hit. The inside of the loop will break on each iteration of the loop.

QUOTE(Jim Kring @ Apr 1 2007, 10:18 PM) Jim is right to say it isn't a bug in the strictest sense -- in general, when we copy a control we don't copy all the property/invoke nodes for that control. But in the case of the SubPanel, you bring up a good point... since we don't have an FPTerminal, and sense the property node is how the Subpanel gets set, we should probably include code for creating the property node as part of pasting or otherwise duplicating the subpanel. I suggest you file it as a bug report to NI.

QUOTE(njkirchner @ Mar 30 2007, 04:13 PM) No process in mind yet. I think at some point we'll have a template class or a wizard that scripts stuff based on the class you give it, but for now, I'm just trying to identify patterns that I see -- things people keep trying to do, and picking out the best implementation I can find for doing that thing. These are starting points for your architecture, meant to help with "blank diagram syndrome" -- only in this case it is "blank project tree syndrome". "I need to build XYZ, ah, ok, this looks like it does what I need to get done, let me build something like that..." I think the way to use it today is this: if you write something that is sufficiently similar to the pattern as described, then do something in the iconography or naming to indicate that this is an instance of that pattern. That way people can more easily figure out why certain bits are written in a particular way ("why did he create this shell library?" for example for the singleton pattern). And if you find a better implementation, let me know and we'll update the document as necessary (or update LV, if that's what's necessary :ninja: ).

QUOTE(LV Punk @ Mar 30 2007, 06:50 AM) It could be a problem, but it's absolutely amazing how often it works just fine. CPUs are fast enough compared with various bus speeds that the dequeue loops for most apps I've seen -- particularly for data aquisition stuff -- are way faster than the enqueue loops, so the queues stay small.

QUOTE(Thang Nguyen @ Mar 30 2007, 04:36 PM) You can also use the "Not a refnum?" primitive (found in the Comparison palette with all the Equals, Less than, etc primitives) to detect whether a Queue refnum is still valid or not. It returns boolean true/false so it might be simpler for you.

QUOTE(yen @ Apr 1 2007, 12:26 PM) Another alternative for posting to NI: Post to the forums with your image attached. Then click on your uploaded image, copy the URL, and go back and edit your message to include this: <img src="URL"> where URL is the url that you copied. That way your image is uploaded as part of the post and you can edit it easily if you need to and you don't have to worry about another website being up/down when someone tries to view your message.

DOH! We're all silly... to create a block diagram constant for clerf, we should use clerf's techniques... So easy, anyone with a formula node can do it: http://forums.lavag.org/index.php?act=attach&type=post&id=5364

QUOTE(tcplomp @ Mar 29 2007, 04:11 PM) Heh. We asked them to beta test our new mind-machine interface for programming LV. We neglected to tell them that the interface went both ways... :ninja:

QUOTE(Tomi Maila @ Mar 29 2007, 04:43 AM) Except we want the subpanel size to drive the dialog window size, not the other way around. Even if the window were made resizeable and this were passed through to the subpanel -- adding a *lot* of work for the subpanel developer -- we'd still want the subpanel to define the minimum bounds. The window resize commands don't seem to work once the VI is hosted in the subpanel (I assume that's because there isn't actually a window to resize).

Well, my little question -- and this groups' response -- has churned up some concern within R&D. I'm passing the feedback back. As far as code inspection goes, there should be no performance difference between the two loops. Regarding the free-range feedback node, opinions are divided about whether there should be any difference there or not ...

With a VI this small, performance probably isn't a concern. But if you do anything 20 billion times, it does tend to add up. ;-) With that in mind, I offer a modification to your VI. Correct me if I'm wrong, but this should be the same functionality in less time. http://forums.lavag.org/index.php?act=attach&type=post&id=5341

QUOTE(prayami @ Mar 28 2007, 02:08 PM) Check the Examples that ship with LV ( Help >> Find Examples... in the menus). Search for keyword "uninitialized". The only VI that is returned in the find results should be educational.

QUOTE(Tomi Maila @ Mar 29 2007, 03:28 AM) Do you have the VIs that you used for the benchmarking? These would be useful to investigate.

Almost every time I see a someone write an LV2-style global (you know, an uninitialized shift register on a loop that is guaranteed to run exactly once, used to store data for retrieval on a later call), it is written with a While Loop, with a constant wired to the Stop terminal. I've always written mine with a For Loop with a constant 1 wired to the N terminal. It seemed more intuitive, and for some reason I felt LV might optimize it better, since normally the contents of a While Loop cannot be optimized based on number of times it'll execute, but a For Loop always can. So I asked Jeff K (father of LV, deep knowledge of diagram optimization). He says that we can indeed constant-fold a While Loop with a constant wired to the Stop terminal. It's the only time we can constant fold the contents of a while loop, but we can do it. He says that there's no advantage to using one over the other. It answered a nagging question in my mind. I thought others might be interested as well.