Leaderboard

I'd seen it before, but the file name was a giveaway

I don't get it, why do you call LabVIEW add-on VIs dynamically These VIs should/could be directly called on the Block Diagram; giving you higher performance, and less complicated code. For me, the main reasons to call VIs dynamically is either 1. to spawn parallel processes 2. to dynamically load plug-ins 3. to break the hard link to a specific set of VIs at edit time /J

Yup. I think originally they were using it to invert (instead of using the primitive) and during debugging/mods changed the booleans around so it was completely redundant.

From Copyright is very sticky!

Yup. The trick is to mount the camera above the door looking down. Then you don't suffer from occlusion,have fairly regular shapes and a constant, uniform background to contrast against. Once you get used to it, you can even start counting prams, pushchairs, wheelchairs, adults/children etc.

The vision package should be able to do that. I think you’re looking at a fairly standard particle counting algorithm, which in theory is pretty easy. But like everything, the devil is in the details. The key to any vision system is in consistent lighting conditions. That might be harder to achieve in a building environment. What specifically is your application? Are you looking at huge crowds of people, or just an occasional individual? Is this an office building, sports stadium, or single room? Is the camera already in place, or can you position it and control the lighting? All of these answers will have an impact on your solution. The easiest thing might be to get a cheap USB camera, download the evaluation version of the Vision Toolkit, and play.

I have just been reading up on topics of OOP in general and although I've used things similar to Interfaces and Abstract classes in LabVIEW, I didn't realize I was doing it. Due to differences between different text based OOP languages and LVOOP I was just wondering if I could get some of you to speak to these two concepts, whether they both really pertain to LVOOP, and possibly provide some actual examples (not just vehicle, shape, cookie cutter examples, but something I'd actually use) of when you'd define an interface vs an abstract class? I'm basically just looking for general information to help strengthen my understanding of these concepts, and most, if not all, examples out there are text based. While I can figure them out, it's much more time consuming, still leaves me with some grey area, and my brain tends to understand LabVIEW much better in the first place.

I know the "Delegation Pattern" has been mentioned in some early versions of OO pattern documentation on NI's website. In my opinion it is more of a strategy or technique than a pattern. Delegation just means having some other class or component do the work. Patterns give class structures (sometimes with minor variations) to solve fairly specific problems. Delegation is far too broad a topic to be contained in a pattern. The Best Practices link illustrates the problem. Compare the "Single Inheritance with Delegation" diagram with the "Cat" diagram in the structure section. The class structures are substantially different and there is no explanation as to why they are different. The Cat diagram is an example of dependency injection. (I do this all the time and it is hugely beneficial for unit testing.) I'm not quite sure what to make of the "Single Inheritance..." example. It doesn't work as a general replacement to multiple inheritance like the text implies, though it might be adequate for specific situations. Yes, both examples use delegation to achieve their results, but neither adequately defines delegation. This is really the comment that prompted me to respond before I got sidetracked on the response above. Delegating to a composed class is probably the most common way it is used, but I don't think it is necessarily a "key idea" of delegation. There are lots of ways to ask another class to perform a task without using a direct method call.