mje

Warning! This is purely academic. My current implementations work fine, I'm just going into excessive details here... My lack of a real CS background here is going to show, but I'm wondering if there's a way to compute array intersections that don't operate in linear time (that is I'd like the operation time not to scale linearly with array size)? I have two methods I hammered out: The first one is probably a little less obvious, but I actually consider it more elegant as it operates in place on the two input arrays, and avoids N^2-time by not blindly doing a nested for loop. Big caveat is the input arrays need to be pre-sorted. Works for me though since the arrays I will be feeding it always will be sorted by virtue of how they were created. The second one is slower by a factor of about 5 on my system, I suspect mostly due to the extra memory allocation being done by concatenating the two input arrays, I'm sure the sort doesn't help either. I'll be honest, both of these work in about a millisecond for the data I'm throwing at them, either one is fine. However they're called in series after a few binary searches I've implemented, and after powering through multiple arrays in microseconds (yay log(N)!), I hate to bottleneck afterwards with serial calls to a function that operates on N-time. I will be iterating over this a few thousand times though, going into log-time can mean the difference of waiting a few seconds and being instantaneous. I like instantaneous. -m

Holy cow people! Was this international insomnia day/night? I know at least some of you are based in North America... Anyways, neat stuff!

Reading through the replies got me thinking sub panel as well. I'm just not sure what the behavior would be...if a panel's updates are deferred will that property extend to the VI in the sub panel? I'm guessing no, but from an architecture stand point it would make sense that it does, so I honestly don't know what to expect. Sounds like it's experiment time.

I've handled this by globally disabling and greying all controls/indicators on the panel prior to a busy state. Then do your work, with deferred updates, and re-enable your controls. Easily done with VI server, there's a Controls[] property somewhere in there. Works good if you have some sort of state machine too, your enable method just needs to be state aware. Also saw a slick demo at the last NI week that had a VI grey out when it displayed a modal dialog box. Pretty sure it was done with a simple image overlay using the alpha channel. Not sure if it was as simple as toggling visibility, or if it involved moving the image from an off screen location, but it looked really slick.

I thought that behavior was odd as well. Features are fun!

Considering this code works... ...I'd be putting my money on the invoke node? Interesting none the less, good find.

Yes! Leave PayPal. Please. It took me many years to finally bite the bullet and support this site, solely because I didn't want to use PayPal. Needless to say I have a bad experience with them as well, but it's nothing you won't hear a hundred times over on other sites. My only recommendation if lava sticks with Paypal is: Have a completely isolated bank account which is only used for Paypal Empty the Paypal account to your main account regularly Have a completely isolated bank account which is only used for Paypal Don't ever maintain a balance in the account Paypal has access to Have a completely isolated bank account which is only used for Paypal Also, being able to purchase rather than subscribe would be nice. Auto-renewing memberships set off certain flags if I try to expense it

I think to some extent, yes we are walled off. I'm pretty ignorant of non NI hardware. To some extent it's intentional. My time is way to valuable to spend tackling the latest low-cost, low-support, low-functionality, low-extensibility system from some other vendor. I buy and work with NI because their hardware just works (usually). For me its an investment in a platform that is proven, stable, and reliable, with good support for both hardware and software.

I have my doubts about priority as well. I was thinking it was most likely first to the line or possibly the behavior might be explicitly undefined.

Is there any priority logic that gets applied to tasks that are blocked on a DVR refnum at an in place element structure? That is, consider two tasks which are both blocked while waiting for a refnum to become available. Is there any way to know which will be allowed to operate first? Does the priority of the containing VI affect this decision at all? Does the order in which the tasks blocked influence which will be signaled first? What about the phase of the moon?

If I look at the error list (same one that appears if you try to click on a broken run arrow, or use the Ctrl+L key), and have the "Show Warnings" box checked, you should see it. Note it's a warning, not an error.

I'm having a slight issue where I'm getting warnings appearing in some of my VIs that use event structues: The above code appears to be fine, but once I run it, the VI generates a warning in the error list. So yeah...am I going crazy here? There's no custom objects or types involved, no other cases in the event structure, what you see in the snippet above is what you get. Is the warning being misassigned, or is there really a problem with the event data that is signalled for in this case, a boolean button? I find the warning annoying since I'm trying to clear a re-use library of all warnings, and I need to wade through several of these... Example VI is attached (2010)... duplicate names.vi

Ok, I'll bite. Portal? I'm usually RSS or active content.

Also noticed a problem with my last paragraph. It seems the problem only creeps up when consecutive calls to the same clone are made. Either way, reentrancy made for some nice and random behavior depending on how the clones had previously been used.

True, that's another way to solve it. I dislike named objects though since their scope becomes global, so I pretty much treat them as global variables (I don't use them).

I had a deadlock issue that has been dogging me for almost two weeks now, and I finally understand what's been happening. I figured I'd share the experience, because it to me at least, it seems to be caused by such an esoteric detail that I'm surprised I was even able to track it down. I'm hoping that if at least one other person learns something, the time I spent on this will be somewhat redeemed. So if you will, it's story time. Please examine this little bit of code. The only non-stock VI is a simple read accessor for an object. Everything else is DVR, notifier, or error related. It's LV2010 code. (Ignore the breakpoint please). This little bit of logic has proven to be the bane of my existence for some time now. I'll explain the logic briefly: This VI is meant to stop an asynchronous task that the PumpRef DVR encapsulates. The VI obtains a notifier reference, and checks for an existing notification via a 0 ms timeout. False case: If we don't timeout, that means a previous notification exists and the task has already stopped (this is the case shown in the screenshot), and no operation on the DVR is performed. True case: If we do timeout, this means the asynchronous task might still be running (yes might, just trust me on this, I said it's story time, not thesis time). So we send a signal to the asynchronous task to tell it to stop. This is not shown in the screenshot, it's in the True case of the case structure. We then release the lock on the DVR, and block on the same notifier. One of two things should happen: 1) If the false case above fired, we'll just pass right through the wait since a notification already existed. 2) If the true case fired, at this point we'll block until the asynchronous task returns, then we'll be off to the races because the last thing the task does is signal the notifier. Now there's a huge problem with this. The logic above is sound, but there's a very important implementation caveat about using the Wait on Notification primitive: Emphasis added. It's the emphasized part that bit me in the behind. The logic of the framework I'm working on is a little more complicated than the simple case I outlined here (big surprise, huh?) and it turns out that the VI will sometimes be called twice in succession. Well, guess what, in that case the logic works like this: First call, first Wait on Notification primitive: Timeout, the asynchronous task is running. A signal is sent (not shown, True case of the structure), and it starts the shutdown sequence. First call, second Wait: Blocks, eventually the asynchronous task returns, signalling the notifier, and the VI ultimately returns. Second call, first Wait: Returns notification, this particular instance of the prim has never seen the notification before. Second call, second Wait: Deadlock. Why a deadlock? Because the second instance of the Wait prim has already received the notification in the first call to the VI. It will never return. The solution you ask? Use a single element queue, and do queue previews. The lesson: Be very careful when reusing notifier primitives if you're expecting to be able to receive old notifications. Bonus points: Reentrancy does not seem to affect primitive reuse. The VI above is in fact reentrant with multiple clones flying around. If clone 1 of the VI fires first, clone 2 will still deadlock. I did not expect this (queue up another few days of debugging)... So cheers, and thanks for paying attention if you kept reading this far. -Michael

Yup, therein lies the rub. I'm aware of your tool but I've never successfully got the right click framework to work on my development systems. Haven't tried since 2010 though, might have to give it a whirl one day. Edit: I totally misread the requirements...quick drop plugin, not RCF...I'll definitely need to take a look.

So, I'm doing really menial work right now, but the perfectionist in me demands I do it. Might be going a little crazy while doing it though. But I had an idea. So I posted it. Basically, when editing the icon of a dynamic dispatch VI, I'd like to automatically be able to apply an icon change to all child implementations. Not unlike how icon changes propagate through all objects when you edit a library icon, only you know, now for dynamic dispatch VIs. You all agree? Oh man, that last one I fixed is off by one pixel relative to its parent... -m

Sweet. Thank you both for clarifying that. -m

Still seem to be missing some dependencies. Of note, I'm getting complaints about MessageQueue.lvclass, Message.lvclass, and ErrorMessage.lvclass. Seems neat though, can't wait to look more into this!

We do exactly the same thing with one of our applications we've written, each object knows how to manipulate its data by virtue of its class, but the user of the object only cares that its some instance of a base class that can be operated on (it's in fact a base class wire that gets passed around) . However since myself and the other person I work with are both chemists by trade, neither of us know the "proper" name for what we're working on either. To me it's always just been an application of OOP-based polymorphism.

Transformations don't require a new buffer because you're telling LabVIEW to change the way it interprets an existing piece of data. The string "8243" becomes the numbers {56, 50, 52, 51} or {0x38, 0x32, 0x34, 0x33} because it is the U8 representation of the same data the string contains. Cast to a U16 and you get only a two element array {14386, 13363} or {0x3832, 0x3433}. Now I'm a little unsure about reinterpretation. It makes sense to me that a temporary buffer would be used if the two types don't occupy the same physical number of bytes, otherwise memory would start leaking all over the place. Make our string "82437" and our U8 data is as expected since the sizes align and can be made to match, {0x38, 0x32, 0x34, 0x33, 0x37}. Cast to a U16 though and we now have alignment issues that cause size mismatches, the cast returns {0x3832, 0x3433}. We've lost our last byte of data. I'd expect this is a re-interpretation?

Yes, I suppose that if this ever were to see the light of day, some connector pane requirements would have to be enforced, not like those for the VIs in property definition folders. I'm curious, in the case of property nodes operating on class DVR refnums, are the errors that can be produced (not counting the ones the VIs themselves might throw) the same as those that might be generated through an explicit in-place element structure? Also, I'm curious if using property nodes on simple by-value class wires (not refnums), can any errors be generated at all (other than any that are generated explicitly by the underlying methods)?

I've been working with data value references of classes quite a bit over the last few weeks. One feature I've fallen in love with is the new property definition folders for classes that the 2010 IDE allows us to use. Not sure how many of you are aware, but in addition to allowing easy access to several bits of data from a single node, they also automagically handle locking/releasing of class DVRs as well: Which is completely awesome, by the way. Kudos for adding that feature. Which got me thinking, it would be neat if statically dispatched methods could also do it. Currently for methods I might need to access from both a by-value and a by-reference scope, I find myself writing two methods: the by-value one which has all the logic, and a thin by-reference wrapper which simply calls the by-value method from within an IPE structure. I've love it if the NI wizards could find a way to have this happen automatically, kind of like the property nodes. The only problem I see is how is LV to know when to be able to allow the use of this automatic dereferencing? There would likely need to be a requirement of having both an input and output for the class of interest, but other things creep up to, such as methods which have both in and outs for multiple classes. This might require a new type of connector flag separate from the four currently used (Dynamic, Required, Recommended, Optional)? Any thoughts on this?