Search the Community

I have a large project with many libraries which I am trying to release as a Source Distribution. I am regularly releasing standalone executables of that project without a hitch. However, the source distribution, once I open the top level VI in a copy of the project I place in the source distribution folder, after updating all paths to the new destination, ends up with many broken VIs. Examining the source of the problem, it appears that it is due to many (if not all) VIMs in my project being replaced by VIs with made-up names (random series of characters.vi), and the Assert Type VIMs in those VIs being themselves replaced by similarly randomly named VIs, and broken. I recall having read threads about some sort of incompatibility between VIMs and libraries, but since I did not have any problems with them during development (or application release), I am kind of at a loss as to what to do next... Is there some literature I can read on the dos and don'ts of Source Distribution release and VIMs + libraries? LabVIEW 2021 SP1 64 bits on Windows 10.

Hi, This is not specifically LabVIEW related: How do you organize important posts you read and want to save for the time of need? For example, I want to save an interesting post from Lavag/NI Forums or any other LV blog. This post might contain VIs and I would like to tag it in a way that will let me find it when it becomes relevant. I would like such a post to be saved locally like an RSS so that I'll get the new comments and won't depend on the site to keep the links alive. I see the veterans here keep track of all the new posts and even offer solutions by giving links to some old posts without having to search for them sometimes. Do I miss something? How do you organize it all? I hope to hear of some cool little RSS app that will let me search through the tagged vis and posts stored on my computer and not about some bookmark manager. Thanks in advance.

I am running calls to a various stored procedures in parallel, each with their own connection refnums. A few of these calls can take a while to execute from time to time. In critical parts of my application I would like the Cmd Execute.vi to be reentrant. Generally I handle this by making a copy of the NI library and namespacing my own version. I can then make a reentrant copy of the VI I need and save it in my own library, then commit it in version control so everyone working on the project has it. But the library is password protected so even a copy of it keeps it locked. I can't do a save as on the VIs that I need and make a reentrant copy, nor can I add any new VIs to the library. Does anyone have any suggestions? I have resorted to taking NIs library, including it inside my own library, then basically rewriting the VIs I need by copying the contents from the block diagram of the VI I want to "save as" and pasting them in another VI.

Hello, this is not strictly VI Scripting related but I believe it's a pretty similar topic, so I hope this fits in with the discussion on this board. I am attempting to write a script that parses through the contents of a very large LabVIEW project (thousands of files) recursively and selectively moves/renames some of the files. The basics of this are fairly simple, however I have thus far been unable to come up with a way of moving files on disk that handles all relinking and dependencies without any issues. At a high-level, my question is whether or not the "Move on Disk..." option in the right-click menu of the project explorer "Files" view is accessible programmatically somehow, using invoke nodes. The option I'm talking about, for clarification, is this one: Using this option in the project explorer seems to be able to move all types of files in the project (VIs, libraries, classes, etc.) and handle all relinking properly without any conflicts popping up. However, there doesn't seem to be an equivalent "Move on Disk" method int he invoke node for project items. I have had some success with some of the "super secret" nodes for VIs: However this only works for VIs and there is no equivalent function for library (.lvlib) and class (.lvclass) files. I've tried various combinations of saving and relinking functions that are available, however I always end up with conflicts when I load the project after running my script. If the "Move on Disk..." function is not accessible programmatically, does anyone know of another way to programmatically move/rename library and class files on disk without causing conflicts? Thanks, Ethan

Hello to all. Thanks a lot for reading this post and being able to help. I would like to know what is the most recent release of modbus library for Labview. Which version? 1.1.5.39 of this link http://forums.ni.com/t5/NI-Labs-Toolkits/LabVIEW-Modbus-API/ta-p/3524019 or 1.2.1 of this link http://www.ni.com/example/29756/en/ ? Thanks a lot!

Some background: I'm trying to use the name of the library my VI is executing in as part of a string which will be used in the name of a Rendezvous, to keep it distinct from other Rendezvous I will create. When attempting to use the VI Property Node to access the Library property on the CompactRIO, error code 1 is returned. Running the same code on my computer runs as expected and returns the Library. Accessing the VI Name using the Property Node appears to work no problem on the RT, though. Does anyone know what could be causing the problem? I tried searching the documentation, but didn't turn up anything. Is this error part of some general behavior wherein some VI properties are not accessible when a VI is running on a real-time target? Code is attached. Please see attached pictures: Project Explorer: Block Diagram: Front Panel - RT Results: Front Panel - Computer Results: Experiment with VI Property Node Error.zip

Name: libpq Submitter: SDietrich Submitted: 01 Mar 2014 Category: Database & File IO LabVIEW Version: 2009License Type: Other (included with download) This is a package containing LabVIEW bindings to the client library of the PostgreSQL database server (libpq). The DLL version 9.3.2 and its dependencies are included in the package. This DLLs are taken out of a binary distribution from the Postgres-Website and are thread-safe (e.g. the call to PQisthreadsafe() returns 1). As of the moment the DLLs are 32bit only. The VIs are saved in LabVIEW 2009. So this package works out of the box if you have a 32bit LabVIEW 2009 or higher on any supported Windows operating system. Because this obviously is a derived work from PostgreSQL it is licensed by the PostgreSQL license. A few words regarding the documentation: This package is meant for developers who know how to use the libpq. You have to read and understand the excellent documentation for the library. Nonetheless all VIs contain extracts of that documentation as their help text. What's coming next? - adding support for 64bit - adding support for Linux (anybody out there to volunteer for testing?) - adding support for MAC (anybody out there to volunteer for testing?) Click here to download this file

Hi, I am having trouble where Labview does not detect the required "edk.dll" file (as missing) eventhought it is in the same VI directory. Any help is appreciated attached are the images labviewsystemerror.png shows the error stated. labviewsystemerror2.png show the labview library explore (edk.all not detected) labviewsystemerror3.png show the edk.dll is in the same folder as the LabviewEmotiv.dll

I've been bashing my head against the proverbial wall for a couple of days now trying to understand what was corrupt in my LV project hierarchy. On the face of it, all appeared to be fine, but I was getting some very unusual errors when executing my VIs. Errors that hadn't occurred before I rearranged stuff. In my project I have a number of classes, with various inheritances and other defined relationships, and I recently moved some things around to make it, well, better organised. I ensured I didn't destroy the relationships required to maintain access to class methods etc. Indeed, after the rearrangement, there were no broken VIs, and a mass compile (for good measure) came back clean. Now, although the majority of my classes were working fine, I had a very bizarre "Out of Memory" error occurring when accessing the private data of one particular class's DVR via an in-place structure. The private data of the class is nothing more than an array of a cluster of elements. Typically the array is empty, and in the in-place structure I am combining the contents of one class's array of elements into another's. And indeed, in the above error case I had two empty classes, so the build array function had no real work to do, yet I saw some very odd behaviour. Firstly, when highlight execution was on, the array datawire from the unbundle terminal of the in-place element structure should show "#0" to indicate no elements in the array, but in fact would regularly show #84 for one, and I would never get to see the other due to the "Out of memory" error. This was very repeatable, even after rebooting my computer. Where was it getting 84 elements from!? In a generic probe place on the class itself I would see that although the class wires showed normal content (zero elements in their private data), their Value field showed an incorrect namespace entry. This class is owned by a single library, so the namespaced title is mylibrary.lvlib:myclass.lvclass. However, the probe's namespaced title was mylibrary.lvlib:sublibrary.lvlib:myclass.lvclass, where sublibrary.lvlib is a library definition that I emptied and removed a few days ago. Yes, the class used to belong inside this library, but no more. In the library project view, the class can be confirmed to live directly within mylibrary.lvlib only. sublibrary.lvlib isn't even on the file structure anymore, it's literally gone - yet LabVIEW didn't seem to recognise this conflict. After seeing this I realised there was a corruption, but I couldn't see how to properly inspect the defined class ownership properties, or influence it? There's nothing under the Properties panel accessible from the right-click menu? I wondered if dragging the class out of mylibrary.lvlib and back in again would help, but it is changing these ownerships that caused this mess in the first place, so I decided to close down LabVIEW and overwrite the myclass.lvclass file on disk with a backup from earlier that pre-dated the original move into sublibrary.lvlib. Voila, this solved my issue immediately. So I'm quite perturbed to see that a bad ownership property in a class can cause LabVIEW to keel over with very odd execution behaviour, yet otherwise believe everything is fine in the hierarchy itself. Is there a way to inspect class ownership properties throughout a project to look for inconsistencies? To validate the information already there? I already tried a mass compile and that didn't resolve it. Now, I actually want it, and some other classes, in sublibrary.lvlib, contained within mylibrary.lvlib, but I've been trying for two days to recover my project after trying this once. I wonder now if I even dare try to rearrange my classes again!

I have been seeing some weird behavior and was wondering if this is a known issue or if I have discovered something new. I have two projects that share several libraries and classes. One is a client application and one is a server. In order to test my code, I need to open both projects at the same time and run the main VIs. When I open the projects, the common libraries and classes are locked and I cannot edit them. So far, this appears to be normal. Where it gets strange is when I close one of the projects. If I have run the VIs to test something and then stopped them, closing the owning project of one of the main VIs DOES NOT cause the VI to also close. The correct project name is still indicated in the VIs window (lower left) and the project is clearly closed but the VI is still hanging around. The second thing that is weird is the common libraries and classes remain locked. Even closing the other project and returning the to the start-up screen does not correct this. The only way to edit those files again is to close LV completely and then reopen it. This is getting a bit tiring and I am just starting to develop this project. I am working with LV2012f3 but have not yet tested this in the 2013 beta. (I really do not want to port the whole project over at this time). Any thoughts? Anyone else seen this? I checked the known issues link and did not see anything related. http://www.ni.com/white-paper/13993/en thanks, -John