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.

6 hours ago, drjdpowell said:

Like most problems, once I had a workaround, I no longer spent any time thinking about it.

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.

1 hour ago, drjdpowell said:

I've encountered a black imaq image display in exes, solved by unchecking the box to allow running in a later runtime version.  Don't know if that is related to your problem.

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:

Quote

I hope you are having a great day. This is XXXX from NI, Technical Support Engineering.

Based on your report, can you send me please the demo VI you mentioned in the description? Based on that I could move forward, reproduce it and fill the bug. I do apologize if you already attached that, but I could find it on the case files

Is this bug affecting your projects or you just wanted to report it? Because if it is unexpected behavior, the fix will depend on R&D priorities.
 

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):

Quote

Hi.

 

there used to be a way to upload files to document a bug report. Is this all gone by the wayside?

In any case, I am attaching an example code  (LV 2019 SP1) and image.

Instructions are on the VI's panel.

Thanks.

The last sentence is also worth its weight of peanuts...

Obviously, I am reporting bugs because I get a kick out of annoying NI!

1 hour ago, Antoine Chalons said:

I can confirm, it expects you LabVIEW License number.

I've recently created a few  SRQ via ni.com/ask

The interface and the process have changed a bit, but I could describe my issue and attach files (max report amd a zip containing code).

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.

On 3/16/2021 at 6:57 AM, Rolf Kalbermatter said:

The wrapping may be done anyways even if it is a clean pass through of all parameters. Simply because this was how the VIs always worked and it was actually easier. The lvanlys.dll had to be modified anyways, so just leave the original exports and redirect them wherever necessary to MKL, with or without any parameter massaging. This makes the tedious work of going into every single LabVIEW VI to edit the Call Library Node superfluous. And yes I have experience with wrapping DLLs from LabVIEW and can assure you that the last thing you want to do when changing something is to make a change that will require you to go into every single VI and make some more or less minor changes. Aside from being a mind numbing job, it is also VERY VERY easy to make stupid mistakes in such changes by forgetting a certain change in some of the VIs. And then you have to open each and every VI again to make sure that you did really change everything correctly, and to be safe, do that again and again. Tedious, painful and utterly unnecessary. Instead just leave the VIs alone, change the underlying DLL in whatever way you need and you are done. There is still a lot of testing after that, but at least one potential source of errors less.

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.

On 1/22/2021 at 11:00 AM, X___ said:

I am reading through that lingo and am trying to extract the substance. What I read is that she was hired by NI for a specific job, did (or not) do it and was, if not fired, at least forced into a situation which led to her resignation after about a year on the job. That sounds rather short to me, but it is true that I am not privy to the way things are working on modern corporate boards. Maybe that is the new trend. I suspect there is more to it, and that her opinion that the business was run in a very outdated manner (saying that on a podcast sounds to me very non-politically correct) may have been the main reason. After all, her title is/was Chief MARKETING Officer, not Chief OPERATING Officer. Then there is the question of whether the "Good Ol' Boys" club might have reacted unkindly to a female outsider (I am not clear what her Dell and Rack Space background means in terms of her tech-savvyness. After all, she appears to have a BA in architecture and seems to only have held marketing positions).

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)...

On 3/11/2021 at 1:32 PM, ThomasGutzler said:

I remove all compiled code from my vis and rarely see problems with it. Nothing that can't be resolved by clearing the compiled object cache. However, I found that the project-level check box doesn't work properly, so I wrote my own quick drop plugin that goes through the project to fix everything up.

In VIPM I usually keep the mass compile option after install checked, except for our build servers because they install a different set of packages with almost every build and it takes longer to mass compile everything.

Remove Compiled Code.vi 36.91 kB · 1 download

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).

21 hours ago, Rolf Kalbermatter said:

I'm not exactly privy to the details but most likely NI doesn't even build the MKL themselves. They simply take the binaries as released from Intel and package them with their LabVIEW wrapper and be done with it. And there are a number of issues with this that way:

1) NI can indeed not patch that library themselves anymore but has to wait on Intel to make bug fixes.

2) And NI won't pick a new release everytime Intel decides to make some more or less relevant change to that library. Instead they will likely review the list of changes since the last pick they did and decide if it is worth the hassle to rebuild a new MKL + LabVIEW package. This is not a one hour process of just adding the new DLLs to the old package build but instead involves a lot of extra work in terms of making sure everything is correct and lots and lots of testing too. The moment for such a review is likely usually a few months before a new release of LabVIEW. IF Intel happens to make this one single important change one month after this, NI will most likely not pick it up until the next review moment a few months before the next full LabVIEW release and then you can easily see how it can take 2 years.

<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:

On 3/22/2020 at 9:52 AM, Rolf Kalbermatter said:

lvanlys.dll is for the most part a thin wrapper around the Intel Math Kernel (MKL) library since many moons. It used to be a fully NI private implementation of the analysis functions but at some point NI realized that they never can beat the guys from Intel in making hyper-optimalized versions of those functions that work virtually on any CPU from early Pentiums to the latest iCore monsters with optimal performance (and also work on AMD CPUs as well).

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)

9 minutes ago, bjustice said:

I've been a big advocate for the Enthought Python integration toolkit in the past.  Unfortunately, the product was discontinued when LabVIEW introduced the native python node.
I'm still scraping by on this product as I've not found a good alternative, and the built-in LabVIEW python node doesn't meet my needs.
Under the hood, the Enthought product was just a TCP link to Enthought's flavor of python called Canopy... which has also been discontinued. 
This product was fantastic for a few reasons:

• Canopy environment could be packaged into a lightweight Python runtime engine, which can be zipped up and passed around with LabVIEW executables.  Made it easy to deploy the code to many machines.
• 32/64 bit LabVIEW compatible
• fast read/write of large data to/from Python

Relevant link:
https://support.enthought.com/hc/en-us/articles/360035630192-Toolkit-End-of-Life-Porting-to-LabVIEW-s-native-Python-support

I recognize that this probably isn't helpful... but a datapoint

 

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.

8 hours ago, drjdpowell said:

I've been investigating this: 

But I failed to get it to work.

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.