JKSH

Yep, one repo per library sounds good. This is a valid solution. It's called "bundled libraries". It works for tiny libraries, where creating release packages (described below) might be an overkill. (I personally don't like bundled libraries because the duplication can make things messy in the long run, but it works) user.lib was designed precisely for this purpose. The fact that the project devs "need to know to check out the dependent libraries" should not be considered a disadvantage. After all, a project's dependencies should be part of the project documentation. However, the project devs should not check out the library. Instead, they should install the library -- install a stable released version, which has been nicely packaged by the library's developers. See the VI Package Manager: http://jki.net/vipm Again, I would not make individual revisions accessible. Project devs should only be allowed to choose from the (small) set of stable releases. Furthermore, a mature library should ideally have a stable Application Programming Interface (API). Newer versions should aim to avoid changes that break compatibility with older versions. This way, you don't need to worry about juggling multiple versions -- just install the latest stable version. Exceptions to the "minimize compatibility breaks" rule are: When the library is in its infancy: It's ok to play around with the API at the start, to figure out the best design. However, it's probably risky for projects to rely on an immature library anyway. (If the library is that new and it's under your control, you could develop the library as part of your project first. Then, when it matures, split it off into its own repo as a standalone library.) When the library has evolved to a point where it needs to free itself from the shackles of old, deprecated functions in order to progress further, or when the burden of maintaining the old functions becomes too great. This should not be a regular occurrence (once every few years, perhaps?)

It's fine; NI themselves published the list: http://download.ni.com/evaluation/certification/cld/cld_exam_prep_guide_english.pdf

Congratulations!

Do you know if LabVIEW do this for OS X menubars too? These are meant to be attached to the top of the screen, not to the application window itself (even some Linux distros follow this style).

TIL... this is an eye-opener. Thanks! (Is this documented anywhere, by the way?)

You're right, writing in chunks reduces fragmentation and improves read/write performance. However, you can let TDMS driver handle this for you instead of writing your own buffer code: http://zone.ni.com/reference/en-XX/help/371361M-01/lvconcepts/fileio_tdms_file_buffering/ http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/setting_tdms_buffersize/

Unfortunately not... I use DownThemAll on Firefox.

NI's website provides a direct download too, bypassing the NI Downloader. For example, go to http://www.ni.com/download/ni-daqmx-15.0.1/5353/en/ and look for "Standard Download". Funnily enough, it links to "support/softlib" via HTTP: http://ftp.ni.com/support/softlib/multifunction_daq/nidaqmx/15.0.1/NIDAQ1501f3.exe I like to Google for the version I want, and then use a download accelerator on the direct download. Google's search operators make it easy to find things (no need navigate the folder hierarchy). For example, type "site:ni.com/download DAQmx" or "site:ni.com/download DAQmx 15" into Google and see what you get.

Ooh, is it possible to obtain a VI reference by its name? Open VI Reference has "VI Path" as a compulsory input (and no VI name input)

Hi all, If I pass a static VI reference straight into Start Asynchronous Call, I get Error 1576: A Start Asynchronous Call node received a reference input that was not configured to allow asynchronous calls. The documentation says that the reference must be "'prepared for asynchronous execution by the Open VI Reference function using either the 0x80 or 0x100 option flag". The simplest way to accomplish this (that I could find) is to first get the path from the static reference and then use that to open a new dynamic reference: That works, but feels a bit clunky. I don't suppose there's a way to apply the option flag directly onto the original static reference?

Hi all, I know that separating compiled code from source is good for a project that's in development, as it avoids the need to re-save every other VI in the project after one small change. That makes source control much saner. What about code libraries that are distributed to other developers though (e.g. through VIPM)? The user of the library wouldn't (shouldn't) modify the library VIs, so the previous reasoning no longer applies. Is there a good reason to enforce separation (or enforce non-separation)?

See hooovahh's post above.

I upgraded my home PC (not my work PC yet) to Windows 10, and it's been a good experience so far except for a small annoyance with mouse wheels in LabVIEW: https://lavag.org/topic/19185-scroll-wheel-not-working-windows-10-labview-2015-parallels-vm/#entry115740 I pin my frequently used apps to the Taskbar (one less click to open, compared to pinning to the start menu). For everything else, I treat it like LabVIEW Quick Drop: [Windows] + [First Few Letters of App Name] + [Enter]

Please ensure that your genetically-modified nodes don't escape into the wild!

I upgraded from Windows 8.1 to Windows 10, and noticed that my mouse wheel no longer scrolls combo boxes (text rings). I can still use it to scroll my front panels, front panel arrays, and block diagrams though. Running LabVIEW 2013 on a physical machine, not a VM.

I'm guessing h I'm guessing he used his backdoor VI editor (https://lavag.org/topic/19178-low-level-vi-data-editor-warning-not-for-production-use/) to create a mutant subtract node

:-S What did you DO to the subtract node?!

I've dabbled for about 1 year, and I haven't needed wanted mutation history either. I have a VI that recurses through my project folders, stripping out all mutation history before I commit my files into source control. The current serialization system needs a major overhaul; AristosQueue has a side project to improve it: https://decibel.ni.com/content/docs/DOC-24015

The LVClass remembers its previous states in its Mutation History. If I'm not mistaken, NI designed this to help VIs that use your class to adapt to the newer version. There is currently no way to delete mutation history via the LabVIEW IDE itself. Your options are: Delete it from the *.lvclass file directly (it's an XML file): See http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-right-click-option-to-delete-class-mutation-history/idi-p/2594921 Use these NI-created VIs to delete the history: http://digital.ni.com/public.nsf/allkb/F0FC362A73C794BA86257C6700692B0B

That technique works for all numbers of rows and columns. (Row Size) x (Column Size) = (Number of Elements in the 2D Array) Do you want to start counting from 1 or 0? If you count from 1, then the last "index" is (Number of Elements in the 2D Array) If you count from 0, then the last "index" is (Number of Elements in the 2D Array)-1 Try it for different array sizes. You'll see that it always works.

Use the Array Size Function, and then multiply (Row Size) x (Column Size).

Hi, Unlike MATLAB, LabVIEW does not use linear indexing. Since you have a 2D array, each element is indexed using 2 numbers (think of it as the row number and column number). Also, LabVIEW's indexing starts from 0. So, the index of "bee" is (2, 3), not 11 or 12. You can use the Array Size Function to find the dimensions of the array (3x4), and then subtract 1 from each element to get (2, 3).

I wonder if it's a race condition, since you are accessing the same variable in two places in your diagram. I'm also wondering if something got corrupted. What happens if you delete the SV node from your block diagram? What happens if you try to write to the variable without opening a connection? Right-click the SV node and select "Replace with Programmatic Access". Does this one work? What happens if you undeploy everything from your cRIO, and then deploy the variables again? What happens if you undeploy everything from your cRIO, and then create a new project with new variables? (Drastic measures) What happens if you reformat your cRIO, install your software from scratch, and try again?

ensegre has given you a good starting point. Would you like to try modifying his code to match what you want?

Sounds good Happy coding!