Leaderboard

Symbio is giving away 3 UML Architect GOOP Development Licences. FYI the new GDS release is supporting the Actor Framework, what better way is there to modelling your Actors in UML. //Mike

--- UPDATE 2012-08-05: Ticket pre-sales are now closed. If you need to buy a ticket at NIWeek, this post has what you need to know. --- It's that time of year again! Are you coming to NIWeek 2012? Do you want to enjoy cold beers and hot mesquite BBQ with your friends from LAVA, OpenG, and the whole LabVIEW Community? Then come to the 2012 LAVA / OpenG NIWeek Bar-B-Q! Year after year we bring together all your best online (and real-life!) friends from LAVA (LabVIEW Advanced Virtual Architects), OpenG (home of LabVIEW's open source community), and even the leaders in NI LabVIEW R&D. Come enjoy great barbecue with great people away from the hustle & bustle of the convention floor. Menu*: Mesquite BBQ beef brisket, chicken, and pork ribs. Potato salad, pinto beans, and coleslaw, and iced tea. There'll be a cash bar, and they have a great selection of brews. Date: Tuesday, August 7th, 2012, 7:00 PM (after the NIWeek "Block Diagram Party") Location: Scholz Garten, 1607 San Jacinto Blvd, Austin, TX 78701 Cost: $30 per person How to buy a ticket: Ticket pre-sales closed. See here to buy a ticket at the conference. *Vegetarian food is available on request -- PM Justin here for info. What to Wear: A LAVA T-Shirt, of course! Door Prizes Galore: Everyone is in the running for one of there super door prizes donated by other LAVA members. (You're welcome to offer up a prize too - hint, hint!)

I've been offered a great opportunity by National Instruments to take VI Shots on the road and bring it live to NIWeek 2012. I will be joined by several prominent members of the LabVIEW community at the technology theater in the exhibition hall on Tuesday Aug. 7th between 4-5pm. I will be recording the discussion live. If you are attending NIWeek, then come watch and be part of the show. We will be taking questions from the audience. However, your best bet to get a question in will be to post it ahead of time for consideration. Anything is fair game. Just go here and fill-in your question that you want to ask me or the rest of the panel: Click here to submit a question for VI Shots Live. Some of my guests will include: Brian Powell (NI) Justin Goeres (JKI) Christopher Relf (V I Engineering) Jack Dunaway

NSV's are publish-subscribe, so multiple Windows machines can still access the same SVs and therefore communicate with the cRIO. (We actually do this all the time.) (Of course, the host PC has to be running. This could be an important consideration depedning on the use case. For us that is easy to ensure.)

Greg: Yes, making the subVI inline does make it possible for the output to avoid calculation entirely. Doing it on any subVI call is something that the compiler optimization team has on its list of possible optimizations, but not currently implemented.

Jonah Paul (Product Manager for LabVIEW RT/FPGA) is very excited to be attending the BBQ and giving away a brand new LabVIEW RIO Evaluation Kit! HW geeks - tell me you're not drooling - I am

In what has to be the most off-topic LAVA/OpenG BBQ door prize ever, I'll be giving away two advance copies of my graphical novel Rune: A Tale of Wizards and Kings, which is coming out in October.

Your curiosity will have to be satisfied with "a certain way we can configure the UI to make controls generic".

Just so everyone is clear: Using the Not A Refnum function to decide to create a refnum is ok because the zero refnum cannot be destroyed/released in a parallel thread. But since the primitive does the extra work of validating the refnum, you take a performance hit on the cases that are going to succeed. Using the Not A Refnum function to decide to do an action or not is a race condition because a parallel thread could be destroying that refnum in between the test and the action. If you need to actually do an operation, do one of these: If you need the combined behavior of "if the refnum is bad, allocate it, and do some operation on it", then do this: What is an acceptable use case for the Not A Refnum primitive? When you're evaluating the status of one refnum before taking an action on another refnum! Or if you're just displaying information in a Custom Probe. Or if you have absolutely nothing happening in parallel (in which case, you might reconsider your use of references anyway). (For advanced users who suggest the use of semaphores to protect the access, that counts only as an OK usage because you still have a performance hit of unlocking and locking the refnum twice.) If you ever are tempted to file a bug report that the LabVIEW queue functions are broken, please check your use of Not A Refnum first. I guarantee I will when the bug report gets to me. 🙂 And, for the record, all of the above also applies to using "Get Queue Status" and "Get Notifier Status" functions. And any other similar "is this refnum still valid" functions that you are using to make decisions in code.