Aristos Queue

Read it again. It is a list of synonyms. Each item in the list is a pair.

I have recently been looking at code that suffers from a lack of synonyms. Everything in the system has a system-to-component-to-element relationship. There are so many systems and components and elements running around, it is hard to figure out what's up. I've seen this many times in my career. You'll see this in LabVIEW if you look at the collision of naming conventions that happened with libraries and classes -- parent and child are used both for the inheritance relationship of the class and for the virtual folder membership of the project tree. Ug. It is one of our primary jobs as the authors of software to name things well. "Well" means distinctly, precisely, accurately, simply and unambiguously. Non-English speakers may have an excuse -- I do not know how plentiful synonyms are in the world's human languages. In English, we are blessed with a cornucopia of phrases, a symphony of words tuned to exactly the note we are seeking. In an effort to combat this in your code, I am offering up this list of synonyms. The next time you are creating an API with a relationship, please consider using the full richness of our language. Feel free to add more as they occur to you. For bonus points, post glyphs to go along with the pairs that can be used in VI icons. Several of these are already part of the NI glyph library in the Icon Editor. whole part wrapper core system component speaker listener master slave outer inner primary secondary facade structure server client framework plug-in source sink parent child manager delegate caller callee refer refee source destination source target original copy controller puppet interface implementation object aspect container content amalgam element genotype phenotype base derived director actor exterior interior recipe ingredient body organ super sub group member real proxy package piece aggregate fragment general specific construct foundation product factor view model shell kernel mask identity carapace meat leader follower application add-on face heart sum segment edge locus commander toady senior junior owner operator

My husband, James Loftus, will be there with an FTC team from Austin. Look for the LASA team -- they're the ones wearing "as funky as you can get purple" elements of clothing. Their school color is purple and the mascot is the panthers. James is also on the LabVIEW team, so if you say hello, he'll know generally of what you speak LV-wise.

I would just get the project property of the new VI. That would also allow you to know which target within the project.

PPLs are not a part of the LabVIEW language. They're just packaging for functionality, no different in many ways to a .zip file. The PPL is not a presentation layer or any other formal aspect. It's just a tool for getting VIs to load faster.When you ask for changes to scope, that addresses language features, which means changes to the run time behaviors that would impact dev environment and run time environment alike, regardless of packaging. A good write up of why composition is preferred to private inheritance:http://www.parashift.com/c++-faq-lite/private-inheritance.html

Doh! Good call, mike_nrao. I completely forgot about Ram's trick.

Google "delegate pattern site:ni.com".

Why isn't protected scope sufficient hiding? That would be unusual among the world's OO languages. I'm not saying it's a bad idea, but when none of the major OO languages that I know of do it, I always have to ask why. Scope is not one of those areas that is impacted by dataflow.

What you're seeing is the same behavior that all LV controls have. It is why some controls have "Synchronous Display" as an option. The synch display option forces LV to wait until the UI is updated for every write to the indicator. Normal operation will update the UI on a much slower schedule -- so you see big jumps when writing to a Numeric control inside a loop, for example. If you update your XControl using the Value property instead of using the FPTerminal, I'm 90% certain that you'll get the synchronous display behavior.

To control what is visible, set the access scope. The dynamic dispatch VIs can be set to protected, which is the only other meaningful scope for dyn disp -- it doesn't make sense to have a dynamic dispatch method that cannot be overridden by children. There is a valid use case for creating a wrapper class that has a reduced set of methods that wraps an inner class. This is done a lot in various programming languages to create a read-only version of the class, so the wrapper class only has methods for reading values, not writing them. You would then hide the core class inside the packed project library (making it private to the library) and expose your wrapper class only.

Congratulations, Vivante.

Reinstallation isn't going to help unless you've been modifying the VIs that are part of your installation. No, this is far more likely to be something you need to deal with in your code and/or app build setup. Try adding instructions to always include the panel. If that works, you can either keep that solution or look at your VI and figure out why the panel is required. You might post the block diagram here... someone here might spot the key node.

Have you turned on Automatic Error Handling both in Tools >> Options and on all VIs in your project? You can quickly write a "get all VIs in memory, turn on automatic error handling" VI to do that rather than doing it by hand. That will make an error go off if there is some place where the errors are being dropped. If you have access to the Desktop Trace Toolkit, that will add an entry to the log file every time an error is generated at the point of original error generation, assuming you have debugging enabled on the VIs.

Use of the UI thread is not enough to trigger the loading of the panel.

1) In pipelining, particularly common in FPGA, they're critical. Of course, those are configured for feedforward, not feedback. 2) I'm told (and anecdotally find to be true) that electrical engineers are used to reading the feedback notation in other schematics. They read them much easier than the shift registers.

Ah, but XControls don't have the potential to corrupt your VI if you do them wrong. There's a big difference between "complex" -- which is a reason to put a good UI on something but not a reason to never release it -- and "flakey around the edges" -- which is a reason to keep it in house.

Yes, those events will always come in the predictable order, as asbo postulated. asbo: Never forget that "for" can be abused as "while" in a lot of C-like languages. Read it as "for(;imstuck;)" where imstuck is true. Semicolons would be needed in C++, but there are other similar languages where you wouldn't need them.

iEmilie: I haven't really been worried about the "hate LV" blog post. I kind of enjoy reading it. In my eyes, LabVIEW seems to come out pretty well in that thread. I figure there's always going to be someone angry at us, so the existence of the thread itself doesn't bother me. What I like is that in all of the pro-LV comments, whether from NI or not, people reply with calmness, reasonableness and helpful advice. I've read that thread a few times over the years and thought perhaps we should start an advertising campaign: "LabVIEW: Using it will make you a nicer person." :-) Various folks have said that reading that post was deflating. It shouldn't be. My list of "things I hate about LabVIEW" would be waaaaay more than just 10 things, and I guarantee some of them are far blacker marks against us than anything jshoer mentions. I cannot believe how incredibly stupid we have been over the years on some features (yes, I include features I created and now regret), and how long it is taking us to get certain upgrades. But I don't view these deficiencies as reasons to be depressed. LabVIEW is a growing language, adapting over 25 years to the changing technologies and customer bases. Doing what no one has ever done before sometimes means you get a less than optimal solution and you have to fix it up in round 2. Do we have more we can do? Yes. And we continue to work to improve. But the backbone of LabVIEW remains strong. Graphics is the only manageable way to express parallelism, and parallelism is the name of the game in the future. Have you guys seen the parallel keywords that Microsoft has been introducing into the other languages lately? Everything needs to be parallel, but procedural programming is a dead end. There is only so far you can go with compiler analysis of procedural code and manual control of mutexes before you hit a wall and flat out say, "No, I need a system that is designed for multicore from the outset." Between our parallel expression on the desktop and our ability to target FPGAs, I'm thrilled about LV's future, and all the complaining is just the list of tasks we need to be tackling on our way there. When I started at NI, on my first day, I saw a sign by Jeff K's desk: "You know you have built a successful product when people use it for things you never intended and criticize you for being short sighted." The "hate LV" post is just one of the sign posts of our success.

VIs that are built into an executable have their front panels deleted by default unless they are the top level VI, a dialog VI, or have a linked control reference on the block diagram. The Median.vi does not meet those requirements, so its block diagram is stripped out of the EXE to make a smaller EXE. You're doing something in your application to try to open the front panel of this VI -- perhaps getting a control reference or using the Set Control Value method? Whatever it is, you need to modify your AppBuilder spec to tell that VI to keep its front panel.

If you like the Enable terminal, there's a feature coming in LV 2012 to solve the tunnel output consistency problem. Take a look at the Upgrade Notes when you get your upgrade later this year.

Hey... at least you guys have gotten me to the point of admitting that XNodes even exist. Time was I would have accused you of hallucinations and swamp gas reflecting the light of Venus for believing in XNodes. lordexod: The XNode tech is reserved to National Instruments for a long list of reasons, not the least of which is that it requires some significant contortions to avoid the traps and pitfalls of working with them. XNodes invoke G code to do their work. There are various operations that are not stable to do while LV is doing certain operations (loading a VI is not always safe, for example, depending on what else LV is doing at the time). As a matter of fact, XNodes have been mostly abandoned by NI for further development ourselves because of their issues. They work great for some things, but poorly (or crashily) for others, and it is very hard to tell in advance whether a given use case will turn out to be the former or the latter. We'd like to have a more complete "G written in G" solution, one that we could release to customers, but XNodes aren't it.

Yes. I do. No, I won't share.

You say that this subVI acquires data from an instrument. Do the other functions also acquire data from an instrument? Is it possible that this subVI is somehow badly written in that it is locking the instrument so that the others cannot access the data? Is it possibly closing the instrument reference that the others are using? I would check all of the "error out" terminals for all your VIs and see if any of them are returning an error that would be useful... your exported functions probably aren't returning the error to the caller, but on their block diagrams, add a Simple Error Handler.vi that collects all the errors generated on that diagram and see if any of them report when you build the DLL. You know that removing this subVI makes the rest of the exported functions work correctly. That's an odd workaround to have discovered, which implies to me that something happened that made you test this theory. What did you observe that made you suspect this subVI might be contributing to the problem? Knowing that observation might help the rest of us suggest how this subVI is interacting with the rest of your application.