infinitenothing

Inspired by these two threads: http://lavag.org/topic/18657-notifiers-not-working-when-use-consecutive-create-notifier-vis-without-delay/ http://lavag.org/topic/4028-notifier-signals-missed/ I was wondering if I could create my own notifier that could switch between references without the history management. Here's what I came up with. I'm not expecting this to be very fast. I thought it was an interesting use case for occurrences. Test Case: Obtain Notifier Wait on notification I probably need a mechanism to check and retry if the "Latest Message Is Valid" flag is false after the "Wait on occurrence". Send Notification

I didn't realize there was a potential for a memory leak there. That's unfortunate side effect. On the upside, if you use the history one, you can reenable dynamic dispatch because you don't have to share clones in yourWait For Notification.

In my opinion the advanced behavior is the more intuitive way. It's not intuitive (as you saw with the original post) that the order of the senders should matter. We normally don't think about the receivers having an internal memory (we expect the primitives to be stateless except for the ones that enable statefullness). The other primitive (no history) maybe should be on the advanced pallet because it's for the power users that go faster.

I looked through that thread and I wonder if there's a better implementation of the notifier behavior like using subscribers or something drjdpowell: Here's how this affects messages. I defeated the reentrancy by wrapping your "wait for notification" in a nonreentrant subVI. If "data 1" executes first, all messages are delivered nicely. If data 2 fires first (as shown in the image below), you get a timeout (or a deadlock if the timeout is -1) You can make it so both messages are delivered by using the "Wait on notification with history" primitive in your "wait on notification" VI instead of the normal "wait on notification" primitive.

TestStand? You can use TS semaphores to arbitrate the equipment. And regarding super clusters, a complicated system can have big clusters (lots of variables). Clusters are nice because they prove some scalability. You just want to make sure your clusters have high cohesion. Also, you want them to have well organized sub clusters. In a sense, you can treat them the same way you treat subVIs. Your top level VI or cluster shouldn't have all the code on its block diagram, it should be broken down into logical chunks.

What's your code (as shown above) outputting now (what's in the array indicator). What ends up in your text file. What do you want in there?

Are you using this function? http://zone.ni.com/reference/en-XX/help/370281W-01/imaqvision/imaq_find_circles/ If so, you can wire the Circles Data array into a for loop and unbundle the x,y, and radius. You can wire each of those out of the array which will autoindex each measurement into individual arrays. You can then wire each measurement array into Mean.vi which will give you the mean x, y, and radius. Also, for future questions, there's a machine vision board here: http://lavag.org/forum/10-machine-vision-and-imaging/ or here http://forums.ni.com/t5/Machine-Vision/bd-p/200

Fortunately, if you can't get them to work as intended, they gracefully fall back to "draw something that looks like this picture" mode

I'll take a stab at it Here's the subVI

This seems pretty close to the original diagram.

Could the compiler fix some of the easier race conditions? It could see that I'm doing something really simple with a global and block other callers for the 10 microseconds I'll need it. Oh, look, you have a property node floating off in the distance, let me do that before I start the event structure.

You can add obfuscation (not real security). For example you could XOR your password with a second password.

Maybe you'd like a type structure (especially the last image)? https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Type-Structure/idi-p/3017975

I really like this library. It's simple to use and understand. It's not viral.

Of course at that point, there's no need to maintain the feature where newer versions can recompile older versions. It's all compiled for good now so there's no need to leave any part decrypted. Surely the RTEs don't have this security hole right .

Is there a good way to grow an xnode from the scripting engine? When I try and pull up properties and methods I get nothing. Maybe there's a key missing in my LabVIEW.ini? To clarify, I want to do something like drop down the regular expression node, grow it a couple times, and then wire it up.