Jump to content

Neil Pate

Members
  • Content Count

    709
  • Joined

  • Last visited

  • Days Won

    43

Neil Pate last won the day on March 2

Neil Pate had the most liked content!

Community Reputation

213

5 Followers

About Neil Pate

  • Rank
    The 500 club

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2013
  • Since
    2004

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. My programs are so well optimised the user never notices the delay 😉 Joking aside, if I am updating that many controls that the GUI is slow to paint it is probably symptomatic of a bad GUI design.
  2. I have tried many different techniques but my currently preferred one is to assume upfront that I am going to use property nodes for all value updates so this then allows me to have a nice Update Sub VI where I update all the values every time I need to update anything. Any non-trivial GUI seems to require property nodes to do the "fancy" stuff, so I just start off with them like that. I normally don't bother with a Defer unless I am dealing with a *lot* of indicators (which is probably a smell of a badly designed GUI) or one of the usual suspects like a big table or tree control.
  3. Thanks Rolf, that fix worked for me too! 👍🙏🙇‍♂️ I did search but never found that thread. Phew, mystery solved!
  4. Thanks Rolf, that sounds quite plausible. AQ this is a brand new CPU with a Ryzen 3600 in it. I would consider changing the CPU if NI could give some guidance on what to change it to. Is there any sort of hot fix or patch I can try? For now I am out of trouble as I have rewritten the VIs that I needed to use from that library (mine were really simple) , but I doubt others will be so lucky.
  5. Same MD5 as yours. @Aristos Queue this is a fresh installation of 2019 SP1 64-bit installed using the offline installer. I think that DLL calls into other DLLS (like BLASPACK or something like that), but I am not sure.
  6. @Aristos Queue I have the PC back in my possession and have run the VI you asked. Here is the result. Now, if I immediately try and drop Mean.vi I can see it is trying to load it from the correct directory But if I do into the VI and open the Call Library Function node I get the e:\builds\penguin stuff The directory on disk is correct: Does this make any sense to you?
  7. AQ, this was a brand new PC. I personally installed the most recent version of Win10 Pro. I then installed LV2019 64-bit SP1 using the offline ISOs from ni.com. No fancy patches or special versions. Then I open LabVIEW, start a new VI and drop down the Mean.vi and it is broken with the error as I have described. Several other VIs that link to analys.dll are also broken in the same way (I looked at some of the Cartesian shift VIs)! I tried this same experiment on the same PC using LabVIEW 2019 32-bit SP1 and the problem did not exist.
  8. It is broken in the editor! That is how I know about the e:\penguin directory, I am opening the VI directly in the LabVIEW IDE and having a look at the DLL configuration. Unfortunately the offending PC is now at a customer site, as soon as I get access to it again I will try your experiments. Thanks for your help, I would really love to get to the bottom of this.
  9. Absolutely. This is what I have had to do to get things working. Unfortunately this is not the only VI I used that calls into this DLL and this is definitely a game of whack-the-mole I don't have the energy to play. The problem is more... "why does this happen?". I am sure you know how frustrating it is when something works perfectly in the IDE but then has trouble in an executable. I thought I was at the point in my LabVIEW journey that I had experienced first-hand most of the weirdness that sometimes comes with the territory. This is altogether a new one for me though.
  10. Thanks, this is exactly the same problem I am getting! I have no solution yet and have tried everything I can think of apart from not using those functions which seems like a terrible idea.
  11. Installed LV2019 32-bit SP1 and it works fine, so this looks like something weird in 64-bit
  12. So this just gets weirder! Reinstalled the OS and the basic 2019 64-bit SP1 RTE. Still get the error. Installed 2019 64-bit SP1 IDE, open a new VI and try and drop down Mean.vi and it gives me an error message saying A Dynamic Link Library Initialisation Failed! So after a bit of poking around I dig into the Mean.vi and take a look at the DLL and it is configured to have the path e:\builds\penguin\labview\branches\2019\dev\dist64\resource\lvanalys.* Obviously this will not work as I dont have an E: or builds\penguin directory!
  13. Just did the same test with LV2019 32-bit and it works fine on the other PC. 🥵 Also works fine in a VM so I guess its probably something borked on the PC. Time to reinstall the OS (as obviously NI Package manager refuses to cooperate and now I have a bunch of orphaned software).
  14. Seems there is a modern version of Dependency Walker called Dependencies, see it here: https://github.com/lucasg/Dependencies Running this does not show any problems with my DLL and if I hover over the BLASPACK DLL it gives me a popup confirming my suspicion that it is delay loaded. So weird...
×
×
  • Create New...

Important Information

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