Neil Pate

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

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

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?

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

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?

Yes that's the one!

Just when you think you know everything there is to know about a language (😉) somebody comes and shows you otherwise 😲

Anybody got anything older than this video about LabVIEW 5.0?

You are not alone Cat. I got a similar error and after battling with NIPM for a weeks or so gave up and just used a different computer. I was getting a similar error message which is totally nuts as it was also for the offline installer.

Yes this is bad news indeed. The forum channel is full of angry customers. For what it's worth I have managed to import several repositories from Bitbucket into github using the github import, but it failed for me when I had 2FA turned on in Bitbucket.

I don't actually need the large memory support at this point, but feel it is getting close to calling time on 32 bit applications. I have been dabbling with LV2019 64 and so far it does what I need but admittedly I have not needed to interface with any hardware yet apart from a GigE camera.

@Rolf Kalbermatter my brain was clearly running badly when I typed that we needed LV2018, what I actually meant to say was the 64 bit LV was required. 🤐 I say this as it is my understanding the Tensorflow DLL is strictly 64 bit. Do you suppose it would be possible to use 32 bit LV if going via the Python route?

Thanks JKSH I echo your sentiment. Versioning is always going to be a problem, but just recnelty Tensorflow hit 2.0 so that was what I was planning on supporting as the minimum version. Going down the python route is also interesting but a bit fraught. Probably due to my inexperience with python and it's tool chain I spent the better part of a month just trying to follow myriad tutorials online to get python and tensorflow working properly on my PC, with very little to show for my results. I do think it would be reasonable to say that a toolkit such as this requires LV 2018 or greater.

Although my intended application is vision based I suppose in principle a Tensorflow Toolkit should support other types of ML applications. As I said I don't really know enough about tensorflow to know how big an undertaking it would be to create a wrapper for the whole DLL.

Hi everyone, I have recently been playing around with the Tensorflow support built into the Vision Development Module. It seems to work fine and I have the basics up and running. There are a couple of problems though that I would like to solve. Firstly, it seems to not use GPU acceleration at all which mostly makes it useless for real time processing at any sensible frame rate. Secondly, it is locked into the VDM which is not cheap and also totally closed source. Under the hood the regular Tensorflow DLLs are called, but via a layer of the Vision toolkit. Third, for this closed source reason we are locked into whey ever version of Tensorflow NI chooses. I totally get that from their business point of view, but conversely I suspect that there is very little push inside NI to update this regularly due to all the hurdles that come with it. My proposal is to implement some kind of community edition of Tensorflow API that wraps the Tensorflow DLL directly in LabVIEW and exposes hardware acceleration capabilities. Anybody interested in collaboration? I know a little bit about Tensorflow, but not enough to be productive, so my first step would just be to mimic the API provided by NI which is deliberately quite simple.