Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by X___

  1. Sorry, I didn't realize that I was trying to "steal" diagrams. Thanks for clarifying.
  2. Now that makes perfect sense.
  3. So NI knows that their password protection is a joke, but they are still using it. No comment.
  4. Well, I presented a clear business case against locked diagrams: they prevent the Analyzer (a NI product) from working correctly. Following your logic, I wonder why nobody has thought of preventing people from using pointers in C because they could crash their software? Providing detailed documentation is not a NI priority, we know that. Fine. Their market share is plummeting in the software development arena, especially in academia. Are the two correlated? Maybe. I am certainly not at war with NI, and my leaving NI forums a few years ago is due to the fact that I felt that my inputs
  5. My ignorance amazes me, sometimes most of the time...
  6. Then we agree that it would be best to release the source code, since this would point directly to another culprit. And BTW, as we discussed in another thread, I believe that there are still some "native" (as in NI brewed) implementations of some of the analysis routines (with their associated corner case bugs). This being said, regarding password protected VIs, I just ran into a LV Analyzer error due to one of the VIs calling one of the User Tags VIs (which are protected because they probably use some super-secret call which are not supposed to be left in the hands of peons). Which is pr
  7. Easy and we'll know what we are using. It's an academia thing, I guess, where a mistake haunts you for the remainder of your career, unlike in industry. You know, miles vs kilometers... I suppose we need to "follow the rules about filling out the form to document our concerns" too!
  8. Let's start with unlocking all VIs and documenting Math DLLs...
  9. I don't know about the future, but seeing how dynamic the first public beta is, the present is not particularly bright ๐Ÿ™‚
  10. Following this post, I installed 2019 SP1 in the hope that what I was experiencing was what was described as Bug number 217468 here: Right-Click Menu Commands Fail Intermittently Some right-click commands fail intermittently. For example, the VI Analyzer command Create ยป #via_ignore bookmark creates the bookmark but then erroneously deletes it. Workaround: Fixed in the LabVIEW 2019 SP1 f4 Patch. I don't use VI Analyzer (that much) so this is not what I have been experiencing (see post above), but 2019 SP1 f4 certainly did not fix it. I guess this is a bug indeed, but I
  11. OK, I'll blame MS...again: https://forums.ni.com/t5/LabVIEW/Create-Folder-Buggy-Dialog/m-p/1504232
  12. I am trying to understand an odd behavior of the File Dialog Express VI which I tend to use in most of my UIs. The snippet below provides an illustration of what I am discussing next: Generally, I will pick an existing file path for start path and either a default name, or one that makes sense in the context for name or relative path. Here an hdf5 file extension is added to/replaced in that template (but this is irrelevant) and the resulting (generally) non-existing file path is fed to the File Dialog Express VI (configured to accept single file path, new or existing files
  13. Thanks for the heads up. Still using f3. I am surprised that I haven't been nagged by NIPM yet... Is that patch even documented anywhere?
  14. Could be useful, especially since I do not store the LV code in the VM but on the host machine, so essentially, there is only the development environment in it. It is backed up with the rest of my machine though.
  15. I just spent a whole day setting up a VM and installing an older version of LV with the right toolkits and driver versions needed on my deployment machine because... versions and toolkits are incompatible and exclusive from one another. 10s of GB most of them useless for my purpose. Awesome.
  16. I am thrilled already ๐Ÿ™‚
  17. 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.
  18. 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... ๐Ÿ™‚
  19. That's good advice, which could be added to the Help for the Error Ring, for instance...
  20. 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
  21. 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
  22. 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.
  23. 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
  24. 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
  25. 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).
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.