X___

I recently ran into an interesting problem: some calculations I was doing in which I used parallelized loops were taking an inordinate amount of time (and consuming 100% of my i9 cores). Turning to profiling to figure out where I might be bugging out or able to find some optimization, I realized that the most active subVI was this: Error Cluster from Error Code.vi There is an interesting discussion elsewhere about why this VI is a nuisance (even in its modernized version), which is compounded by the facts that: - it is randomly used by NI in its code (some error codes are never converted, let alone passed, so good luck to figure out why your code fails) - there is no particular discipline (from NI) on how it is used (for instance, random error codes (aka 1) are plumped on the diagram and connected to said ECfEC VI - it is used in locked VIs (super secret ugly code, presumably) For kicks, I zapped it and replaced it by a simple version of mine everywhere I could (that is, except in the locked VIs) and reran my calculation. Same symptoms. The locked VIs were for sure not the problem, as they were not called during the calculation, so I had to find out where this VI was called from and narrowed it down to one caller. I opened up the diagram... and did not find it there. However, I had two Error Ring "constants" on the diagram which, you probably know that or have figured it by now, I didn't, calls ECfEC.vi. One of the Error Ring, O Irony!, was a "no error" Error Ring "constant" (no comment): Therefore, merely running that subVI (which was supposed to be quasi-instantaneous), was now launching LabVIEW into the ECfEC.vi maze and hogging my computer. I have now removed the incriminating Error Rings and moved on, but I thought this potential issue should be better advertised. My 2 cts.

Sure, but are you not concerned enough when you see a pattern of concerning "features" piling up on NI's end, to at least suggest they pay attention? I am not making a living from NI's products. You seem to be... The fact that checking the "Allow future versions of the LabVIEW Runtime to run this application" should really read "and consequently make it impossible for intermediate versions to run your application" is one of the things which contribute to erode my trust in NI. And you know what they say about erosion. It starts with a trickle, and soon enough, you have a mountain tumbling down.

Have you talked with NI about that? I was debating whether that was worth for me to investigate further. I have learned to let a few versions go before upgrading and the thought of having to recommend using a RTE I haven't tested thoroughly (or even superficially) just for my app to be functional is not too exciting. Where is this written that checking that box meant you HAD to use the LATEST RTE? This sounds like a bug.

I am not sure I understand the problem: is this an IMAQ (DAQ) related problem or a Vision Development (image display control) issue? It sounds like the latter, but your inclusion of details of image acquisition is confusing. It might be totally irrelevant, but an app I develop in LV 2019 (using Vision Development 2019) failed to work when a user installed both runtimes on his computer (LV RTE and VDE RTE). It sounded like a Vision Development module license issue, which was strange as there should be a grace period for demos, but eventually it turned out that this was fixed when the user installed the 2020 runtime (I had selected the option to have the code able to be run with later version of the RTE). The symptoms were not a black image though (there was no image), but one of the VDE errors when one of the Vision VIs was called. My point is that there might be some issues with version conflicts... As far as trouble shooting, post your demo VI, I have 2018 SP1 installed on a machine where this is the only version isntalled, so I can test that.

I have been experiencing some weird "bug" lately, while using the Windows LV 2019 SP1 64 bit IDE, namely, the BD right-click context menu for objects only shows generic items (Create constant, etc.), completely failing to show the standard associated options (for instance bundle/unbundle for clusters, or New/Delete Data Value Reference for a DVR wire, etc.). I have found that tabbing through open Windows, or opening a new VI, in general is enough to restore the functionality, but this is very puzzling. Anyone else has experienced this type of weirdness? The only thing that I can think of that could be different from my previous configuration is that I switched to a new laptop (Windows 10 Pro), but I can hardly fathom why that would affect this installation...

I got confirmation that the attachments in my email were stripped off, and told that I could do exactly what Antoine just mentioned above. I am positive though that I was not offered this option when submitting the bug, which is a change compared to the past system. And again, there is no need for a S/N (a SSC number doesn't work).

It's getting better. First of all, gone are the annoying automatic acknowledgment emails. Not sure whether this is good or bad. After I received an email from a NI engineer asking me for details, I sent a demo VI and a test file (which I would have otherwise uploaded on the reporting site) attached to my email, only to receive the following after a few hours: So, either NI's email system strips any attachments from incoming emails, or the engineer doesn't understand English since I responded (and duly attached the two files): The last sentence is also worth its weight of peanuts... Obviously, I am reporting bugs because I get a kick out of annoying NI!

Try again. This doesn't work anymore. I received an email from NI, which I answered with an attachment, but this ability is gone on the website. Regarding S/N, you don't need one (this is specifically stated on the submission page).

Good catch. You'll love the expression node result!

Apparently, NI has changed there Support's website. - you cannot write a description of a problem. You choose your preferred communication means and write a one-liner topic, press "Send", and... wait to be contacted by NI. - you cannot provide example files when filing a bug "report". You can only provide "steps to reproduce". I guess there are so few bugs nowadays in LabVIEW that NI figured they could get rid of the whole obsolete process of filing detailed bug reports.

By "special functions", I mean "Special" functions such as Bessel, which can be found in the non-yellow subpalettes of the Elementary & Special Functions of the Mathematics palette. I am under the impression that those are not part of the MKL.

It appears that the Green Lady of NI has moved to even greener pastures: IBM - Biographies Can't abbreviate IBM (I?) but the website could use some of that pastel green and washed out pink palette NI has ambitiously engineered his website with.

I am not sure there is any special functions in the MKL (at least I could not find any in the description) and all these are LV_something in the DLL call. There is really no wrapping to be done here, as the arguments are only a few. So maybe after all NI did code those (sometimes using lousy algorithms, as was the case for the Kummer function)...

Similar to the VI posted at the end of the blog post 3 above (with less granularity and the option to do the reverse by mistake! :-) In what sense is the project-level check box not working? I am interested because I have set the app-scoped flag to "remove compiled code" but still occasionally find some new VIs (created by "Create sub VI from selection") with their flag turned OFF. It is probably time for me to ask whether I am just victim of a LV virus or this is indeed a reportable bug (very irreproducible, so not very convincingly reported).

<OOT> In the case of the Kummer function (which I was referring to above), this appears to be an internal algorithm as the function is called LV_Kummer (there are a number of similar LV_functions in the lvanlys.dll). For the purely MKL ones, I guess we have to check the bug fixes here (without knowing which one is relevant for which LV version...): MKL Bug Fixes </OOT>

<DEBUG_OUTPUT> 3/12/2021 10:42:37.511 AM DWarn 0xFCC058F4: An item recompiled in the final iteration should not still have recompile needed set: [VI "ix.vim" (0x0000029f40dbd0f0)] e:\builds\penguin\labview\branches\2019\dev\source\compiler\compiler.cpp(621) : DWarn 0xFCC058F4: An item recompiled in the final iteration should not still have recompile needed set: [VI "ix.vim" (0x0000029f40dbd0f0)] $Id: //labview/branches/2019/dev/source/compiler/compiler.cpp#6 $ First comment: the penguin has reared its ugly head (or tail) again! I do not have a E: drive on my PC, so this is probably some internal stuff, as is the //labview/branches/... thing. The ix.vim is mine though and while not doing what I want, it looks pretty innocuous:

Kind of out of topic, but if confirmed, that transposes the source code source from NI to Intel... MKL forums seem to be indicating that obtaining source code from Intel is a complex and costly proposition. I wonder whether this is why it took 2 years to fix a numerical bug in LabVIEW (i.e. this was out of the hands of NI and had to be fixed by Intel): https://forums.ni.com/t5/LabVIEW/Bug-in-the-Kummer-Function/m-p/2387522

I learned about the Project-level "Mark Existing Items" button reading that blog post...

Project Dragon LabVIEW: Announcing Project Dragon - Managing LabVIEW Virtual Environments with VIPM - YouTube Project Dragon Sign Up - VIPM 2021 (jki.net)

It was not free and indeed was carrying along a few MB of extra payload in each executable/distro. That link will not be usable by new users (as far as I understand) since they don't sell licenses anymore.

What is the problem? As far as I remember I just had to tweak a path constant... However this is more than python. It's python in a Jupyter notebook (which is getting very popular in many circles)

Sounds good. Will try.

I have my suspicions. But I like the terseness of the warnings (which pop-up only upon restarting LabVIEW). I suppose there is not more info that can be provided to the user (the LVInternalReports are binary files, so I can't make much of them).

The last time you ran LabVIEW, internal warning 0x occurred in image.cpp.

Appropriately enough, I recently got this startup warning as well: The last time you ran LabVIEW, internal warning 0x occurred in xstuffprivate.cpp.