Aristos Queue

You people are so laid back and forgiving. I’m an editor on multiple wikis across cyberspace, and none of the others are anything less than draconian. Capitalization whatever?! Wow. I’m going to need to wear my oversized Hawaiian shirt and cargo shorts when I’m editing, just to get in the right state of mind! 🙂

If you want to run the VI in the IDE as a tool of some sort, save it into the "<LabVIEW>\project" subdirectory. Every VI in that directory gets automatically picked up and added to the Tools menu. The menu item gets its text from the display name of the VI, saved in VI Properties. When the menu item is chosen, your VI is run in an isolated application instance so it never interferes with running applications. App instance isolation is how all the G parts of the IDE execute, like the icon editor, the getting started window, or the right-click menus.

I noted a few uses of lowercase "boolean". Capitalizing that B is often confusing because it is the only non-class type that is typically capitalized. Text languages have solved this by using keyword "bool", and therefore that is the actual type name. LabVIEW doesn't typically type out data types. NI style guide says to capitalize Boolean. Does LV wiki agree? When I'm editing the wiki, I will generally follow NI documentation style guidelines (so "subVI" instead of "SubVI", for example). Are there any particular conventions that the community has established that differ from NI standard practices? When discussing language features (as opposed to editor features), LabVIEW 20xx uses "LabVIEW"... LabVIEW NXG has moved to using "G" and uses "LabVIEW" to discuss the IDE. We find that this provides clarity in many documents, and it provides less of a mouthful when speaking (The NXG root class is "G Object" instead of "LabVIEW Object", for example). Does the wiki prefer "LabVIEW" or "G" when discussing language features? When behaviors diverge, what is the preferred way to document distinctions between LabVIEW 20xx and LabVIEW NXG? Should they be separate pages (so the former can be easily deprecated in the future) or do we prefer same-page-different-sections for easier side-by-side comparison?

I tried to update this existing image with a new version of the PNG: https://labviewwiki.org/wiki/File:Screen_Shot_2019-06-27_at_1.50.14_AM.png#file I keep getting an error: [XSir2GJrsGEvUGpzBj7-DAAAAAQ] 2019-07-12 15:48:40: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" Anyone know what's wrong?

Are those 10 charts in the first image all screen shots from LabVIEW? If so, very nice! Professional work!

Ethan: can you confirm fixed in 2019?

MartinD: no, nothing wrong with that, but I usually only use that approach when the value is a computed value that needs different data storage. For example, “determinant” of a matrix... sparse matrix and dense matrix have different data storage, and determinant is computed differently for each type. But it works fine in your case, too. It’s nice if some classes have it as a variable (gets stored per object), but other classes it is constant for all objects of the class, so the method can just return a constant and not burden every object with that bit of data.

Honestly, I have no idea if that’s something that is even logically possible. Computing data flow from procedural instructions is one of the holy grails of compiler optimization. Sure, there’s short segments that are easy to translate back, but a general app? Maybe, but I have 19 years of LabVIEW R&D experience with the compiler, and I’d be hard pressed to do it by hand, much less derive a general algorithm for automatic decompilation.

I pro-indicate them (opposite of contraindicate?) because despite some issues over the years, they have some abilities that nothing else in LV replicates, and I've learned where the rough edges are. There are some really sophisticated tools that can be built from these controls (even the Q Controls can't help out while editing). I've built multiple XControls that work just fine in built apps and large projects. YMMV.

Someday, I really would like to take two months off of my main dev job to sit down with the developers of some app that uses all this ref stuff and really tear it apart. I've gone through smaller apps and been able to eliminate most of the references, achieving much better performance -- often with a significant decrease in memory and usually fixing a couple of race conditions along the way! But that's only for small apps, which leaves my theory that the big apps would be better off without the ref aspects as just that: a theory. I don't just need my time... I'd also need the time of the large app's developer(s) to provide the handholding to do the analysis. The work I did with Allen Smith on the AF was this weird moment of downtime for me at NI between two major projects, something that doesn't come around often. Until that next magical gap in my schedule, I'm just going to look at diagrams like the ones above and wince, whispering quietly, "We gotta find a better way..."

PS: ShaunR's new XControl is pretty nifty.

The rusty nails are never-released features that aren't supported. XControls very much are supported and are useful, just not as useful as we all wish they were. Big difference.

@AbdulQuader As Rolf says: Yes. You can trivially build one just by building placeholder subVIs that either do nothing or return dummy data when called, and then fill in those subVIs with real hardware calls later. But more sophisticated simulations are very application specific. Unfortunately, there isn't (and cannot be) a general "HW simulator API". This guide to building a hardware abstraction layer may help you design one for yourself. Or it may not help -- the PDF is one that I've handed around to many users, and it's about 50/50 chance of people either happy it is so helpful or frustrated that it is so unclear. But maybe give it a chance. Good luck.

@CheesyGC what is an example of "dynamically building a project" question? I can think of a few interpretations... dynamically loading modules/plugins or dynamically building the build specs. Both of those are pretty common (the latter is sufficiently common that NI just rolled out new CLI tools to support doing it).

I think the XControl questions should stay. Any CLA should be able to recognize/use/edit an XControl because it is a part of the language, and not an obscure part (like, for example, "Enable Database" on a subVI). They do have real uses. For me, they're the best way to put a UI element together to display a LV class. We are still years away from a general user-base migration to NXG -- I think it is too soon to be making those arguments (as a counterargument, I think CLAs should know what scripting is, even though most scripting functions are not going to migrate to NXG). (The exact number of questions is open to discussion... I'm only opposing a blanket elimination.)