LabVIEW Idea Exchange

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

For Reports it is only possible to set one with for all columns. It would be nice if the polimorphic VI "Append Table to Report.vi" would support column with for multiple columns too. Several VIs would have to be copied and adapted.

 

For a standard report, the VI replacing "Set Table Column With.vi" would look like this:

 

Set Table Column Widths_BD.png

The functionality to adapt to the page with if the column with is too big is lost when different withs are set. But probably NI could fix this too.

 

Greetings,

shb

Locking a library during an automated build seems like a very natural thing to do.  Would be nice to be able to script it.

Create a VI, which allows to get the config file path from the config reference.

 

Regards,

Marc

We are getting into trouble with all these run-time engine updates! Every time a new release or service pack come out we have to create a new installer with the new run-time engine and send it out onto all our customer's machines. It is not convenient to develop in 20 different versions of Labview and we like to keep our executables and updates recent.

 

Our instruments run on XPe with very little extra room for an additional RTE every 6 months. Asking the customer to uninstall old RTEs is painful as they are not supposed to go that deep inot our XPe build. 

 

I would like to see a modularized run-time engine where we don't need to update the whole thing every release. I know  with .NET updates are only necessary in 3-5 year increments. That would be much more acceptable IMHO:smileyhappy:

 

I'm proposing a new certification, one certification to rule them all, the Certified LabVIEW Gangster Group Developer.

 

Or simply a fully functioning CLA that requires 3 people to take the test.

Architect

Developer

Embedded Developer


It should function using an FPGA, or a simulated interface.

 

 

One of the things LabVIEW is best at is its innate parallelism. Parallelizing for loops with a right-click is something other languages wish they had. Having all code on the block diagram (or equivalent) innately run in parallel is something few other languages have even tried, much less succeeded at.

 

Crunching large datasets can be sped up through use of GPUs, and over the past decade or more, Nvidia has kept their promise of having a common interface to their hardware through CUDA. 

 

Having a LabVIEW add-on that is well maintained, and that can give GPU parallelism in the same ways we've seen LabVIEW deliver CPU parallelism would be a game changer for many labs and manufacturing environments. It could also help LabVIEW be a leader in the AI space.

 

I suggest that you create this add on package using CUDA as the underlying GPU calls, in order to keep the code easy to manage, while also providing the package for a large number of supported GPUs.

to transform existing VI to be integrated into PA flows, the drop-in should be populate all controls and indicators to be used as connector variables. 

Companies around the world are trying to make it easy for robotics, for example NVIDIA is doing everything that they could get into simulation and and NI should have been in the front to support, just like NI had the tools for mobile interface in 80's, and never released to the public, if it would have happened then Android would not have born, just like that robotics once NI loses it to NVIDIA and python and other tools, it would be difficult so I am trying to create a simulation environment just like digit twin for robotics, where labview will simulate in open source for Gazebo, and then based on the simulation will control the actual robot.

 

Setup LabVIEW talking to Gazebo through ROS, if you are interested to be part of a group where we could get the software updated, please email me at jacobs.mathews@gmail.com

Report Writer BEFORE WIndows 10 was SUPER ROBUST! Now that Windows 10 came along there exist many "turds" left in the Registry when folks UPGRADE from Office 7 to Office 10.

What happens is the Registry NEVER NEEDED to be kept clean of extra junk because NOBODY EVER UPDATED Office.

 

Now every Joe on the planet updates their Windows 10 with the latest Office 10..


What happens if they do NOT FIRST UNINSTALL, is the Registry is left with "turds"


When Report Writer uses ActiveX to make calls to use Word, in the old days, there was a SINGLE key in the registry to allow the calling program to gracefully start Word or Excel, or whatever.


NOW< with Windows 10 there are FREQUENTLY multiple "keys" in a Registry that causxe the LabVIEW Report Writer to "Gag" and "Hang up" doing nothing.


The SOLUTION is for the Report Writer to PARSE the Registry for valid keys and allow the request to be passed to the propper called process.

 

If this is not clear, please look up the SR below. There are a TON of examples and videos explaining how to fix it.

 

I have been working with LV since Dr. G was roaming the halls on LV 3...

 

This is the FIRST TIME Report Writer has gotten "sick".


This is an EASY FIX for the devs and since Report Writer is a purchased plugin they sould be able to update it so it works well.

 

Currently, they have us fiddling with the Registry or telling customers to uninstall and reinstall Office. That is a BIG FAT NO-NO to big companies because Office WORKS COMPLETELY for them and even programs like SolidWorks and DXP that use Word and Excel for stuff.

 

My number 831-455-0418

 

DEVS:

Please see: Request #: 00994109] Can not get EXE BUilder to run on WIn 10

 

it would be great if adobe reader was built into the additional installers section of the project installer build.

i would think this would be a common thing users end up installing sperately

 

 

Idea is quite simple - add to instrument drivers project wizard template for switch/MUX/matrix devices.

 

Custom switching boards are commonly used, b/c for some simple purposes it is cheaper to make custom design with simple functionality (some micro processor which controls relays), and which could communicate by serial line. Then instrument driver - is ideal solution to create simple API in LabVIEW for its control; but unfortunately, there is no template for such types of devices in New Instrument Driver project wizard.

Hello Guys,

 

as we are transforming our Testing Application deployed as Executables to something more "state-of-the-art", I found the Remote Panels solution could suite our needs.

Remote Panels are a nice solution, but they rely on LabView RTE and Browser Plugin on the Client Machine. I don't think this is state-of-the-art, since the Web Technologies Wars have are over and Plugins lost the Fight.

I found some similar ideas in the Idea exchange, but none of them hit the point directly. So heres my Proposal:

 

Replace the reliance on LabView RTE and Browser Plugin with a HTML 5,JavaScript and Websockets solution, that runs on any modern Webbrowser!

 

This would bring the following Advantages:

- support for any client operating system (even IOS, Android, etc. possible)

- seamless support for Remote Panels in modern browsers (neither Chrome, Firefox, IE will support NPAPI in the future)

- take advantage of all the PROS of modern web technology (e.g. responsive UI to support Touch UI targets)

- since no Plugin is needed, Clients will have no Security concerns (remember Adobe Flash concerns at Apple)

- no need for any NI customer to build an own HTML5 remote panel solution to bridge this obvious gap of Labview Functionality.

 

I know there are solutions for Windows Remote Control like VNC, but this does not offer a target UI adjustment for the application. So for example a Ipad Target will not change its UI to be Touch-friendly for the User.

 

I hope you support the Idea! Best regards and thanks for the Attention, Philipp

 

To generate a VI or set of VIs with a general driver to get low-end FPGA boards to work with LabView FPGA. Parameters will only come from the users to make this dynamic, this would be the total count of I/Os FPGA type, location of I/O items (eg. buttons) in the FPGA board, etc. It would be a bit of work, but also would pay off at the end. Doing such is no more than an extension of LabView if done well, let's say written in an xml file plus it would be a very powerful tool for researchers, and would generate more sales to use LabView FPGA for more researchers, university students, and engineers who want to test a few things without full initial commitment to NI tools.

 

 

It would be nice to get the Test Case Comment into the report. Also, please add programmatic access to read it out.

 

Test Case.PNG

Hi

 

Is it possible that the contents within the instr.lib to be defaulted to read-only every time LabVIEW launches? VIs that is drag-drop from the pallet onto block diagram is currently modifiable and may cause unintentional code modifications, especially due to the 'save all' function and hasty/improper shutdown. The extend of the damage may be inherited over time.

 

Also propose to default modified instr.lib VIs saves to be in active project folder instead of the instr.lib.

 

Hope to see these features in future versions.

Make a tool pallete wizard that would make it easy to install custom software into the tool pallete. It should allow for the user to make the sub directories, Icons and everything that is need so it could be published without have all kinds of headaches. Making tool pallete menus has to be one of the worst things I have to do. This year with the FIRST libraries being added to the tool pallete a lot of them have no icons because of how hard this is. PLEASE make this easier to do!!!!

There are some analytic software that adds connections to Excel.  JMP comes to mind - it allows 2-way data transfer, and allows excel to run some of JMP's analysis routines.  Those packaged routines are vetted by phd's and can't be quickly damaged by a tired user. 

 

This details how JP morgan lost a few billion dollars because they were using Excel for hard math, and someone had an error in an equation.

 

Excel is likely more common than both Javascript or SQL for use in the planet. 

 

It might be very powerful to be able to import an excel spreadsheet, specify inputs, specify outputs, and get it translated to "g".  This could allow it to run thousands of times faster, and the visual language would allow a technical vetting that can be very hard for humans to do on hundreds and hundreds of pages of tables of numbers or formulas. 

 

This would be a motive for banks like JP Morgan (or their peers) and their multi-billion dollar business units to use LabVIEW.  Stunning speed, optimization, and scale.  Stunning accessibility to error correction.  Packages that, once wrapped, stay wrapped, but can plug in where they need to.

 

Other add-in or connectors for Excel:

It is unlike the TDM-importer in that it sends data to LabVIEW, the data is transformed or processed, and a numeric, text, or image result is returned to Excel.

GPS/INS applications are increasing every day as you know.
It is inevitable that using maps in GPS/INS project.
There is not a simple and useful map tool in Labview.
In some open source code map applications like "Open Street Map" will be useful for some projects which including GPS/INS.

I've made my own copy of the actor framework to implement some changes that I really needed. Because of this I cannot really share code easily and my framework branch is not automatically updated. The changes that I've made could be made without overwriting the framework if only the framework was more open.

(a bit of what you can do with the changes are listed in brackets)

 

Creating more functionality for actor framework classes should be done through children of the classes in the framework. The way the framework is setup makes it impossible to add functionality to some classes:

- Message Priority Queue

- Message Enqueuer

- Message Dequeuer

- Message Queue

These classes are all obtained with a class constant internally in the framework.

I would really like it if we could have a class input to all these so we can implent additional queue functionality and have this input as part of either an actor dynamic method inside of the Actor.vi that the constants are read from or an input to the launch VIs.

[Magic can be done with enqueue in front combined with batch message children and public scoped read self enqueuer --> self propagating message array]

 

Changing functionality through dynamic dispatch is the way it's meant to be done. But most of the Actor framework VIs are static dispatch. Vi's that I'd like to make dynamic are:

- Launch Actor Core.vi (and probably all the other launchers as well)

- Actor.vi

- Send Message and Wait For Response

- Send Batch (Or change the class constant to a control

[adding a counter to an actor child would be easy with a dynamic dispatch of Launch Actor Core]

 

Heavy use of access scopes makes some actions impossible (as intended). I'd like to have the following changed to community scope and added as friends to the Message class:

- Read Self Enqueuer

- Read Caller Enqueuer

[Messages that flush the queue, view the queue status enqueues them self on the queue and so on can be made]

 

And lastly but surely the most controversial is the change of pre launch init from non-reentrant to reentrant.

Yes by doing this and launching an actor from within the vi will crash your program. But doing it as is will result in a deadlock anyway. The protection of making it non-reentrant is extremly weak! I'd rather have some warnings. What you gain is that the actor that you are launching and the nested actors that it will launch from the pre launch init can share their private data during launch! This is extremely useful with actor shared notifiers, DVRs and so on. Note that you can do this halfway by launching from the actor core.vi however the data will only be shared up in the hierarchy not throughout the entire hierarchy... which is bad/sad.

 

I hope you'll look into at least some of this to enable a more dynamic usage of the framework for advanced users.

 

Add a LabVIEW application method or property that would allow us to set the object of the context help so that we can specify a VI from a tree based browser (much like the Project Window does).

 

https://lavag.org/topic/9167-context-help-for-a-vi-without-loading/?p=54820