LabVIEW Idea Exchange

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

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

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.

Presently LabVIEW and it's toolkits ship with a number examples.  At the same time there is a massive amount of information and examples with content like the examples and the things that are much more.  When I am searching for an example I often can't remember if I saw it on the web or in the examples.  So first I open the Example Finder, a tool that I really like, and search for things there.  Then if I don't find what I am looking for there I open up a web browser and search the NI Communities, then the NI forums and other forums (like LAVAG.org).  It would be nice that instead of having to use to programs the Example Finder could give a list of possibly related items on the NI forums.  I think this could be managed using the existing tagging feature of the forums with perhaps by having an #example_code tag.  A crawler program could then parse though the tags and grab the links to pages of possible matches populating a database.  Then this database could be access by the Example Finder for related info.

 

Another option would be for me to be able to find a link I like and attach it to my example finder or perhaps to my NI.com community account.  That would be useful.  

 

Actuallly, if there was an API for example finder that'd work too.

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

The current implementation of the integrated SCC options have an option to exclude (or ignore) vi.lib and instr.lib files.

Mysterically user.lib cannot be excluded!

This ought to be fixed.

 

Ton

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

 

Hi,

 

what does the community think about configurable automatic type conversion between .NET and LabVIEW? We need to deal with a .NET API for a sensor which handles system time with nanoseconds since the 16th century. Don't know why they're doing this stuff.

 

To set the appropriate time you have to substract two .NET DateTimes. Everybody will know this will look like in LabVIEW.

 

TS01

 

You will have to use a method of the object to substract this. Now you're using DateTime.Substract. This means in LabVIEW.

 

TS02

 

Here it would be nice to have a checkable item in the right-click run-time menu for the invoke / property node to select or deselect the automatic type conversion so that the Substract() method would accept a DateTime class and not a LabVIEW timestamp.

 

TS03

Hope the idea is clear enough. I've checked the idea forum for this entry but didn't found it. If so, don't shoot me for a double post.

 

Tyler.

When using dll's or .Net assemblies, you always have to right click & hunt down which version gets used for the constructor.

It'd be handy to have the version shown in the Help. I already know it's a constructor node, that's not much help...

It would be nice to improve documentation created by Tools->Import->Web Service... wizard.

Especially, I suggest to automatically create Description in created .lvlib Documentation so that it would be immediately clear which WSDL URL is handled by that library. Currently, WSDL URL is only placed as a String constant in Open Web Service.vi which is not really convenient.
Thanks for understanding and support.

I would prefer better and much more error messages in the DLL import assistant.

- I had a unknown data type of I64 as "long long". But LabView only knows "__int64".

 

The only message was "could not import function xxx"

I prefer the line of header file, there the import stopps. Two days of searching, and only small hints from the NI support...

 

Peter

Property nodes for LVClasses are a tease, this is what I really want:

 

Invoke nodes that correctly wire call dynamic dispatch by value VIs (this includes the ugly wireing of the "preserve runtime class" inside the in place element structure.  Its ugly, just obfuscate it for me.

 

References to Data value references that correctly respond can use the "to more generic" and "to more specific" class so that I have the DVR to the more specific.generic class REFERENCE.

 

Justification for Invoke nodes:

I work with lots of different Classes, and libraries.  I can quick drop alot, but I do not know all the publicly exposed functions in a give class especially since 90% of the time it is still in development.  Generally a pallete won't see the light of day in internal development (somewhat of a pain to make/maintain, definately not a single click operation), so getting the correct methods involves paging back and forth between the project explorer, this is slow.  I want to code quickly, if I can have the Public api exposed by an invoke node it means I dont' ever have to make a pallete of VIs (we can argue over this all you want, it just isn't simple/fast enough)  and I can access the functions much more easily/quickly.  Even if every class had a pallete, it would still be inferior to the invoke node solution because A.) I have to remember where every pallete is. B.) Sharing/installing pallete changes for other developers is PAINFUL.  I want to give them a zip file that they can chuck anywhere.  I sure do not want to make a scripting function to update there palletes, so it requires file moving/installation/making sure they actually put the class in the right folder (which someone will always do wrong and invariable cause me to right arrow enter 1000 times when I receive their project.)

 

 

My tools are technical facing, and I use math.  Instead of ASCII only, a "markdown friendly" version of MathJax, something that allowed me to write clean equations, would be useful.

 

instead of writing

     "sin(x^2) e1 +cosh(1/x) e2"

 

I could enter the text

 "$sin\left(x^2\right)\hat{e}_1 + \cosh \left(\frac{1}{x} \right ) \hat{e}_2$"

which is LaTeX in a wrapper

 

And I would see displayed this:

gif.latex.gif

 

 

LaTeX is deep and wide, developed for decades, nicely licensed, and supported well in academia. 

 

Some linkes:

 

It would be nice if you can define a webpage or email address for bug reporting in a VI or library, that you could set under File->VI Properties before you distribute a library/device driver, etc.

 

If this address is set, labview could automatically add a menu entry "Report Bug/Feature Request" in the Help menu that takes you to a webbrowser or a email client with some preforumlated text, e.g. subject: "[Labview Bug Report] <VI name> <VI version>".

 

This way one wouldn't have to start browsing the web frist to figure out where to report problems.

 

It would also be nice, if one could set this once for a complete project and all VI would inherit this from the project they belong to.

 

regards

 

Arun

 

Labview should support inserting a LabView plot object in microsoft powerpoint to allow access to the data and plot features like enable disable in plots that have been shared via powerpoint. Many other applications support embedding their objects in powerpoint.

LabVIEW has shipped with an Express VI which supports the ASCII LVM format since version 7.0.  However, there is no other way to access LVM files from LabVIEW, short of burrowing into the Express VI and using the subVIs.  Doing this leads to problems, since the subVIs have changed a few times.  In addition, the Express VI does not support all the features of LVM and makes accessing multiple data segments somewhat nonintuitive.  We need an API for LVM, ideally object based, so features like the special block can be easily extended by users.

Hello,

 

I work as a LabVIEW integrator and for one of my customer I develop application, with maintenance goal for their installation all over the world with RS232 or Bluetooth communication for example, deployed on targets as PDA (PocketPC 2003 & Windows Mobile 6) or Touch Panel (Windows CE 4.2 to 5.0) using LabVIEW 8.6 Mobile Module.

This LabVIEW additonal module works quite well to deploy the same application in this differant targets, but I encountered some problems and I have some suggestions for Mobile Module :

 

1/ MMI (Man Machine Interface)

      -  for graphics indicators (as Gauge or Slide) graphical object ramp or multi Slider is deleted by LabVIEW when you build an EXE => I think that a graphical objets with all its graphical property could be added in Mobile Module (and works on these all targets). See examples in GraphicalObjects.PNG

      - as I say in my introduction my application is deployed all over the world and usually I used "Caption" dynamic modification for multilingual management for all my controls & indicators. But in mobile module we can't do this (but we can modify dynamically boolean text), so I think that it could be possible.

 

2/ VISA (& Bluetooth) Management

      -  I think there is a bug with VISA installation. Indeed with the installer you can choose the installation directory (default directory or specific directory : in non volatil memory) but if you don't install VISA support in default directory it doesn't work (with PocketPC 2003 for example) I think that could be resolved

-  As I said in introduction my application could communicate throught different protocols (RS232, Bluetooth) and with LV 8.6 Mobile Module we can now use VISA : great !!!. But in Windows Mobile 6, VISA does not support bluetooth (it seems to have an incompatibility with virtual aliases in the registry) ; and in PocketPC2003 it works very well. I think that could be resolved