LabVIEW Idea Exchange

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

whenever a change of .NET dll is introduced, LabVIEW kept wanting to use the old dll. The change in a 3rd Party dll caused a full blown LV crash... 

 

A simple Uninstall of the entry in C:\Windows\assembly did the trick.

 

This was not mentioned in the following:

https://decibel.ni.com/content/docs/DOC-5921

http://zone.ni.com/reference/en-XX/help/371361J-01/lvdialog/assemblies_in_memory/ (only talks about runtime, which is helpful when creating the distribution)

 

 

 

This is not obvious nor an easy to find solution. An ability to pick and choose within LV the required dll (and version) would be helpful.

Formula node is a great tool for evaluating mathematical formulas and expressions. However right now, you can one time input text into the formula node (during application development) and after compilation, the node does only this one added text and any change would mean a recompilation of the code. It would be absolutely fantastic to dynamically load the node text for example from some file…the node would then have not only a variable input, but also one text input, and the text would bet the formula node text.

It would then be a upgraded sort of a „eval formula node.vi“, which would accept also syntax for while loops, for loops and all the other stuff and not only a regular expression.

Creation of a VBScript Node, similar to the MathScript Node, allowing to run a VBScript.

Just like LabVIEW 2009 introduced Custom User Hooks for Data Member Access and Override VI LVOOP templates....

 

I would like Custom User Hooks for Dynamic Dispatch and Static Dispatch LVOOP templates as well.

Message Edited by jg-code on 11-26-2009 02:26 AM

When working with large projects with many VIs I often find myself rewriting portions of the 'find and replace' feature that already exists as part of my VI Analzyer for overnight code-checks on the server...

 

It would be really neat if the existing find and replace logic available via the dialog was wrapped up into some simple API to allow for searching:

  • for full/partial matching text
  • VI path to subroutine...

 

if it had parameters to suppress dialog popups for passwords & not-found-subVIs, that would be really helpful for running searches headlessly.

 

The API could return just a 1D array of paths to SubVI's where instances were found, or if it was really nice, the VI references?    I'd be content if just the 'find' side of the equation was implemented..I could take any manipulations from there.  I can see that there might be a dependency on VI Scripting to accomplish the search, and I'd be OK with an API that only works on a machine with a dev license... Especially if the 'replace' side of things was implemented somehow...

 

-E

 

 

Not so much a new idea as a request to maintain current functionality. LV2010 does not support importing of LabWindows/CVI function panel drivers, can we have it back ASAP please!

 

For more info see:

http://lumen.ni.com/nicif/us/gb_infolvinstdriver/content.xhtml

http://zone.ni.com/devzone/cda/tut/p/id/3164

 

 

Kevin Snelling

(CVI Certified, CLAD, Alliance Member)

I did a search on this forum to see if the subject been asked before but couldn't find it quickly, so I post. I have been seeing business push and pressure to move in this direction over the years, more so recently and have migrated to eclipse for my current project and like CDT. I saw the following today and it got me off my inertia to ask/feel the question here. I would venture that Operating systems and other mature s/w tools aren't rocket science anymore, but commodities and open-source w/ customization makes sense. Easier said that done. Thoughts?

 

pavan

 

This inspired me to ask the question:  The Eclipse Helios simultaneous release of 39 Eclipse projects and 33 million lines of code showcases the diversity and innovation going on inside the Eclipse ecosystem. In terms of statistics, the Helios release includes 33 million lines of code developed by about 500 Eclipse.org committers from 44 companies. The important thing to remember about Helios and Eclipse simultaneous releases in general is that even though it's a simultaneous release, it doesn't mean these projects are unified. Each project is a separate open source project within Eclipse.org, operating with its own project leadership, its own committers and its own development plan. The simultaneous-release concept is designed to provide a transparent and predictable development cycle.

 

Other ref:

Microsoft ups the ante in the robotics market, makes MSRDS free ... (see coments from emiliekopp)

CentOS, Ubuntu...

Eclipse & addons

Python

GCC

Octave

Scilab

Android (I think it is open?)

Open-office

ISO formats for docs

Open Car

Open prosthetics

...

The list goes on.

I have LabVIEW Classes of the same name in two separate LabVIEW Project Libraries (e.g. for namespacing reasons) in the same LabVIEW Project.
When I go to configure the Inheritance of the a Class, the All Class In Project list just shows the Class names.
These names can be the same and it is not immediately obvious which Class is the correct one.
The only way to pick the correct Class is by looking at the Selected Class Path on the right.

 

demo.png

 

My idea is that the All Class In Project list will display the qualified names.

Either as one long name or nested, mimicking the LabVIEW Project hierarchy. 

(I think I currently prefer nested). 

 

Please implement a way to generate reports in ODF (native format of OpenOffice) as it is a file format everybody can read (.doc is not because you must buy Microsoft software).

 

 

If you do that, programmers will automatically be able to generate PDF because OpenOffice has a dos command to convert any ODF document to PDF.

I wouldn't call it common knowledge, but it's certainly not unknown that there are LabVIEW callback VIs that are invoked if present when certain development environment events happen. With the growing prominance of scripting and the increasing ability to develop custom tools to inhance development, I suggest a more flexible approach to these callbacks. Right now, if you want to use these VIs you have to be careful that you don't overwrite the existing VI (if there is one), or you have to manually go into the VI and drop your subVI that you want to run, within the specific callback VI. It would be nice if there was some tool within LabVIEW that allowed you to select the VIs you would like to run on certain LV Development Environment events, and then the paths to those VIs would be fed into the callback function VI to be called dynamically. While us developers could create something like this on our own, a standardized template for a more flexible callback would be nice. This would ensure the developer could create VIs to, say, run on LabVIEW startup but never have to muck with the actual lv_init.vi VI, worry about what's already in the VI and overwriting it, etc. They would just have to configure another path to a VI for the lv_init VI to call. If anyone has a more flexible idea, please feel free to add to this.

 

Easy printing the test reports with the Front panel as per the A4 Standard.

For making the A4 Standard printing needs the option to make Pane A4 Size.

Then we can make easily create the front panel reports easy manner, add Indicator (result ,title, logo, auto signatures etc)  in the report and generate the print out.

Pane sizing to A4 Sheet.png

Download All

Hi,

 

I've recently been handed the task to reevaluate our NI licensing needs.  We're currently using a DevSuite setup, with some add on modules and sourcing wants me to evaluate a setup with Labview Professional and the associated add on modules.

 

Now I have a large code base to check and it would be good if there were a tool which would automatically tell me which add-on modules are used in a specific project.  It could be a menu selection in the tools menu called "List Used Add-On Modules" that checks the project for vi's from add-on modules and lists these.

 

Br,


Albert Lederer

Would like to target Labview embedded on a host of platforms. Specifically x86, lynuxworks, Vxworks and xilinx platforms - boards, SBCs, COMs, stacks, PC/104... Like PXI, the way to get the users onboard is to show that the industry supports this direction and you are not tied to one vendor. It would be expensive if in an iterative learning process (necessary but collaboration is also necessary with well established & matured platforms/standards) the users one chosen platform vanishes (maybe like fieldpoint?). Packaging options is also very important to achieve something like Adlink's MilSystem 800 that the application demands.

 

Pavan Bathla

It's not secret that .NET or ActiveX object on front panel appears to be child window of NI container clipping window, which itself is a child of front panel window. When there's only one object in the container on FP, it is easy to get its window handle (HWND) by calling GetTopWindow or simply by iterating through all child windows of FP. This handle has to-one correspondence with automation refnum on block diagram. But when there are several .NET/ActiveX objects on the panel, it's impossible to identify their handles with refnums on BD.

 

The way of handle obtainment could be implemented by any of the following methods:

 

1.

Autorefnum To HWND.vi

 

2.

 Window Handle Property

(or let it be private property, being activated with special *.ini key)

 

3.

MgErr AutoRefNumToHWND(refNum, hwndp); - this variant is analogue of LabVIEW Manager function FRefNumToFD, where refNum is automation refnum of .NET/ActiveX object (type LVRefNum) and hwndp is pointer to child window handle (type HWND *).

 

Probably many people may consider this idea unimportant, but when it comes to drawing different shapes, displaying text, copying window content etc., my suggestion may be very relevant.

My customer is using LabVIEW 2009 with SIT, MATLAB R2007B and he was able to transfer more than 97 elements of array data with his Simulink .mdl file with the following configuration:

- Configuration parameter of MATLAB model: solve complete time: inf, type: fixed step, solver: discrete, fixed step sample time: 0.01
- Default LabVIEW array reading rate defined by auto generated VI: 50ms >> changed to 5ms
- Executed in Windows local host

However, when the .mdl file is converted to DLL, it seems as though that an array size of over 97 cannot be transferred.

The issue seems to be able to be produced even with multiple arrays or multiple scalar controls so I believe it seems to be an issue of how much data it can handle and not a data type issue. As I mentioned previously, data is able to be passed up till a certain amount but after this "threshold", data does not seem to be passed and the default value of 0 is displayed on the indicator. (In an array, the specific array size is initialized but after the threshold, 0s are shown)

 

I was also able to reproduce the issue on my end with the attached files.

Download All

There are methods available to covert from .sif files commonly used with InField to .tdm or .tdms but not the other way around.  It has been suggested by customers to provide a method for this conversion.  

Hello, community


Since some years I'm using LabVIEW now (currently 2010). I'm working in the automation business branch and I see, that there are many HMI visualization softwares around. Nearly all of then support the inclusion of ActiveX plugins into the HMI surface. We are using LabVIEW, among other software, to control our machines. The HMI software we have to use is normally decided by our customers, so not always the same HMI software. Mostly we use Wonderware-InTouch or Siemens-WinCC. Using LabVIEW as HMI host system is not an option, as customers want to stick to their favorite tools and want to be able to manipulate the HMI by themselves. We would like to replace certain parts of our HMI by LabVIEW-VIs.


This can currently be done by

  • Compiling the VIs we want to display as standalone programs with HTML server included.
  • Installing a runtime LV on the HMI-PC (Windows based)
  • Running the VIs
  • Including a WindowsExplorer.ocx into the HMI project and displaying the VIs via Web connection.

This is very sub-optimal because it includes many superfluous things and induces a more than necessary amount of problem-sources.

What I would like to be able to directly build an .ocx file out of our VIs and so include our VIs directly as AvtiveX objects into the HMI (instead of Windows Explorer as wrap around).

What do you thing about an application builder able to produce ".ocx" output?

Regards,
Ralf

Hello, 

I just had a call with a customer that have a problem: 

we cannot install multiple version of drivers to develop applications with different driver versions. 

This problem happens to our partners.

          

Example:   

I have a customer that want to uses LabVIEW 2014 and another one that uses LabVIEW 2017. So I would like to make a project with 2014's dependencies and another project with 2017's dependencies. 

 

So the idea is to manage the dependencies in the project itself.

 

Best regards, 

Antoine

I really like the changes to the Create Data Member Accessor Screen in LV2009 (and LV2010).

 

I like the Place new accessors in this folder logic.

One thing that would be cool to extend on it would be if the screen allows you to set the scope of a new Virtual Folder at the same time.

 

21684iC82E6A87291349BB

 

This would save time as you would not have to right click and set the scope of the new Virtual Folder from the Project Window the first time it the Virtual Folder is created.

If the Virtual Folder already exists in the Class then this option should be grayed out and disabled.

The operating system takes a long time to open an application when you need to open many file, if we group files in larger files, the times are reduced. With LabVIEW we can create libraries ".llb" is a really funky zipfile, but it is a file that was introduced to provide functionality in the past.

 

Like Java uses the ".jar" to create packages and distribute the code more easily. They are built on the ZIP format and typically have a ".jar" file extension; LabVIEW uses the ".vip" to create packages with VIPM. VI Packages are similar to zip files in that they contain all the VIs and resources for a specific LabVIEW add-on. But ".vip", are not recognized by LabVIEW in the project tree, instead ".llb" files, we can access its contents from the project tree of LabVIEW.

 

Zip Format 1.png

  

From a labview project, we can build a ".zip" file. (Build Specifications>New>Zip File). But if we enclose the project in the .zip file, it does not show us the content tree.

 

  

Zip Format 3.png

 

My proposal is that LabVIEW can recognize the contents of the ".zip" files, as well as the ".vip", to be able to access its contents and be able to use the lvlib, lvlibp, class, vi ... that are contained. In this way, we can use ".vip" files in <vilib> \ *, <urllib> \ * ... and be able to use its contents without needing to unzip it.

 

Zip Format 5.png