Sean Donner

This track was everything I hoped it would be and I hope NI brings it back for next year. I especially enjoyed your session on Xnodes and VIM's Brian.

Thank you so much, there are at least 3 recorded sessions I wanted to make but couldn't due to conflicts.

I don't disagree that there wasn't some editing, but there is a lot you can do to match those pictures with just standard LabVIEW. For example, that pink box around the Z transform VIs can be accomplished with decorations. Here is something I whipped up in < 10 mins. It looks like the size of the 'Merge Signals' VI has been blown up because 13 inputs is as tall as 6 of those Z-transform VI's stacked up vertically. The standard one only gives you about 3. I tried to cheat a bit by making the VI's icons about 5 pixels smaller on each side.

There we go. It looks like they took LabVIEW code and did a zoom desktop to make the code look bigger for the silver screen. The top image is definitely 'Split Signals' running into some unknown intermediate VIs which then merge into the 'Sine' VI. The bottom image is also definitely the 'Merge Signals' VI that is taking input from what looks like some Z-transform VIs. I don't recognize those so those might just be custom.

You're right, the images posted don't look like LabVIEW. However, these are not the shots I remember, there are certainly other screen shots in this very same scene which I'm nearly certain were 'merge signal' VIs. Any chance you could grab screen caps of that program? It couldn't be more than 30 seconds away (forward or backward) from the screen caps you posted.

Just saw the SciFi Robotic AI movie called 'ChappiE' yesterday; it was no District 9 but it definitely had it's moments. Anyway, there was a brief 1, possible 2 seconds worth of shots showing LabVIEW code. I couldn't quite make it out but it looked like there was a ton of 'Merge Signal' primitives. Anybody else catch this?

rolfk hit the nail right on the head, what he described is exactly my problem. I tried taking the suggestion of comparing OldVal to NewVal and not doing anything when they are equal and that does indeed stop me from getting 2x events when the value is changed from the UI but it also prevents the 3rd party app from ever firing an event because it appears that OldVal always equals NewVal. I guess I could use that info to my advantage and set a flag when the two values are equal so that if the UI event happens 2nd I can case off of the flag. I also moved the brat code into the timeout case of the event structure set to 10ms. I was hoping there was a way where I could completely abstract this without having to clutter up the event structure with odd control mechanisms but that possibility is looking less and less likely. I was thinking about using an AE to contain a control<-->value hashmap but I can't seem to figure a way to eliminate the race condition. I also tried out flushing the event queue every time my poll loop finds a change but that too is plagued by a race condition because I'm not guaranteed the UI event is on the queue by the time I try to flush it.

We have a 3rd party application that can talk to an arbitrary LabVIEW VI (or exe) via ActiveX and can both change and read the controls on the VI (or exe). The problem we are facing is that the ActiveX interface does not support events. This means that if a control registered for a value-change event has its value changed over ActiveX the VI does *not* fire off the value-change event; although the control's value will indeed change. Currently, our developers are working around this issue by forgoing the event structure altogher and using a polling loop instead. My goal is to see if I can abstract away the polling loop so the developers can use the event structure and I'm *almost* there but I've hit a problem. I've abstracted the polling loop into a "brat" VI that gets a ref to the parent and uses VI server to do the polling and if a value is found to be changed it issues a value-signaling event via the control's property node. This solution works exactly how I want it to as long as the *only* thing doing the value changing is the 3rd party application. The problem lies in the fact that the VI's front panel is still required to be visible and operational such that a user can change the control via the front panel as you normally do. If a user changes a control via the front panel, not only does my "brat" code detect this change and fire off a value signaling event but because it's done through the front panel the event structure fires off as well and now I get two events firing when I only want one. I don't expect there to be an elegant way to solve this, but what would be the least ugly way to do it? Is there anyway for my "brat" code to programatically detect the last time a control ref had an event fired, *and how* (front panel vs value signaling)? Thanks, -Sean

What about this .Net 4.0 library? http://sshnet.codeplex.com/

I'm a pretty avid Magic player and I thought it would be cool to get another 7 or more people together for a LAVA draft! If anybody is game, I have an unopened box of New Phyrexia I'd be willing to bring to crack open. I've always wanted to play cube but never made the time to put one together so if somebody wants to bring one that would be awesome as well. See you guys there.

Nevermind, I found the 'Limit Testing' VI!

A colleague of mine was tasked to create a program which takes as input 1000 data points each second along with two "masks", one for max and one for min, and the program will analyze and report TRUE if there is any section of the 1000 data points that fall perfectly in between the two masks. He wanted to do this in C++ but I told him this type of data analysis stuff sounds like LabVIEW's bread & butter. I browsed some of the Waveform VI's, especially the "Window" pallet but those don't seem to be what I want. I have an algorithm in mind to do this manually in LabVIEW, but id like some expert opinions if there is an easier way to do this with existing VI's before I attempt to remake the wheel; perhaps Open-G has something I can leverage as well? Just to drive home what I'm looking for, below is a visual picture of when the program would report back TRUE. I'm not sure how much this matters but I should mention that the two masks are NOT given as 1000 data points like the pulse to analyze is. Rather, since they are simple step functions they are given with level (V) + duration (ms) pairs. For example one of the masks could be described as: 0.1 250 10.0 500 0.1 250 Which means the pulse is 0.1 volts for 250ms then steps up to 10 volts for 500ms and then finally steps down to 0.1 volts again for the remaining 250ms. Thanks for your help!