Leaderboard

We've posted a Knowledge Base (KB) article on this subject; Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams, which explains, in some detail, why the VI password protection feature is implemented as it is and the alternative available when stronger protection is required. We also plan to add a link to this KB in our product and/or help documentation, where appropriate, as part of our next major release. Our aim is to do our best to help users be aware of the issue and understand their options. I will monitor this thread for a bit and respond to questions or concerns as needed. Sincerely, Roy Faltesek Senior Group Manager LabVIEW R&D National Instruments

I posted a small tidbit of useful info over on ni.com for those of you who like to squeeze every drop of performance out of your LV code. This tidbit involves avoiding data copies when doing type testing on objects: http://forums.ni.com/t5/LabVIEW/Performance-tweak-for-LV-Classes-and-quot-To-More-Specific-quot/m-p/1760322/message-uid/1760322#U1760322

When developing apps with multiple parallel processes, many developers prefer messaging systems over reference-based data. One of the difficulties in messaging applications is how to handle request-reply sequences between two loops. Broadly speaking there are two approaches: synchronous messages and asynchronous messages. In some ways synchronous messaging is easier to understand. The sender asks the receiver for a piece of data and waits for a response before continuing. The downside is the sender isn't processing new messages while its waiting. Important messages will go unnoticed until the sender receives the data or gets tired of waiting. It can also be hard to verify correctness in synchronous messaging system. Cross loop execution dependency may hide deadlocks in your code and they are very hard to identify. Asynchronous messaging sidesteps the issue of deadlocks. Each loop executes on its own schedule so there's no danger of multiple loops waiting on each other. The drawback? There are a lot more messages to handle and the bookkeeping for sequences of data exchanges can get messy. For example, if a data consumer, C, needs data from a data producer, P, it might send a GetData message then continue servicing messages as they arrive. When P processes the GetData message, it in turn sends a HereIsData message back to C. C then not only needs to implement a HereIsData message handler, but also needs to keep track of the reason why it wanted the data in the first place so it can continue its previous task--there is more state to manage. Since synchronous messaging processes the returned data inline with the request it doesn't have this problem. Often I eliminate the need for additional state management by having P broadcast new data to all C's every time it changes. That ensures each C has the latest data and can use its internal copy inline instead of requesting it and waiting for a response. Sometimes that is not a very good solution. Consider the case of a high output P and a C that sometimes, but rarely, needs the data. That's exactly what I ran into recently with a motion control system where the motor positions are updated every 10 ms or so but the UI needs to know position data maybe 5 times every 30 minutes. Continuously broadcasting position data to the UI seemed like a waste of resources. Where am I going with all this? A little while ago I ran across a concept called "futures." It is essentially a promise to supply needed data at some point in the future when it is not available at that instant. The future doesn't have the data now, but it will when it is redeemed. Rather than broadcasting thousands of unnecessary messages or creating lots of extra states to manage, I used futures to get the readability of synchronous messaging while (mostly) maintaining the natural parallelism of asynchronous messaging. I don't have time to code up an example right now so let me try to describe it. (If there's interest I'll try to post an example later.) The process flow I used for my futures is similar to this: 1. UI determines it needs position data from the motion controller (MC.) 2. UI creates a future and keeps one copy for itself, sending the other copy to the MC as asynchronous message data. 3. UI continues processing, not caring about the specific data right now but trusting it will be there when needed. 4. MC eventually processes the message and "fills" the future. 5. UI gets to the point in its execution where it needs the data, so it "redeems" its copy of the future and obtains the data filled by MC. Compare that with synchronous messaging and the difference becomes clear: 1. UI determines it needs position data from the motion controller (MC.) 2. UI requests position data from MC. 3. UI sleeps while waiting for a response. 4. MC eventually process the message and sends a response. 5. UI continues processing, confident it has the data it needs for future processing. I don't claim this idea as my own, or even that its new. I implemented the future using a notifier. In fact, under the hood a future looks a lot like a synchronous message. The important difference is where the waiting takes place. Synchronous messaging forces the sender to wait for a response to the message before continuing. Futures give the sender more control over their own execution. They can redeem the future immediately and behave like a synchronous message or they can redeem it in the future and continue doing other stuff. It turns out I unknowingly implemented futures about a year ago as a way to have synchronous messaging with LapDog. At the time I was focused on obtaining the response before continuing, so it never occurred to me to defer reading the notifier until the data was actually used. I've just started using this idea so I don't really know where it'll lead. I don't think it's a "safe" replacement to synchronous messaging; there is still the danger of deadlocks if futures are used extensively. I think they're better used as a lightweight request-response mechanism when implementing a new state is too heavy and broadcasting is too resource intensive.

Jason Willis, aka WireWarrior on the LAVA forums, is a CLD from Little Rock, Arkansas, USA and very keen to start helping. On behalf of the OpenG Team I would like to welcome Jason on board and look forward to his contributions! In fact, he will be chairing the Variant Config Update - haven't seen it? - check it out here! Kind Regards Jonathon Green OpenG Manager Wanna be an OpenG Developer too? PM me.

The iOS will never have as much functionality as a computer. That being said, when it comes to tablets more weight is given to ease of use. The purpose of a tablet is consuming information/media or entertainment. The iPad is successful because it does that out of the box and you aren't burdened with any of the minute details. If you want to be bothered by those details and spend more time customizing your experience you can go in that direction. I think at one end you start with an iPad that holds your hand for you and makes sure you have fun and at the other end you find yourself building a linux kernel for your netbook and customizing your display drivers weekly because the manufacturer doesn't support linux. I have an iPhone and an iPad1. I will never have a mac computer. The difference is that these things serve separate purposes. I use the iPad to surf the internet while watching tv or keep up with football scores. I use my computer to do real things.

Along the lines of what Ben suggested, I believe you can simply add a second plot with x=0 for all y values and simply use that plot as the fill baseline for the first plot. I'd do the similar thing for the horizontal rendering (y=0 for all x) so you do not have to futz with the fill baseline via property nodes and can always fill to plot 1.

...wow well that site is interesting. FYI it seems that the NI forum has found it as well. http://forums.ni.com...p/310730/page/6 For those of you that are interested the site appears to take a VI and overwrite the password with a known one, and then recalculate two hashes needed. It seems to me the person that owns that site must have some inside information from NI about the file structure. Not necessarily in how to parse the blocks of data (I can see that) but I'm not sure I would have been able to determine the two hashes that need to get recalculated when the password is changed.