Aristos Queue

QUOTE (jlokanis @ Aug 31 2008, 05:37 PM) Without someone actually inspecting the code, there's no further recommendations that I can make, but those are two independent subsystems, so I would be very doubtful of a bug caused by their interaction. I don't rule out the possibility of a bug in something, but not that. Can you post your code on ni.com for an AE to investigate? That's going to be the best way to get NI to push further on this. PS: Even if your app is thousands of VIs, if you're able to share it with the AEs, they'll try to replicate the bug. There's an assumption that customers have to get their architectures down small before a bug will get investigated. But if you're convinced there's a bug in LV and only a huge application replicates it, then, please, submit the whole app if you can.

QUOTE (JDave @ Aug 31 2008, 08:13 PM) I think you summed it up rather nicely. Except I wouldn't say "the access scope changes based on where it is called" so much as "multiple access scopes can affect the same VI depending on the caller." Think of libraries as containers of VIs. Some VIs are at the edge of the container, others are deep inside. The containers can contain smaller containers. So if a VI is on the edge of a deep container, it might still not be on the edge of the outer container. VIs inside the outer container can see the inner container and that VI, but VIs outside cannot.

QUOTE (Jim Kring @ Aug 30 2008, 05:07 PM) Double click on the class in the class hierarchy window. Same as you do for a VI in the VI Hierarchy window to open the VI. QUOTE While it might not make sense, theoretically, it does make sense in practice. No, it still doesn't make sense, even in practice. What it does is highlight other aspects of LV that need improvement. But let's fix what's broken, not create workarounds that don't do what you think they do. QUOTE And, those of us who echoed support for PJM's request spend a lot of time practicing LabVIEW. As do I... although to be fair to you, I don't practice all of LabVIEW. But programming in the particular corner called LabVOOP is a large chunk of my professional work these days. Maybe someday I'll be able to call myself a LabVIEW programmer , but I do think the title of LabVOOP programmer is one I have rights to already.

QUOTE (Jim Kring @ Aug 30 2008, 01:21 PM) And that's why I was suggesting that something on the subVI node itself was more useful -- you wouldn't have to open up the subVI at all in that case. And, as I mentioned above, if you did open the subVI, you might not see any private marking because of the sublibrary problem: A.lvlib owns B.lvlib owns C.vi. C.vi is public in B.lvlib and so wouldn't have a private flag. But B.lvlib is private in A.lvlib. So a caller D.vi that is not in A.lvlib would be broken. Having the indication on the subVI would be useful, but having it on the subVI when you opened it would not be.

Which context the VI is in makes a huge difference in how it will behave when it runs. Whether the VI is private or public makes *zero* difference to how it behaves when you run it. None. Zilch. Nada. You can change the scope from public to private, even to protected, and the behavior of the VI will be unchanged.

QUOTE (crelf @ Aug 30 2008, 08:54 AM) Ton is correct. The VI itself has no idea of its scope. The library is what defines and controls the scope of the items within that library, and you have to query the library item reference for that information. In fact, it goes further than that... just because a VI is public inside its owning library, that owning library could itself be private inside its owning library, and so any caller VI has to check with the entire ownership chain. Checking protected scope is even more complex -- the code in C++ stretches to a couple pages. Asking a VI "are you a private VI" is easy enough -- use the VI ref to get the lib item ref and then ask for scope, which will take care of checking virtual folder settings. But asking "can this VI call that VI" is a much more complex step and I don't know of any property/invoke API that will allow you to query for that information. This is another aspect of why the publicness/privateness of a VI is irrelevant when writing the VI itself... its callability varies depending upon the other VIs that you're talking to. PS: Since the library is what knows the scope of a VI, if a VI claims to be a member of a library and the lib is missing, we assume the VI is private.

QUOTE (jlokanis @ Aug 29 2008, 06:25 PM) That was the other thing I was going to say ... not only would you have to allocate millions of queues, you'd have to have them all continuously in play in order for the refnums to ever hit up against each other. Now if somewhere you're calling Obtain Queue and you're not calling Release Queue, you might be running your machine out of memory, and perhaps something strange is going on there (though I still can't imagine what would just cause the refnum to get deallocated).

We don't use a true GUID. We use a fixed count for the first several bits and a random value for the last few. In order to get any recycling of the unnamed queue IDs you would not only have to generate roughly 30 million queues, you would also need to get particularly (un)lucky on the other bits. That seems unlikely.

[Writing as G progammer, not as LV R&D developer] Strikes me as a strange request. Why do you care when you're writing the function what the scope of the function is? I can understand being interested in that when *calling* a function (ie, an annotation on the subVI call), but not when writing it. I don't know of any programming language that has that sort of notation in its code nor any language's IDE that provides that kind of visual feedback when writing the function. To me, the "I am Reentrant" glyph is a more useful request since a reminder that this VI is reentrant changes what I might write on this VI's block diagram (ie, don't use that control on the front panel as a storage location since it won't be the same control the next time you're called).

Create a single project that has the common VIs, and only the common VIs, in it. Those should be off in an isolated subdirectory. Whenever you edit those VIs and want to publish those changes for everyone else to use, use Build>>Source Distribution and export your VIs to the common directory that all other projects share.

QUOTE (Yair @ Aug 28 2008, 02:53 PM) No, you can't get the award. Why? Because you weren't actually using that 10000 frame sequence. The wire that was over 16K pixels long was part of an actual application.

I use it heavily during initial design. When code is finished, I turn it off, error cases either wired or consciously ignored.

Remember that the "Show Buffer Allocations" tool does just that -- it shows allocations. IT DOES NOT SHOW COPIES. So there's a buffer location allocated in case the front panel does get shown, but it is not necessarily used. So, no, there is no penalty for calling the subVI due to copying unless 1) the front panel is open when you make the call or 2) if there's a control reference open to one of the front panel controls or 3) the block diagram uses any local variables for that control or 4) the block diagram uses any static-linked property/invoke nodes for that control

They're looking to have some fun content for the class. I suggested that the class project should be to write your own slot machine and roulette wheel simulators so that on the last day of the cruise, NI can make even more money... er... I mean so everyone can have fun playing!!! :-)

Various NI products have various sections of the int32 range reserved. LabVIEW's reserved range is all positive, so positive numbers are what you'll get from all the built-in primitives. It overlaps with GPIB's range unfortunately because those two products predate when we started reserving independent ranges. Last time I looked, LV used error codes went from 1 through about 1500. But there's no inherent meaning in the fact that they're all positive. That's just the section that is reserved for LV use. Math is a separate DLL, developed by a subteam of LV, and they decided to reserve their own range so they didn't worry about accidentally using the same code when they're off in their own parallel development branch.

QUOTE (eaolson @ Aug 22 2008, 04:13 PM) Being younger is a major advantage in this regard... no one had the idea of layout managers when LV first started creating user interfaces. But your point that it is too hard to do GUI layout in LV is well known and a topic of frequent thought around R&D.

Error codes in an error code cluster may be positive or negative. There are old VIs still around that do not return an error code cluster, only an error code. Some but not all of these VIs have a convention that negative means warning, positive means error. Check the VI's documentation if you are dealing with one of those. For the record, the range of error codes reserved for users includes both positive numbers and negative numbers. Check the LV documentation for the exact ranges that are reserved (my memory is that they are not symetrical because part of the negative range had already been used by shipping products, but the documentation is more authoritative than my memory).

QUOTE (Darren @ Aug 22 2008, 10:59 AM) I've seen implementations where the tipstrip is a borderless VI (no menu bar, no title bar, no scrollbars, etc) that just displays a string control. That VI's front panel can be shown and hidden as needed and it can cross the boundaries of the front panel that it is over. Similar tactics have been done for custom popup menus prior to the facility being part of LabVIEW. This isn't as much of a hack as it might seem -- the tipstrip and popup menus in the OS are just separate windows with parts hidden.

For the record, Rick is an NI TestStand developer.

You cannot set tags in the runtime engine because you cannot change the VI (there's no ability to Save).

QUOTE (LV_FPGA_SE @ Aug 21 2008, 08:12 PM) Hm... what if you did blue=timed loop yellow=event structure black=while loop green=case structure wired with error cluster red = for loop with a breakpoint set on it

QUOTE (gmart @ Aug 21 2008, 06:15 PM) No offense taken. I was young, and the Stacked Sequence Structure looked so inviting.

The VIs inside an EXE cannot be recompiled as their diagrams are gone. So they cannot be loaded into any other version of LV other than the one they were last compiled for. They also cannot run without the version of the runtime engine that they were compiled for. They also cannot run on any other platform (Mac, Windows, Linux) than the one they were compiled for. Essentially, extracting VIs from an EXE is a useless exercise.

A defense of the flat sequence on this dialog VI has been presented: http://forums.lavag.org/index.php?s=&s...ost&p=50685 You may proceed to that forum to add your voice to the choir of arguments.

I wrote the three-button-dialog... and I don't mind talking about it... First I'm going to make a small technical correction to a previous comment, and then I'm going to make an Inflammatory Declaration. First the correction: QUOTE Actually, if you simply remove the sequence, you would get different behavior. You would need to wire a lot of error cluster wires that are currently missing and you would need to change the local variable that writes to "message" into a Value propoerty. So to be clear, it is currently adding functionality, but it is functionality that could be obtained otherwise. Ok... with that out of the way, let me move on to the real reason you're all still reading this post... Now, recall that I did say this is a VI I wrote eight years ago, one of the first VIs I ever implemented. I used the stacked sequence in the first version without questioning its use. I used a lot of sequence structures at first, and most of those have been removed as the years have gone by. I would now consider more carefully before deciding to use a flat sequence structure. And, so, with careful consideration, here is my inflammatory declaration: I believe that this dialog is an appropriate use of a flat sequence structure. And now, in this brief time while crelf, gmartinez and the other Guardians Of Diagrams (G.O.D.) are sharpening their machetes and prepping their missile salvos, let me present my defense... Part 1: Alternate implementations Three alternate implementations of this diagram have been proposed. SubVIs State Machine Just wiring all the error clusters Regarding SubVIs: QUOTE I think subVis would have been more appropriate. It is UI code on tightly linked property/method nodes. Creating subVIs would construct a nest of control references going into a subVI, definitely less readable than the code as it stands today. I don't think that would be more appropriate at all. Regarding State Machine: QUOTE (Michael_Aivaliotis @ Oct 24 2005, 05:25 PM) Hasn't NI learned about the state machine? I've actually given some thought to Michael's suggestion made back in 2005 about how this should be a state machine. I've come to the conclusion that if the sequence structure is bad then the state machine is worse. Why? Because in this case the state machine would be nothing more than a stacked sequence structure with more runtime overhead. If a flat sequence structure is considered better than a stacked sequence for readability, then turning the sequence into a case structure is a step backwards. And because the cases run in the same sequential order every time, then you've added the overhead of the while loop and the case selection without any benefit. Regarding Wiring All The Error Code Clusters: So from a "clean code" point of view, it seems that the only correct solution is to wire all the error cluster wires to enforce dataflow everywhere. We might then draw picturesque boxes around parts that are related for documentation purposes. I have no objections to this implementation. I think it would be fine for this diagram to have been implemented that way. Part II: Why The Flat Sequence Is Better Even If All The Error Terminals Were Wired So if I've conceded that wiring the error code clusters would be a fine implementation, isn't this discussion over? We found an acceptable alternative to the flat sequence. Case closed, right? No. Even if you wired all the error clusters, I think there would still be value to having the flat sequence around in this case. The minor reason not to use flat sequence structures is that they lead to code that runs off the side of the screen. However, as noted above, the only "good" implementation of this VI is one where all the error code clusters are wired and we still end up with a long string of code that runs off the side of the screen. So the minor negative is going to be encountered one way or another. The major reason not to use sequence structures is very clear -- it eliminates the ability of the compiler to take advantage of natural dataflow parallelism. It is a performance penalty. That isn't happening in this case. In every individual frame of the structure, there is stuff that is allowed to go on in parallel. But none of it can be made parallel because all of it is in the UI thread. Every property/method node on a control requires the UI thread. There cannot be any parallel advantage when doing UI programming. So the use of the flat sequence takes nothing away from the diagram. Indeed, if anything is wrong with this VI, it is that the VI itself is not marked as having the UI thread as its prefered execution system. It might run faster if we said, "just force the whole thing into the UI thread". LV's compiler might be making that choice for us anyway given the high number of property nodes. The value of the flat sequence is when you are editing this diagram. Suppose we drew rectangles around related sections of code for documentation purposes. Those rectangles would drift as you work and may not stay lined up around the nodes that they were first put around. The flat sequence delimits regions of the code in a way that it is part of the diagram. You really find value in the flat sequence when you need to remove a section of the code. When you're adding code to the diagram, you can use ctrl+drag to make space. But there's no remove space unless you use the new 8.6 diagram clean up tool, but that tool has its own rules for what clean means, and those rules may not be ones that you like. The diagram cleanup tool is meant for disasterous VIs that need *some* order brought to them, not for essentially orderly VIs that you're just trying to adjust. Now, if we were using a state machine with the attendent case structure, we would also have this advantage. But as I said above, the case machine hides code and adds overhead, both for no benefit. A previous post called the flat sequence on this diagram little more than graphic art. Yes. But it is *functional* graphic art to the artist. So, in summary, I claim that a) The only good alternative implementation has the same code-runs-off-the-right-side-of-screen issue that the flat sequence has b) the usual negatives of the flat sequence do not apply and c) the editing behavior of the flat sequence provides a positive. Thus it is correct and acceptable to use a flat sequence in this VI. The defense rests, Your Honor.