Neil Pate

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.

14 hours ago, Aristos Queue said:

.Heck, the VI would be broken in the editor!

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.

On 2/28/2020 at 8:53 PM, Michael Aivaliotis said:

Can't you just add the numbers and divide?

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. 

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. 

Installed LV2019 32-bit SP1 and it works fine, so this looks like something weird in 64-bit

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!

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

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

Tried Dependency Walker (which I cannot say I really totally understand) and it looks like it is looking for LV18000_BLASLAPACK.DLL which I have located and tried copying to the directory holding the analys.dll, still no luck. I don't know what the hourglass next to this DLL is, maybe it means lazy-loaded?

I am pulling my hair out over this one...I am trying to run a LV2019 64-bit application as an executable on another PC. I have done all the normal things I do like install the runtime engine etc, but as soon as any of my code contains any VI which calls into lvanlys.dll I get the following error. 

This is the code:

I have done everything I can think of including re-installing the runtime engine, creating an installer from the build PC, copying all DLLs from the Runtime directory to the application data directory etc, none of this works.

This is just a regular PC, the only thing that is a bit out of the ordinary is that it does not have internet access, but surely this is not the cause? Could it be related to 64-bit?

Anyone else seen this in 2019 64-bit?

Bump to this. Still present in 2019 🤮

Mandatory LabVIEW.ini keys

DragAutoWire=False
LiveDrag=False

12 hours ago, hooovahh said:

Oh yeah, just wire a -1 and you get the whole file.  I always forget that.

Tried that in my original test, still did not work.

2 hours ago, ShaunR said:

I don't have a linux machine handy, right now, but try unchecking the "Convert EOL".

Tried that, no dice. The file read returns an empty string.

The confusing thing is the file read does work, but only if I read it as lines instead of characters. 

This works fine for what I need, just a way of displaying the memory. I am too lazy to convert the string into a number (or rather I don't know if the units are always kB).

Linux RT Memory Usage.vi

Well that is not what I expected!

Any ideas why reading just a pure string did not work?

5 hours ago, Aristos Queue said:

Say what?! Why in the heck is that a thing?! Since I really don’t want to dig into the C++ code to find the answer, does anyone know what it means to interpret a double as a timestamp?

This has been around for years! I think it is number of seconds since the epoch in 1970 or something like that.

29 minutes ago, ensegre said:

spitballing, having never worked on cRIO: standard linux ways like just parsing the output of free wouldn't help? Or reading /proc/meminfo?

Yeah it seems this is the way to go, I was just hoping somebody had done this already 🙄

I have tested both using an SSH console into a cRIO VM and they do seem to work.

As per this KB it is no longer possible to retrieve the memory usage using the System Session property nodes. Considering the Linux implementation is several years old already this seems like quite an oversight but not something NI seems terribly worried about. The solution proposed in the KB seems quite incomplete.

Strangely, NI do have a way to get this info as it is reported in MAX

Does anyone have a solution for this?

You can add text labels to a dial. It does not turn it into an enum but sort of works like you would expect (change the data type to U8).

Not exactly LabVIEW related, but an interesting related read anyway. How Diablo was reverse engineered.

As a lefty, don't even get me started on can openers.

Turns out there is a way to do it from within the IDE without mucking about with copying files etc (100% not obvious though). I stumbled on this totally epic write up/demo by Matthias Baudot. 

https://www.studiobods.com/en/niweek2019-ts170/

Not sure if this is the right place for this, so mods please feel free to move if it is not.

I have just started to play around with the Web Module in NXG 4.0. There are quite a few tutorials around, but (unless I have missed something) all of them seem to gloss over the task of getting a trivially simple web VI actually running locally. After a bit of head scratching I did manage to get something up and running eventually, but have a question which is hopefully simple for anyone who has used the Web Module.

When running the web VI inside the NXG IDE, is there anything actually hosting it? In other words can I visit some address from my web browse to see it running while I am developing it? Or do I have to build (i.e. turn into html and JS) and then copy the files manually to my NI Web Server directory?

23 hours ago, Dataflow_G said:

I assume you meant this video?

There is this older video of Dr. T and Jeff K. introducing a LabVIEW Basics Interactive CD-ROM (~LabVIEW 4), but it's not as exciting as the LabVIEW 5 promo.

 

Yes that's the one!