Leaderboard

Because I can immediately test the correctness of any of those VI's by pressing run and viewing the indicators. Nope. That's just a generalisation based on your specific workflow. If you have a bug, you may not know what VI it resides in and bugs can be introduced retrospectively because of changes in scope. Bugs can arise at any time when changes are made and not just in the VI you changed. If you are not using blackbox testing and relying on unit tests, your software definitely has bugs in it and your customers will find them before you do. Again. That's just your specific workflow. The idea of having "debugging sessions" is an anathema to me. I make a change, run it, make a change, run it. That's my workflow - inline testing while coding along with unit testing at the cycle end. The goal is to have zero failures in unit testing or, put it another way, unit and blackbox testing is the customer! Unlike most of the text languages; we have just-in-time compilation - use it. I can quantitively do that without running unit tests using a front panel. What's your metric for being happy that a VI works well without a front panel? Passes a unit test? It may be in the codebase for 30 years but when debugging I may need to use the suspend (see below) to trace another bug through that and many other VI's. There is a setting on subVI's that allow the FP to suspend the execution of a VI and allow modification of the data and run it over and over again while the rest of the system carries on. This is an invaluable feature which requires a front panel This is simply not true and is a fundamental misunderstanding of how exe's are compiled. Can't wait for the complaint about the LabVIEW garbage collector. We'll agree to disagree.

<EOM>

Anyone else getting their popcorn? I cannot predict the future. And worrying about things I can't control gives me anxiety. So I'm just going to chug along as best as I can. My boss likes the work I do, and I like my job. I'll be mindful of industry changes. But at the moment I am not pivoting away from LabVIEW or NI if I can't help it.

The mutex ensures that no one else can perform a read or write while it is locked. Otherwise you could mismatch requests and replies. [W1,R1], [W2,R2] instead of potential W1, W2, R1, R2 You could have it in a non-reentrant VI, but then you would also restrict parallel operations for completely different ports. In this case, in could be wired direclty to out since there are no modifications to it. The mutex will be locked either way.

I was fairly sure that there was actually an application event for file open events passed from the OS to the running application, but seem to have dreamed that up. It shouldn't be to difficult to add although might have some implications. Would have to be a filter event that can check the file name and then indicates if LabVIEW should further handle it (for LabVIEW known file types), or if it should be ignored (potentially handling it yourself). Ahh, it's super secret private special stuff: And seems to have trouble in some newer versions than 8.2! Although Ton says he got it to work in 2009 again.

This looks interesting. What are the licensing used? What are the restrictions? Is there a manual that is in English? Is the source code available?

Oh, I knew. I just like to poke dormant threads (keeps the context instead of duplicating it into a new one) until their issue is resolved. Only then can they die, and live on forever in the cloud😉

This is a shameless plug for a new idea I've submitted to the Idea Exchange suggesting that by default, a VI should not have (or need) a Front Panel. Connections to the con-pane are defined from the Block Diagram - after all that's where the data is used, and the subVI interface to that data should be specified. One (or more) Front Panels can then be added which provide a user interface to the BD data (controls/indicators). Perhaps one is the standard run-time view, and another is a debugging view (like an enhanced Probe window). Or for many subVIs, there may be no FP at all. Kudos (or critique) welcome!!

^ 100% all these things.

These are for shared libraries.

That sounds like the LabVIEW Solution Builder, which I use. It works quite well.

Not sure about 2011 to be honest, but no you do not have to have all dependencies included in a PPL. You can have a PPL depend on other PPLs and configure the build to exclude that dependency from you PPL build, so that it remains external. This has of course to be down from bottom up, which is quite a work. Only PPL dependencies and other binary dependencies can be excluded from being pulled into a PPL. So if you want code that has to be shared between your PPL and other PPLs or your exe, that code needs to be in its own PPL, so each of those can refer to it. Yes it is not trivial and you need to plan before you start programming. You need to have a clear hierarchy overview and be able to cleanly modularize your code into different PPLs. Tools like the MGI Solution Builder definitely help with that as you can script the creation of a whole hierarchy of PPLs to be compiled in the correct order. Someone from NI was busy creating another solution that could build PPLs and in the process of building them also relink any dependencies on lvlib's into dependencies of lvlibp's but that didn't quite finish.

As an experiment in seeing what VIMs can do, here is an all-VIM implementation of a "circular buffer", based on code from a 2D DBL array circular buffer I had previously used. In LabVIEW 2018. Features: Works on any scalar type, giving a 1D array buffer, or any 1D array, giving a 2D array buffer (could be extended to a 3D buffer of 2D arrays) Has VIMs that accept either a by-Value Buffer, or a DVR of a Buffer Package contains simple examples. Comments welcome. jdp_science_lib_malleable_buffer-0.1.0.5.vip

Now I don't think it is completely fair to take what someone said during a presentation, and quote them out of context. But I just love this from Darren's presentation: If NI had a replacement for Project Providers that was documented and stable and all that, then I won't suggest anyone make a Project Provider plugin. Until then I say there is a time and place for them, just knowing the edge cases, documentation, and support issues. I think Darren's presentation does a good job of cautioning others.

For me it has improved but is not quite fixed. I still get broken wires on the calling VI when changing anything in some vims. In fact, I have a VI which I copied from the Debug Log.lvlib:Debug Write.vim in vi.lib and made some changes to. My version breaks when I change anything in it, but the VI.lib-one does not. I have force-recompiled and am now trying to make my VI work like the one in vi.lib, but mine still breaks. I just might recreate it and see where/if it breaks then. I don't know if I am unlucky or if that might happen for others too. When the wires do break, it seems like they auto-heal better than before, when I had to rewire at every broken place, but now its enough to just do something that triggers a compile (I think).

Put a new 0.5 version on VIPM.io Remember, this is still beta code.

Malleable Buffer.zip James: I did a lot of polish on your library -- cleaning diagrams, finishing out a couple of API points, documentation. I deleted the experiment stuff. You're free to take the attached files and add them to your published VIP if you want. There was only one real functionality change that I made: a performance improvement to "Add to Buffer (By Value).vi". Thank you -- this code is quite helpful in my current project.

I've put 0.4 on VIPM.io.

Decided to update this to 2020 and release (this is 0.3; I never posted 0.2): jdp_science_lib_malleable_buffer-0.3.0.8.vip

This IS fixed in LV 2020, but it got left out of the Upgrade Notes*. I have posted details here: https://forums.ni.com/t5/LabVIEW/LV-2020-Upgrade-Note-Altered-rules-for-named-Bundle-and-Unbundle/td-p/4035624 The fix is very healthy for most apps, but we did find one internal-to-NI app that was dependent on the dumb-luck-that-it-sometimes-works behavior. We had to fix that one up by using the Coerce To Value primitive to set a name of the element in the caller. But going forward, such antics should not be necessary... the adaptation rules of named bundle/unbundle are now well-defined. * My mistake -- apparently my tech writers cannot read my mind; I actually have to hit Submit on bug reports, not just leave them in Draft. *chagrin*

The New Data Value Ref and Delete Data Value Ref nodes will be able to be in inline VIs (and thus malleable VIs) in LV 2020.

I've put the freezing of the bundle/unbundle nodes (including those on the In-Place Element node) into LV 2020.

Major differences: One was an off-the-cuff prototype that frequently crashed, couldn't nest properly, had no well-defined recompile semantics (so you couldn't trust that if you made a change the callers saw it), and didn't integrate with any of the rest of LabVIEW features except by accident (and, in the case of polyVIs, that accidental interaction was a bug). The other is an actual feature. I don't think we retained any of the original code. Comparing them, especially in the context of complaining about loss of functionality, spreads disinformation to anyone who doesn't know the background history. If you meant it as a joke, you forgot your </joke> tags. I did not find your semantic antics amusing.

First up, it's not that I don't like Front Panels! Rather, the idea comes from the recognition that, as evidenced by a fair number of ideas in the Idea Exchange, FPs often add unnecessary work to developing VIs. I was trying to pull a number of different ideas together into a solution, sparked by reading this idea which suggests adding yet another layer to a VI - and questioning whether we can reduce complexity instead of increasing it. There's been some discussion on how to limit the FP to show only what's needed for the user interface (e.g. here). Having unneeded (from the interface point-of-view) controls and indicators on the FP means we need to work around issues such as edit-vs-run-time displays, setting up tab orders, rescaling controls (but only some of them) as panels change size, disabled code, and so on. The basis of my suggestion is not that we shouldn't have FPs, but that FPs should only contain what is needed to be seen by the user. Secondly, the data that needs to be seen during development or debugging is often very different again. When we use a Probe, we essentially create a virtual indicator. Take the Probe Window slightly further in its development, and we now have a second FP, which contains another set of controls/indicators for showing, or setting, the data during execution. Also, for many VIs, the variables that are passed through the conpane interface are not required to be shown in the user-interface - Error clusters for example. It makes sense to be able to link the conpane directly to BD controls, and therefore there is no need for the controls/indicators to appear on the FP at all - many subVIs without user interaction wouldn't need an FP defined at all. To me, the conpane has a much stronger link to the BD than the FP, as it is there to provide the programming interface to the code. The downside would be that it is perhaps more difficult to find terminals on a crowded BD, but that could be enhanced (e.g. mouse-over the conpane, and everything fades except for terminals). Perhaps there would even be the opportunity to see the FP as a virtual cluster. The LV paradigm presumably arises from the concept of Virtual Instruments, where the controls/indicators are what you define your instrument by - and much early code was all contained within one VI! This idea suggests that LV has perhaps grown past that stage, with far more emphasis now on subVIs, classes, libraries, etc which are maybe more like patch panels or breadboards (still thinking as an engineer!) - things that are hidden from the end-user. I don't see it as such a radical change - more a response to the way that LabVIEW is being used anyway - to make that process easier and more transparent.

It's with a saddened heart that I pass this news along, that we've lost a dear friend and LabVIEW Champion, @Kurt Friday. https://www.linkedin.com/feed/update/urn:li:activity:7212115164492353541/ We will miss you, mate.