LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Hello,

So as it is The VI analyzer has some limitations:

1. You can't fully customize the toolkit as some functionality is still not exposed as an API.

2. You can't build an executable with a VI analyzer.

I was hoping that NI could expose some more API that would allow for programmatic control of the error highlighting feature of the VI analyzer.

This will allow for creation of a more standalone application rather than being piggy-backed into the LabVIEW environment.

Thanks, Sher

View All (2)

I get that the Application.ini file can contain configurations options which might wished to be changed after compile, and I get that the application shouldn't modify its own exe.

But sometimes the ini file is used for things which cannot simply be hard-coded (or at least, I've found no way). For example, I am using unicode (it isn't my fault I have to resort to "experimental" modes in order to gain basic, fundamental functionality which should have been implemented as standard decades ago, but I'm not going to apologize for living in 2019), and in order for an exe to properly render unicode strings in controls etc. it requires the UseUnicode=True flag in the ini. What this means is that, in order to even function correctly at all, the exe is burdened with the constant baggage of an ini file which end users will never interact with, never understand, and frankly have a less-than-zero need to be exposed to in the first place.

I've wanted this functionality on other occasions, but I'd be happy if someone could explain why I'm wrong about the unicode thing.

Array to Variant Function

I'm writing a VI for a lab which writes to a database. The number of measurements will vary depending upon which fixture is set up in the lab, and whether the experimenter decides to add extra ones. This results in a varying size array of doubles which gets written into a single database with generic column names c1-c200. The column names are cross-referenced in another table keyed to the lab fixture.

The method I found here is to convert from array->cluster->variant->database insert. The problem with this is that a cluster's size must be available at compile time, making the varying array size more difficult. It also limits the size of the array/database entry to 256 elements in the array->cluster conversion.

I know I could just populate and write a 200 element array into the database, but that increases database activity , is inelegant, and forces me to put zeros in the unused columns, instead of leaving them null.

Attached is a VI which demonstrates what I would like, though it only works for doubles and is still limited by the 256 element limit. It could very easily be changed for integers or strings, but it would be best if it could take any type of array input, with a much larger size limit.

Download All

View All (3)

Today, a for loop always select the minimum number of iteration between the number wired in "N" input and the size of every auto-indexed array.

It will be great to select between three mode :

- the minimum value, like today, with a "N" terminal.

- a fix value, ie the value send to the terminal, who become a "F" terminal (for example), no mater the size of the auto-indexed array.

- the maximum value, with a "M" terminal for example.

View All (1)

With use Conditional Disable Structure developer define custom Conditional Disable Symbols as Project property.

I think, add option to define Conditional Disable Symbols as Labview property.

Now I use Project code in two computers with different MS Office versions (2013 and 2016).

Because part of Office functions in different versions has different count of parameters (example, Save As), I must replace Invoke mode each time open my project in other PC

The close reference node returns errors for invalid references (1026, 1055 etc.). The majority of the time, I don't really care. I then have to manually filter out this error on that particular node.

Could we have a bollean option to generate warnings on invalid VI refs instead? Similar to the following:

Whenever we add a new item in tree programatically using "edit tree item" node,

We are not sure what tag would be set to Child Tag. Because if that tag already exists LabVIEW will appends a number to make it unique.

From help of "Edit Tree Items:Add Item Method"

The default is the string you wire to Left Cell String. If an existing tag already uses that string, LabVIEW appends a number to the string to create a unique tag for the new item.

It would be great if we can get the value of "Child Tag" as output as well, which is set by LabVIEW.

The error cluster is obsolete, it's time to move on. It's 2018 we need a more flexible error output.

it's deeply hard-coded into LV.

The most hard-coded thing that is impossible to remove is that it's used as a way to force sequential instructions (error in -> error out are many times the only connectors).

The problem is that

the error codes are limited
dont scale.
cant embed additional object into it.

I can't use the full range of I32 as error code.

If I use error code 6400, it will clash into yours 6400 custom code.

I need a way to say : this is the error code of MyModule/Actor/class/LVLIB, that I need to "namespace" error codes

I need an additional object into error cluster, so I can carry more info.

So pls NI, empower error cluster with additional field: "meta error object", that we can derive/extend and use.

View All (1)

ALL Properties

NI's code should be excluded! Many VIs are installed as part of LabVIEW in the C:\Program Files (x86)\National Instruments\LabVIEW folder. These should NEVER be modified outside of installs/upgrades. I started a Mass Compile and, whoa, it did much more than I expected! It changed and saved hundreds of files. I let it run for about a minute, got too nervous, and stopped it. I didn’t think to back that up. Now I fear my LabVIEW installation is dirty. NI SR#7722650 says "It does go outside of the specific folder if the VIs in the specific folder depend on another VI outside of the folder. When it goes outside, it is just opening the VI and resaving it in the current version of LabVIEW. Because your VIs depend on some VIs in the ... vi.lib it went and resaved them. But, they are already in LabVIEW 2015 SP1, so it will not change anything in them. It does this to ensure the VI is looking at the current version of LabVIEW and not an older version." If that is true, why would installation of a version of LabVIEW install VIs of older versions? Make sure all vi.lib VIs are already compiled for that version.

I found https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Force-Recompile-option-in-Mass-Compile/idi-p/2659839 which discusses whether or not LabVIEW Mass Compile changes files that are already up-to-date.

View All (1)

Mass Compile changes files that do not have a LabVIEW code extension such as ".ctl" and ".vi"! Why is it trying to load, check, and save files with extensions such as ".bak" and “.err”? The following example shows files that a prior mass compile found problems with and I renamed them and removed them from source code control.

### Bad VI: "EditString.ctl.err" Path="C:\cvs\r8000\labview\app\editor\controls\EditString.ctl.err"

### Bad VI: "MCNavigate_old.vi.err" Path="C:\cvs\r8000\labview\app\remote_control\MCNavigate_old.vi.err"

Another example of this is described in https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Mass-Compile-should-not-touch-Subversion-files/idi-p/1081483 which says files with ".svn-base" are changes. Yes, there was a specific improvement made to ignore those, but really, that wouldn't be necessary if Mass Compile stuck to known LabVIEW file types.

View All (1)

Which VI has exection thread?

We can get the top level VI using property nodes / call chain, and we can also determine the running state of any specific VI (given a path).

It would be really useful to know which VI was running as any point in time (without resorting to execution highlighting) - not really applicable to time critical applications of course.

Uses for this include:

1) the abilty to change a VI execution state from Modal to normal with custom created dropins - if required.

2) Automation - it would be really useful to retrofit projects with a tool/dropin for soak testing / debug which detected certain windows - normally these would be modal dialogs and entered data in them to allow the program to continue (I know these features can be built in at the start of a project, but dropping in later would be very powerful for pre-existing ones and allow the use of the NI dialogs.

3) simple debug - code is stuck, exection highlighting is not showing where. This would give the answer.

James

LabVIEW currently does not have a VI which moves user selected single or multiple array elements up or down (increment or decrement selected index numbers) and reorder the array. I built a malleable VI which does that and if I am lucky, it may be released in the new LV version within the array palette. This VI can be used when single or multiple selected items in the listbox, multicolumn list box or similar controls wanted to be moved up or down at one click of a button, i.e. if you have a list box with 10 items and you want to move up or down item # 2,5,6,8,9, ( which means array indices 1,4,5,7,8) , these selected items will be moved up or down and items will be reordered within the list box. This also can be used when you move items up or down while editing Enum items. Currently, you can move up or down only a single element but not multiple elements in the Enum edit elements function

View All (1)

Global Queues Palette

Proposed:

New "Global Queues" palette with with both "queue name" and "application scope" input required, on Global Obtain Queue and Global Release Queue.
Global Queues to be accessible to ALL projects / applications running on the same host, but only if referring to (the same) queues with the same queue name AND application scope (not just queue name, but both, to allow for scope partitioning).
New "release mode" input to Global Release Queue (enum, 3 options): "release" (single local ref, as per normal queues), "force-release" (all local refs, as normal queues with forcing TRUE), and "global force-release" (all refs with the same name AND application scope pair, globally).
Due to multiple projects / applications referencing the same queue locally, a few further VIs or methods would also be productive, such as: get total number of local references to queue, get total number of global references to queue, singularise all local references to queue (release all but the latest 4B ref), these are mainly related to monitor & control the accumulation of 4B queue refs in a direct closed loop fashion (as opposed to merely keeping track of them in an action engine).
Due to further increased complexity, a queue attribute / property (and a Global Queue Status VI output revealing this) specifying the enqueuer application -> library -> VI chain for each enqueued / dequeued / flushed item, could be added. This could also be used for security & access scope purposes if desired (i.e. custom code to reject the dequeueing of any queue element not enqueued by a specific enqueuer, etc.).
For monitoring & debugging purposes, a VI to output names of all queue names associated with a particular application scope would also be useful. Application scope name would still need to be known, but code for dynamic allocation of queue names within the same application scope could be designed with much better compliance.
Although this can be considered a queue functionality extension, having a separate palette (e.g. same queue icons, different colour) is subjectively better, makes it easier to read code visually, less error-prone, and more consistent to implement with the crucial new Global Release Queue "release modes" proposed.
Essentially the extension of named queues to be accessible by multiple distinct projects / built applications (assumed to be long-awaited by many), but with being able to specify the pool of interacting applications explicitly, hence "application scope".

Purpose:

Direct queue use across multiple projects / applications on the same host. Similar comms can currently be implemented by using network streams (acceptable lossless FIFO), but these are grossly inefficient and slow compared to queues in memory, require coded polling to check stream items available to read, and are exposed to, as well as dependent on networking protocols and even firewall configuration. There should be no need at all to use any networking for separately built daemons running on the same host, and no need to do (coded) polling in particular.
This would also allow for a new approach to plugin architectures where plugins can be implemented as fully decoupled, compiled, standalone daemons each (a potential for further explicit optimisation for parallel processing). Process call overhead and memory implications could be managed by means of coding directly (daemons could be individually configured to be either launched on demand, or launched automatically to await instructions / data on standby). Develop new plugin adhering to engine specs on queue datatypes only, build it into an exe using any version of LabVIEW, set single or multiple instance mode in ini file directly, supply to client, done...

View All (4)

Bottom Line Up Front: The Asynchronous Call functions should maintain functionality of Malleable VIs when called.

Background: LabVIEW 2017 added the Malleable VI (https://www.ni.com/docs/en-US/bundle/labview/page/malleable-vis.html) which allows a VI to adapt to it's inputs at edit time if the inputs don't break the subVI block diagram. When attempting to start an Asynchronous Call on a Malleable VI the input terminals are forced to the types the VI is saved with. This is most likely due to the Strictly Typed VI Reference (https://www.ni.com/docs/en-US/bundle/labview/page/creating-strictly-typed-refnums.html) required to start the call. This type of reference loads the connector pane of the selected vi which seems to lock it to the saved terminal data types instead of allowing the malleable vi functionality through.

Proposal: Malleable VIs are a huge leap towards highly reusable code while maintaining the strict type paradigm standard to LabVIEW. By abstracting that functionality one step further to the vi reference/asynchronous call functions, possibilities for highly parallelized "type independent" code frameworks would be greatly improved.

Example: A framework to build/deploy/maintain many connections to a separate application is desired. This could be accomplished through TCP/IP or Network Streams or the like. By allowing these connections to be handled by one asynchronous vi each the setup time/maintenance time can be highly parallelized. These connections could support many different types of data transfer but would need to have each case coded and maintained separately. With asynchronous calls to Malleable VIs a single handling VI able to handle arbitrary data types internally would be sufficient for each communication method greatly reducing VI maintenance time and risk.

Conclusion: The Asynchronous Call functions should maintain functionality of Malleable VIs when called.

View All (3)

I have been developing LabVIEW projects for more than a decade now and most of my projects are large scale modular projects. Let me give an example; I have a project which has 20 program modules in it. Each program module has its own Main VI, SubVIs, controls and globals. Each module is called dynamically so that only the module being called will be loaded into a memory. Ie, if I want to use my "Performance Test Module, I called only the performance test module main VI and other test modules like "Durability Test Module" will not be loaded into a memory. Here is my idea; If I need a new module like a "Fatigue Test Module", I would like to be able to duplicate an existing module's Main VI hierarchy into a folder with modified names and this newly created Main VI should reference these newly named VIs. Since existing module and the new module are intended to be in the same LV project, it causes file name and references conflict when an existing module's main VI hierarchy is duplicated to create a new program module. Currently, LABVIEW version 2017 has no option to duplicate hierarchy with new file names. It would be very time saving for me if I was able to duplicate hierarchy with new names. For example, If I am duplicating a VI named as "SaveData.vi", I would like to be able to add an extension to a file name when I am duplicating the hierarchy like "SaveData_FatigueModule" so that all other duplicated VIs would have the same extended "_FatigueModule" name in them and newly created Main VI would reference to these VIs. Therefore, I would be able to add the new module into my project without causing any conflict.

LabVIEW Idea Exchange

LabVIEW VI Analyzer: Expose Error Highlighting feature of the UI to toolkit API.

Allow storing Application.ini within the exe

Array to Variant Function

when stepping into a VI, do not read controls before pausing

Select the for loop max number of iteration

Have a SignalExpress Duplicate Directory Name Error/Warning

Define Conditional Disable Symbol as Labview property

Close reference - Option for warning instead of error

Value of Child tag for newly added item in tree

Improve error handler by including an object

ALL Properties

Mass Compile should NOT change Program Files

Mass Compile should not change other folders

Mass Compile should NOT change NON-VIs

Which VI has exection thread?

Move user selected single or multiple array elements up or down - fool proof version

Move user selected single or multiple array elements up or down

Global Queues Palette

Asynchronous Call on Malleable VIs

Duplicate Main VI hierarchy into a folder with modified VI names