LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

We have developed an external DLL that is called from LabVIEW using CLFN. I have noticed a weird behavior regarding DLL detaching (unloading).

Scenario 1
I have 2 VIs calling the DLL. I run them and then close all of them. In this case, the DLL is detached when the last VI is closed.

Scenario 2
However, if I create project containing the same VIs as in scenario 1, when I close all the VIs after running them, the DLL stays loaded until I close the project.

This behaviour does not seem correct. I think LabVIEW should behave the same in both cases.

What do you think?

Sara

 

[admin edit: I changed the idea title per user request. The original title was "DLL shouldn't stay loaded when all the VIs calling it are closed".

My request is very much similar to Rob Hingle's request posted in "Need custom column widths in Append Text Table to Report" thread here:

 

http://forums.ni.com/t5/LabVIEW/Need-custom-column-widths-in-Append-Text-Table-to-Report/td-p/1108404

 

I discovered the above thread while looking for a solution and I got very disappointed that the discussion in that thread did not lead anywhere...

Rob actually said it all; I can only second him here as my problem is basically the same. Nevertheless, I'm putting it out here for reader's convenience.

 

In my practice, I often need to create a LabVIEW standard report (for printing on paper) which would contain, among other things, one or more tables. The tables must have columns of different width. Some columns need to be just a few characters wide, while some other columns have to be quite wide. For example, a table of chemical compounds would contain a Sequential number and a Compound ID, and a few other columns. The first column needs to be three characters wide maximum, while the Compound ID has to be much wider (say, 30 characters wide). There is no way I can use the standard LabVIEW "Append Table To Report.vi", since it sets all the table columns to be of equal width. In the past (LabVIEW 7) I was able to do this by modifying the "Append Table To Report.vi" and its subVIs so that the VI would take an array of column widths instead of a single scalar value. It became quite difficult to achieve since NI reworked the Report Generation Toolkit... I ended up importing and using the old toolkit - now with LabVIEW 2010 and 2011, which is obviously not the best solution.

 

I'm surprised that this issue apparently did not draw more attention so far, since IMHO it's been a glaring deficiency of the Report Generation Toolkit for some time now. Why the Report Generation Toolkit was designed with the assumption that columns in tables can only be of equal width is just beyond my understanding... Generating printed reports with tables is a quite common task, and most of real-world tables have columns of different width - just take a look at a few tables in books, magazines, manuals... A table with columns of equal length is quite a special case of more generic form, and can be easily obtained if needed by specifying the same width for all columns in the table.

 

Please make the "column width" input of the "NI_report.lvclass:Append Table to Report.vi" an array... To provide backwards compatibility, the VI can be made polymorphic (I hope), so that either an array or a scalar could be used.

 

It would be great if you could easily add a license (public domain, GPL, BSD or your own) to a vi. This would be great especially for libraries such as device drivers, etc.

 

I think a good place for this could be File->Vi Properties. There could be a license tab where you either can choose from common pre-defined licenses or have a text entry box where you can add your own. If someone else uses the vi, that person can than easily find out if he can use this VI in for example commercial code.

 

Arun

As part of the base package in the LabVIEW Developer Suite, include an integrated SCC in the IDE. We are using a third party SCC program right now, and it has it's quirks when integrating with LabVIEW. Our group is comfortable with the quirks now, but for a new group starting a new project, the hurdles might be big enough to nix SCC. If a LabVIEW-specific package was maintained with the IDE, those quirks could be reconciled for the LabVIEW-specific style (i.e., a file is "modified" when compiled, diffing two VI's, ...)

 

NI has been really promoting SCC recently, and I think they should officially develop (or adopt) an integrated package with the LabVIEW IDE.

LabVIEW contains a mechanism for storing custom metadata of any type inside of VI files as "tags" (e.g. the path of an Express Source VI's associated config dialog VI) but the methods for manipulating them are marked as private. I think this could be a useful thing to have as an officially-supported feature.

Direct to PDF reporting is an extremely important feature to provide customers.  It cannot be relied upon that the customer has MS Word or the like installed.

There are a couple of LV PDF toolkits supplied by developers.  However, the problems with these include that they are (a) not updated or well-supported (b) buggy (c) have out-dated dependencies such as .Net 2.0 (d) restrictive licencing for deployment.

Good reporting tools are essential and NI should develop and support a direct to PDF toolkit.

If NI were to make the following modification to the Word_Save_Document vi, we would be able to generate PDF documents directly out of the Report Generation Toolkit. This may only be applicable to later versions of Word.

 

What is required is to handle the PDF file extension and set the appropriate wdSaveFormat value for the SaveAs Method. It would also be nice to be able control the show PDF after generation option, but just being able to save as PDF would be very useful.

 

 

VI modification

Ok this idea would be trivial for NI to include in 2011.Heck I could do it.

 

The idea is simply to include the JKI state machine in File/New/Design Patterns. It is BSD code and I am sure that JKI wouldn't mind anyway.

 

I must admit that I have an ulterior motive. If this were included in the NI distributed templates then I could use the JKI state machine for my CLD exam. And so could you!

 

Now let the kudos start rolling in so NI will take notice.

Support LabVIEW-UML integration.  Integration means supporting code generation from models and reverse engineering to models.  The UML tool must support the latest UML specification from OMG.  (This includes the specifications for interoperability.)

 

Other considerations when selecting a UML tool should include:

UML features and ease of use of the tool.

Support of SysML.

Integration with version control.

Additional features of the tool.

Cost of a license.

Size of user base.

 

When I want to insert a line of text in the Enhanced Icon Editor of an existing VI it usually means I have to overwrite my existing text or cut and paste it.

 

I.e. If I simply want to go from this:

 

21203i5E96ED314B36205F

 

To this:

 

21205i0BA9C1C27BE039D4

 

It's not that easy and it could be much quicker.

 

I would like to be able to Right Click (or a similar method) on the Lines Cluster and select "Insert". 

This would insert a blank line and move the Line Text and Line Colors accordingly, preserving existing settings thus allowing me to easily edit the above icon's Lines quickly and easily.

 

As software versioning becomes more and more popular also the automatic building of source code becomes more and more interesting.

 

Right now in our company we are using GIT and JENKINS for C-code material as our versioning and automatic build tool. As soon there is something being checked in and pushed to the main repository the builder gets notified and tries to build your source code having the output available somewhere.

 

As we are having many users around the globe these tools obviously run on a virtual machine or server somewhere.

 

Right now there is no option in buying the application builder seperatley and control it via command line. The only option is to put a complete development environment on there which is useless and a waste of money.

 

My request would be to sell the application builder seperatley for these purposes OR figure out an alternative way for doing this in a professional and neat way.

 

some usefull links:

http://jenkins-ci.org/

http://git-scm.com/

When you hit build, you can't edit code. Build takes a while, sometime hours. 

 

We would like to separate the compile process and free the editor, or target another pc/ip to offload compilation.

 

I would like a right-click option where a folder of packed libraries waiting to be compiled are queued and scheduled e.g 6pm or weekends and Labview is open. 

 

My colleague Bosko G has something on the latter (attached) and came up with the request. I am sure others have thought about something similar but I couldn't find a post addressing it directly. To be clear, the request isn't for a 3rd party cloud farm alone but also something we can setup on intranet PCs/Servers.

 

Thanks. 

 

Pavan 

Title pretty much says it all.  It would be a fine companion for the proposed Noncommercial Hobby/Home license for LabVIEW.

So I've recently discovered Darren's original post regarding the App Builder API (http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-02-15-2010/td-p/1072575) and used it to fully automate my build process.  I can't tell you how much time this saves me!  I work primarily on a good sized app that depends on an ever shifting array of plugins and 3rd party installers, and having the ability to programmatically add or remove them from a build is a lifesaver.  But because the API doesn't extend to the installer, I still have to do that last part by hand.  I'd really like to see an installer API that would allow me to add build specs to an installer on the fly.  It would be especially handy to have the ability to add other files, specify their location, and (if they are executables) set them to run them following the install. 

 

Thanks,

JasonP

 

  • I like to make plugin tools that work on items in the project e.g. Libraries/Classes.
  • I like implementing these plugins using the Quick Drop plugin framework.
  • And I normally always work with the LabVIEW Project in my standard workflow. 

 

 

If I want to act on a Library, obviously I can just open a Member VI and get a reference to the Parent Library to do this.

However, I feel it would be more natural to Quick Drop on the Library in the Project itself!!

I also feel that it would be faster...

...And isn't that what Quick Drop was invented for?

 

I don't know if native options would ever exist, I am looking to call my own shortcuts - but there is alot of scope to implement custom plugins.

I have only given one example above.

 

Cheers

 

-JG 

 

Quick Drop on Project Window.png 

The idea is to decouple the icon editor from LabVIEW so users can create their own. The intention is to make it easier for people to distribute their own icon editors by only having to place code on disk and modifying an ini token.

 

This would mean modifying lv_icon.vi so that it contains nothing but a launcher that would load the new icon editor from a path specified on a LabVIEW INI token.

 

There will be a default plugin that would hold the current icon editor, the path to the default icon editor would be a part of the LabVIEW ini file on LabVIEW install.

 

I created a working prototype that does that here.

 

I want to make sure this idea gets traction before going further with this.

NXG needs an Idea Exchange.  The feedback button is a lame excuse for a replacement.  Why?

 

  • I can't tell if my idea has been suggested before.  (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
  • NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
  • Many ideas start out as unfocused concepts that are honed razor sharp by the community.
  • This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

We were thrilled to see that NI developed an OPC UA API. We develop software for both VxWorks and Windows, so having OPC UA available on RT is great. But having to shell out for the entire DSC suite, run-time licenses and all, just to be able to use the same API on Windows is unreasonably costly and forces us to use a different API on Windows. If we could buy the API as an isolated component at a more reasonable price (and with easier licensing) we would jump for it immediately.

 

A generalized version of the idea:

The DSC can still function as a nice bundle, where the price for the bundle is lower than the total for each individual item, but when NI makes such packages please make it possible to pick-and choose amongst those components as well, so that in cases where you actually have a need for just one of them, you can get it at a price that is reasonable for that individual component.

Can I have a API for the "Profile Performance and Memory " tool Jürgen

This Idea applies to all Libraries but my main Use Case relates to Class Libraries

 

I am not sure how everyone arranges there Classes, from trolling online it seems common that non-publically scoped methods tend to get placed in their own Virtual Folder and public methods are at the top-level. 

 For example:

 

21672i8DF9E7B8B93A8490

 

Unless my Class only has a few methods I would take a similar approach however, most of the time I like to categorize them in more detail. The reason being this is my palette from where I choose my methods, and I like to group them using the following logic so that I can get as much information visually out of the organisation / layout of the Class. I like to have the only top-level method as the constructor if there is one (so I can see that there is one or not for that Class).

I only create the Virtual Folders I need, but usually there are a mix from the follow example:

 

21674iC695C8CF5C268BEE

 

The problem I have with the current design is that I don't know whether I have scoped my public methods correctly, as I could have forgotten and they are still left not specified - which is the default when you create a new Virtual Folder

 

21676iAB6ED5F8E26BA877

 

Currently there is no way to tell the difference from the above two Virtual Folders unless you right click on them or possibly look at the contents.

This is not great as there is potential that I could have scoped things wrong which normally leads to me having to check or recheck the scope is correct.

 

21678iF61DE0BD73C6A4AD

 

As LabVIEW is graphical by nature, it would be much nicer if I could visually see a public scope glyph to differentiate it from a not specified Virtual Folder.

I selected the color green as it is a natural opposite to red (private) and has not been used yet.

For example:

 

21680iDEBCDA19ED6B9DB4

 

Therefore, my original implementation would look like the below, and I can straight away see if I have scoped the public folders correctly.

 

21682iC59F6703EC013513

 

I am sure there was a reason not to include it originally.

I am interested to why and if there is a good reason not to show this too.