LabVIEW Idea Exchange

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

LeCroy oscilloscopes do have a decicated area of the user interface for customization. The custom space can be used by an ocx-ActiveDSO PlugIn that is registred on the instrument.

This kind of ActiveX-Control can do far only be built by some VC and VB compilers.

 

It would be very nice to build now such a CustomDSO PlugIn for a LeCroy oscilloscope by LabVIEW.

 

With regards

Peter

 

 

Tameq Schweiz GmbH

+41 56 535 74 29

A version control system is a must these days, but rearranging project files in LabVIEW is a nightmare without integrated support.

 

The correct way to do things is in LabVIEW rather than the file manager to save creating headaches and conflicts in LabVIEW.

The correct way to do things to maintain subversion history and minimise headaches related to subversion is in the file manager using subversion tools (e.g. TortoiseSVN).

 

So without subversion integration, we are damned either way.

 

Please provide a way we can get this support without doubling the cost of all our licenses by upgrading to Professional for this one feature (management will never go for it) . Please consider adding it to cheaper versions, or at least make it available as an optional addon for a reasonable price.

Can we have some report generation that is Microsoft Publisher specific as this would be more useful than word or excel. Or a more generic format that could be used by different publishers. Or a generic print file that is more adaptable to the page size and position on the page. LabVIEW desktop publisher?? This is because the only way to print at the moment is via word or excel or by printing the front panel which can be a bit hit and miss in different versions of Windows.

It would be very useful if we could have same QuickDrop PlugIn with the same shortcut depending of the selection object that we have made in "Block Diagram" or in "Front Panel".

 

For example:

- Imagine "Ctrl+C" short cut, this would be useful for lots of QuickDrops that comes to my mind.

  • Copying to clipboard a bundle by name text.
  • Copying to clipboard a unbundle by name text
  • Copying to clipboard a selected case.
  • etc....

Hi,

 

i have an idea to use for labview for vehicle navigation display on ENC charts. it will be very useful as developing sensor interfacing and acquiring data from navigational sensors (GPS , accelerometer, gyros ) is a lot easier in Labview but then displaying it properly using ENC charts for mapping purpose is still a question mark in Labview.

 

i would like to refer some companies (global mapper etc) which are developing SDK  and activex control for C# etc but no support for labview.

Although there is a manual patch for that I think that it will be nice to include the VI Snippet for chrome users too.

Hi!

 

We are trying to work with an OPC server with some array tags defined. We can access the array tags perfectly.

 

If you request a single value from that OPC server (through an OPC client like Wonderware, Ifix, Control Maestro (Wizcon), WinCC, etc….), the OPC server sends a timestamp with the time in which that value was acquired. I have confirmed that there's no way to request single values from an array tag (neither with DSC, nor with DataSocket).

 

I don't know how hard to develop would this feature be, but I think it would be great.

 

Regards!!

This is a suggestion a bit technical and is posted here following the suggestion of the National Instruments support center. 

 

When building a shared library from a vi, the run time engine make use of a configuration file which has the following name: <name of the executable program which links in the DLL>.ini .

 

The fact that the name of this file is not configurable by the users is EXTREMELY annoying in my application (the LV DLL is a plug-in of third party software) because causes the corruption of the calling program configuration file.

 

It seems very easy to me solving this problem by making user-selectable the name of the ini file used by the DLL produced by LV. It also would improve the interoperability of LV with third party software.

 

I really hope to see this upgrade already in the next release of the software.

 

Thank you very much.

I would like to propose the inclusion of the possible errors to the help menu of each function.

If you are new to LabVIEW or have to work with something you don't know, it would be nice to see all the possible errors, so that you can handle them appropriately. Also it is easy to forget an unusual error or one that is so common that one hardly notices it anymore (e.g. timeout, reading non existent array elements or division by 0).

This information is included in the APIs of other programming languages, e.g. Java, as well and saves a lot of time in searching and testing for an exotic error.

In some cases we may have functions called from DLLs, which cannot be not terminated in "normal" way due to some reasons.

When source code for DLL is available, then this is not a problem, but for third-party DLLs this may be terrible.

 

All what we needed is Timeout for External Code Call.

Let me explain. For example, we have code like this:

 

01.png

when such external code called from VI, then this VI cannot be stopped

 

Suggestion:

 

add Timeout option to the following dialog:

 

timeout-setting.png

 

When enabled, then the following input will be shown:

 

timeout.png

 

And timeout can be programmatically defined on the block-diagram:

 

suggestion.png

by default -1, of course.

 

I fully understand, this is dangerous thing, but in some cases we needed this. Suggested is something like TerminateThread function.

 

Back to the code above, when this code should be terminated, then we needed wrapper something like this:

 

02.png

 

Then this function can be called in separate thread:

 

03.png

 

And now we can terminate execution with TerminateThread function:

 

04.png

Then in LabVIEW it looks something like this:

 

06.png

 

Now we can "Abort" our infinite DLL call without any dialogs like "Resetting VI", etc.

 

Again, this is dangerous feature (but not more dangerous as TerminateThread itself), and may be is necessary in the most extreme cases, otherwise the only way to stop the application is taskkill.

 

 

We are using IMAQ's C API to control a Camera Link camera. Our camera's .icd file supports changing attributes such as exposure time and capture bit depth. These parameters can be adjusted inside MAX, with MAX only allowing values supported by the camera. While the C API allows for getting/setting these attribute values (ex. with the imgSet/GetCameraAttributeNumeric functions), there is no way to determine the allowed or minimum/maximum values (or even that an attribute is supported for the given camera). It would be helpful to have API functions which could access this sort of data within the .icd file.

 

A similar issue exists when trying to start a new imaging session: there is no way to know programmatically which cameras (if any) are connected to the machine, and if so which interface ID they are connected to ("img0", "img1"...). This data appears to already exist in the .iid files used by MAX, so it would be useful to get at that info from within C (right now, our applications just open the "img0" interface and hope everything works).

LabView could use plugins (like Adobe!) for a lot of the features suggested by those on this forum, instead of implementation only with the latest release. For a lot of university computers that are running on old DAQ boards or simply cycle through their programmers quickly, upgrading to newer versions of LabView isn't an option, both from a price perspective and from a "reprogramming everything" logistics perspective. (I'm in this situation, with a lab using 6.1)

 

Plugins that I have in mind are:

 

  • Block Diagram Cleanup Utility plugin for versions of LabView before version 8.6. Whatever algorithm the 8.6+ versions use would still work for wires and other objects strewn across the block diagram, so adding this shouldn't be too difficult.

 

  • Zoom functionality for LabView, period. LabView is a graphical programming language, and anything graphical should have some sort of zoom utility. Whether it be to see a large block diagram in its entirety or to zoom in for people with poor eyesight, or simply a graphical readjustment to suit a different sized monitor, zooming is critical to any graphical process. Certainly, LabView wasn't created for artists, but I still think this is very important. Again. Not too difficult to create a plugin that works natively. Failing that, even an NI-supported zoom-in/zoom-out tool that wouldn't allow editing in those zoomed modes would be helpful.

 

  • LabView canceling when opened. I believe I saw this elsewhere in the forum, but basically just something that would allow you to close LabView if it opened accidentally without going to Task Manager. On older machines it takes forever to open. Easy to implement; basically just a GUI change to allow closing earlier.

 

  • An "Open Recent" option. I don't know if later versions have this, but it just allows opening the last project you worked on so much faster than what directory browsing allows. Again easy to implement as a plugin, I'd imagine. Some sort of cache'd memory and a new menu item.

Thank you for your time.

The CVT library is very useful in automation applications especially combined with the TCE tag editor and CDL data logger.

At the initial phase of the development of a new project, it could be useful to try new values for parameters and after evaluation, it could be nice to save them back to the XML CVT file as new defaults.

For this reason, it could be nice to add a Saving method to the CVT library.

 

Regards,

 

Maurizio Bollini

MET Srl - Milan (Italy)

www.met.it

One of the many attractive things about LabVIEW, is the fact that if you can think logically, most likely, you could write LabVIEW code. However, there are lots of coding opportunities in the world, that require code that is developed in C or C++, especially products that use embedded SW.

 

Since "G" is based upon "C", I was wondering if it would be feasible to create a development tool that would allow the user to develop in LabVIEW, but also convert or create equivalent "C" or "C++" code that could could literally be inserted into a program. I've used the .dll creation utility for C developers to use in various "test" type applications, but have yet to find a way to use that method constructively for embedded projects.

When we open and not making any changes we close the code refering to the API of components which version differs from the version was used to write the code we are getting the standard message do we want ro save or deffer the changes or cancel the operation.

 

When we hit the buton/link 'Explain the changes' as the result we are getting the 'not explaining a lot' message: 'External component has been changed'.

 

It would be very practical to have the information what exacly has been changed.

Vision Assistant creates code for raising an error if the coordinate system is invalid. The code would look much nicer when the VI "IMAQ TransformROI" would check for validity of a coordinate system. Or when at least the error would be checked in a SubVI.

 

The generated code currently looks like this:                                     With the SubVI it would look like this:                                               And with error handling in IMAQ TransformROI like this:

Original_VI_BD.png SubVI_VI_BD.png inSubVI_VI_BD.png

 

 

The SubVI would contain code similar to this one:

Check Coordinate System_SubVI_BD.png

 

This application is used to track the Position of the person in the mall as the GPS will not work nicely in Indoor Area it can be help with Inertial Navigation System since all the current mobile phones comes with accelerometer and Gyroscope which are the basic parameters for the INS to be added with the last GPS fix will give more or less accurate position and with the essence this can also be integrated with RTLS tags and Cell Locate Algorithm and A-GPS inbuilt 

Iam looking for Labview support on this so as the application can be completed quickly 

Regards

Satish

I will go straight and may litter bit offend the guys working on developing labview in NI, that since labview 2010, there is less and less suppresses brought to the labview coding folks. But also since labview 2010, I've been 'pleased' most is that ni recognized that 'user driven' is one of the most eye attractting futures labview can provide to the developers. Why not you guys go further, release the labview sdk and turn product labview to platform labview. Then fans and geeks can improve labview developing experience along with the employees at ni directly and efficiently.

 

Here is my reasons:

 

FOR US:

 

1. A powerful and convenient developing environment benefits both labview developers and NI.

 

FOR PEOPLE:

 

2. Not only normal engineers, but also professional software engineers choose labview as their developing tool. Trust me, current labview will drive them crazy, like me(three years "torching"). You can never control the threads or memory under the graphic programming concepts, though sometime it mattered.

 

3. There are so many ideas users want and sometime maybe they can realize it by themselves easily under the access to the labview sdk. Then new fractures can be shared, sold or contributed.

 

FOR THE ECOSYSTEM

 

4. We deserve an ecosystem for labview. Roles are like: labview market, developers, users, ni, etc.

 

敬请拍砖, in English means welcome criticizing~~~

Apologies for being heretical to LabVIEW.

 

Even the text-based coding world has room to leverage a good driver-hardware ecology.

Hello everybody!

 

There is a simple way to trigger linescan camera acquisiton controlled by an encoder, as is shown in LL Trigger Each Line From Encoder.vi example.

 

However, it is not possible to do it for frame cameras in a similar fashion.

 

Therefore I suggest that there is a way to configure "IMAQ Configure Trigger3.vi" in order to acquire a frame from a camera every N ticks from the encoder.

 

[idea thanks to a customer's request]

 

What do you think?

Have a great day!

Zenon