LabVIEW Idea Exchange

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:

• http://www.thespreadsheetguru.com/blog/popular-excel-addins <- nice graphs, analysis, excel visual transformation tools.  VBA security
• http://opensolver.org/ <-- Several, non-trivial, solvers.  (COIN, CBC, others)  Large problem solutions (not throttled).  Visualizer.  Alternative user interfaces, sometimes more valuable

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