Leaderboard

I want to let LAVA know about a feature of LV 2016 that may not get much press. The In-Place Element structure has a new pair of border nodes to let you access the attributes of a variant without copying them out of the variant. This will VASTLY improve the performance of tools that use variant attributes as lookup tables. I strongly encourage everyone who works on this to look at the shipping example: labview\examples\Performance\Variant Attribute Lookup Table\

LAVA has won an NI award for LUGnuts at NI Week, the largest independent online user group. Thank you everyone for making the online community something to be proud of.

It's actually very straight forward. The main VI pokes the servers to do things and the listeners react to the responses from the servers. Each server and listener is an API with a pre-defined set of actions and commands. They all follow the same template.Keep adding APIs (services and listeners).and keep poking them to do things Each subsytem is standalone (modular) so you can take one; analyse it then run it and test it in isolation meaning you can break down even really complex systems in easily digestible chunks.. Don;t forget to run the TCPIP client first so you can see the Telemetry that hooks all the messages

The "CLI or Die" posse are definitely in the driving seat at NI and perhaps that's why QD is so popular. If you add superduperCLIorDIEquickdrop=true to the LabVIEW ini file in 2016 you can do this Expect this in LabVIEW 2017, now

You don't understand: This IS the compact view (though the icons looked way smaller on a 4K monitor)... how very strange... Seriously though for long-term user like us it doesn't look very appealing, but it might help attract new customer/user in the future. Nowadays everything is about how it looks, so NI would be stupid not to develop in that direction. Also there is one bright side: Now everyone got a reason to make use of QD. Not sure if this is what you meant, but it looks like a bug(feature). Do this: Create a new VI, place a structure (while loop), insert one or two functions IN the structure (no need to connect them), select both (all) and begin dragging so they come close to an edge of the structure, while still holding the left mouse button (dragging) press and hold space (sometimes you'll have to keep moving the mouse and let go of space) This is how you grow your diagrams now

This is the downside of the event system. I still like it, you just have to learn the fiddly bits to make it display nicely. I may be slightly off with these but: -User event registrations, in the event structure, show the label of the event refnum as passed into the register for events node. Therefore, your cluster label is "New Temp..." and your event case is the same. -Control registrations use the same principle, but with arrays of control refnums it totally goes bonkers. I've used a for loop and To More Generic with a VI server constant (this is automatically performed for you when you use a Build Array with different refnums, so throwing this in there is basically a no-op). In this case, the event case shows the label of the VI server constant used with the to more generic class function. -The inner data node where it says "New Temperature Limit" is based on the label of the element inside the user event refnum as passed into the register for events. That is, your wire "New Temperature Hysteresis" contains a numeric called "New Temperature Limit", presumably because you copy-pasted. You can fix this in one of three ways: Right click on the user event refnum in your cluster and select show control. Then you can relabel the existing data. Open your cluster type def (because you absolutely typedef'd it) and drop down a new control of the type you want, in this case a numeric. Relabel this new control to "Blah". Drag and drop "blah" into your user event refnum and it will replace the prior contents, meaning you've just relabeled "New..." to "Blah". Go back to where you created the event, right click on the constant you used to create the event, change the label to "Blah". Then create a new constant/control off the create user event node. This new control should have the correct label. I haven't personally used this, but the discussion is pertinent: Since I'm already here, its worth mentioning that if you rearrange the order of event registration or the label of the user event (not the contained data), you **must** verify the order of your event cases. The same is true if you bundle up multiple registrations. Changing the order or name of the event registration requires a quick code review. This is the one killer negative feature of the user event system. I still like user events despite these flaws, and I think as long as you know about them you're fine, but... By the way, one neat thing I don't know a good use for is that you can unregister for selected events on a temporary basis: http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/dynamic_modifying_reg/ One thing I wanted to use it for would be as part of a state machine, you can literally stop listening for some events when you're in a state where they don't matter. But I decided it was easier and more readable to just put a case structure in the right places. I don't have labview here so I'll try again. Its worth mentioning to be clear that this is just how I personally organize the code. I've never really swapped notes with anyone on this. Imagine you have two loops. One reads the data from the sensor (I'm assuming this is what the loop you showed above will become -- lets call it "HW") and one that interacts with the user (lets call it "UI). "HW" generates a temperature reading event and an alarm event. "UI" generates a new limit and stop event. "HW" consumes the new limit and stop events. "UI" consumes the temp reading and alarm events. So my init sequence would be: "HW" creates the temp reading event and alarm event and stores this in a cluster called "HW.Pub" At the same time, "UI" creates the new limit and stop event, storing these in a cluster called "UI.Pub" On the higher level diagram, you feed "HW.Pub" to a function called "UI.Subscribe". This function pulls the events it cares about out of "HW.Pub" and bundles everything up into a cluster called "UI.Sub" At the same time, on the higher level diagram, you feed "UI.Pub" to a function called "HW.Subscribe". This function pulls the events it cares about out of "UI.Pub" and bundles everything up into a cluster called "HW.Sub". You pass "HW.Pub" and "HW.Sub" to a function ("HW.Main"), and you pass "UI.Pub" and "UI.Sub" to a function ("UI.Main"). I like this because it makes it clear just by looking at the code exactly what each loop is subscribing to and publishing. This doesn't scale for more dynamic situations.

This article does a good job at narrating the author's journey from being an OOP enthusiast to an FP advocate, and helps us understand his feelings and frustrations. However, it does a poor job at illustrating OOP's actual shortcomings/pitfalls. Let's have a closer look at the author's arguments. Inheritance: The Banana Monkey Jungle Problem This is a strange example. It's like an OpenG author who decides to reuse some OpenG code (say, Cluster to Array of VData__ogtk.vi) by copying the VI into his project folder, and then is gobsmacked to discover that he needs to copy its subVIs and their subVIs too. This shouldn't be so surprising, should it…? Anyway, it sounds like his main gripe here is with excessive dependencies (which is influenced by code design too, not just the paradigm), yet his stated solution to this problem is "Contain and Delegate" (a.k.a. composition). Sure, that eliminates the class inheritance hierarchy, but I don't see how that helps reduce dependencies. It feels like he's trying to shoehorn the "You need composition!" message into every problem he listed, just so that he can argue later that inheritance is flawed. Inheritance: The Diamond Problem Yes, this is a real issue that can trip up the unwary. However, the author claims that the only viable way to model a diamond relationship is to do away with inheritance ("You need composition!"). He disingenuously ignores the numerous inheritance-friendly solutions that can be found in various languages. Inheritance: The Fragile Base Class Problem Yes, this is a real pitfall. This is his most solid point against inheritance. Inheritance: The Hierarchy Problem His main point here is, and I quote, "If you look at the real world, you’ll see Containment (or Exclusive Ownership) Hierarchies everywhere. What you won’t find is Categorical Hierarchies…. [which have] no real-world analogy". I'd like to hear from someone who has implemented a HAL (or someone who's a taxonomist). Would you agree or disagree with the author's claim? Encapsulation: The Reference Problem This is another bizarre example. His logic is akin to, "An LVClass lets you have a DVR as a data member, and it lets you initialize this member by passing an externally-created DVR into its initialization VI. Therefore, an external party can modify LVClass members without using an LVClass method. Therefore, LVClasses don't support encapsulation. Furthermore, attempting to prevent external modification is inefficient (and perhaps impossible). Therefore, the whole concept of encapsulation in OOP is unviable." This is a huge stretch, IMHO. Polymorphism His main point here is, "You don't need OOP to use polymorphism". This is true, but is not a shortcoming. Also, the author paints a picture of interfaces-vs-inheritance. They are not mutually exclusive; they can be complementary as they serve different use cases.