infinitenothing

Do you ever come back to something super cryptic like "Open draft update node" and are like "WTF does that mean?"

I would push the data from C# to LV using UDP or TCP/IP. It should be quite fast.

I'd rather have broken code in the repo than code that works 80% of the time or a missing subVI. My most common "break" is to leave some simple minded wiring TBD as a nice warmup for the next morning

Here's another attempt: https://decibel.ni.com/content/docs/DOC-39565 It's something I think many developers want to do but it's going to need some more infrastructure to make it efficient to run and easy to use.

I agree it's a good use case for bookmarks. However, it requires that I remember to check bookmarks at the start. I tend to be in autopilot in the morning.

Does anyone else break their code so it won't compile at the end of the work day so that the next morning you open your project and follow the broken run arrow to what you were doing?

Thanks for fixing the conflicts. The new package works for me.

You can tell the flush event queue to flush all but the last one. It also outputs the number of events that were flushed so you can use that to detect you're at the end

A little bit off topic but if you wrote this sequence in TestStand, you'd already have HTML report generation by default. You'd also have a database, user logins, etc.

I've made some things like this. Usually I've used a tab control with the common controls floating over and the custom controls on their designated pages. The tab change event would sometimes hide or re-caption certain common controls. If you want another function, I'd make another tab page fill out the captions and visible flags. You need to send that over TCPIP? no prob, just send the function and a flattened cluster of the page contents or even send each individual control on value change. Not infinitely expandable or perfectly decoupled but it got the job done.

It's really a risk calculation. You have to anticipate what are the odds that down the road you'll want some feature (programmatic access? in place editing?) that globals can't easily provide. If you think you have a 10% chance you'll need that and it would take your 40 hours to pull out all your global and put in a better data type, you'd need to save 4 hours of development time to justify using a global. Maybe you should put in a fudge factor for unknown unknowns. So you'll want to save 40 hours of dev time to justify their use.

It's building a listener list (no time stamp) but it's not stored in the internal state of the WFN. It's limited to how many nodes you have (like you said).

Your peak detection may work better if you increase the peak width setting. The sine waves are flat at the top and don't look all that peaky if you just look at a narrow section.

You're not supposed to get notifications that occur between WON if you set the ignore flag to true are you?

You're going to have to give us some more examples of the echo so we know what to look for. If it always looks the same you can use the cross correlation of a "good looking" echo segment vs the waveform you want to search. The x location of the peak of the cross correlation will tell you where they line up (the start of your echo). http://paulbourke.net/miscellaneous/correlate/

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.