Leaderboard

The NIWeek 2015, 2016, 2017 Videos are compressed and ready for down load from Tecnova's ftp server I would strongly recommend using an ftp client to transfer them to your computer. A web browser may work but if you want to download multiple videos the ftp client makes things much easier. My ftp client of choice is FileZilla and it is free. FileZilla can be downloaded at http://filezilla-project.org/ If you are unfamiliar with FileZilla there is a youtube tutorial video found ftp://frc.tecnova.com login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. Please Let me know if you find any issues with the videos

Recently experienced a performance bug that I traced to a bug in my code related to shared variables that I just want to share to hopefully help others avoid this error. (This was running in LV2014 SP1 on Windows) I am using a dynamic shared variable "Read Variable Function.vi" but not opening the connection prior to reading the data. I accidentally had passed in an invalid PSP variable path to the "shared variable refnum in" input. This VI happened to be in a loop that was updating fairly frequently (every 50 ms). Well ... it turns out that because I wasn't opening the connection first and passing in an actual refnum, every time it hit this node, it retried opening a connection to a variable that didn't exist which eventually timed out - this was a very shared variable/(scan engine?) intense operation and effectively brought all of my other shared variable operations to a halt - performance went from awesome to a total drag and my application was almost unusable. Short term fix - I changed my configuration to point to an existing and valid PSP variable and all of my performance went back to normal. Hope this helps someone else avoid my "mistake" although I'd also call this a LV bug in a sense that it shouldn't drag an application's performance down in such a severe way if a variable goes from existing to non-existent.

Hi LAVA friends, We are pleased to announce that the Delacor Queued Message Handler (DQMH) is now available via the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286 You can read about the thought process behind DQMH at our blog post: Ours is not better than yours (or YAF=Yet Another Framework) at WalkingTheWires.com The DQMH is based on the NI QMH Project Template. The DQMH expands on the NI QMH by providing safe, event-based message handling and scripting tools to encourage same style between different developers in the same project and improve efficiency. The DQMH is ideal for applications where multiple modules must run in parallel, possibly at different rates, while communicating with each other. The DQMH can also be used for applications that have a single module, where the developer would benefit from having a Tester with the capability of eavesdropping on the different DQMH events and messages. The DQMH integrates with TestStand since all development and troubleshooting can take place under LabVIEW, while calling the public API VIs as individual steps in the TestStand sequence. The tester can eavesdrop during the execution of the TestStand sequence. This is specially useful when the LabVIEW code is written during the research and development or prototyping phase, because the same code can be called by TestStand in production or manufacturing sequences without any changes. The DQMH uses LVOOP for some internal functions, but developers need not be familiar with LVOOP to use or understand this architecture. Try it out and let's us know what you think. Fab and the Delacor team.

In AQ and John McBee's presentation "2015 NIWeek_21_Computer Science for the G Programmer Year 2" They mention 3 other videos from previous years. 2012 NIWeek_LabVIEW Classes State of the Art 2014 NIWeek_02_LabVIEW OOP CS for the G Programmer 2015 CLA_11_Dimitry Sagatelyan_Actor Programming Without AF These videos have also been included in the NIWeek 2015 folder Go to this link for information https://lavag.org/topic/19154-ni-week-2015-videos/ Please see this link for Video downloads https://lavag.org/topic/20645-labview-videos-tecnova-download-site/

I have the impression that Juypter is very much focussed around textual languages - I think most of the existing clients expect to send text to their kernels and get back a mixture of text and graphics. LabVIEW doesn't really lend itself to this paradigm. You could, of course, write an interpreter in LabVIEW that took textual input and did stuff with it, but frankly there are probably easier things to do. Where it did occur to me that Juypter might be interesting for LabVIEW developers would be in something along the lines of LabPython - which although it works great, does have issues with both 64bt platforms and using non-thread safe Python modules (notably numpy!). I have a feeling that Python 3.x is not supported either. A LabVIEW based client for Juypter kernels might be a way around this by decoupling the scripting language from the LabVIEW executable - allowing mix and match 32bit/64bit, newer versions of Python, alternative language bindings etc.... Just needs someone who understands the LabVIEW scriptnode interface, C bindings to 0MQ, and how to do the Juypter protocol - which rules me out on erm, 3 counts :-( !

This will let you connect any 1D array if you really hate polymorphic VIs and xnodes

Okay deep breathes everyone (including myself). New users need to be pointed in the right direction some times, there were times when we all knew nothing so they should have some slack just like we should have had some when we were new. But on the other side of it, how are new users going to know proper etiquette if we don't point out what it should be? Lets try to be mindful of other cultures and remember we all have bad days. Lets just try not to take it out on others. We can be overbearing at times, and new users can make mistakes.

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.