X___

I am thrilled already 🙂

I followed @dadreamer's advice and now get verbose logs every time I get this. There are a few Insane object warnings I need to investigate in my main VI (some cluster constants), and some bizarre DSDisposeHandle errors pointing to that non-existing penguin path, a load of messages regarding references that couldn't be found in a cookie jar, some "this is dangerous" warnings, and tons of weird internal self-addressed warnings... I may contact NI support at some point, but since it is not killing me, I have put that on the "to do" pile.

As a note, a quick performance test comparing dropping a constant or an error ring in a case and running this over and over doesn't seem show much of a difference in terms of CPU (but benchmarking could probably done more carefully), so I may have just used up bandwidth for not much, as usual... 🙂

That's good advice, which could be added to the Help for the Error Ring, for instance...

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

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

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

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 thi

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 p

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.