LabVIEW Idea Exchange

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

This is a very simple example of subpanel structure in LabVIEW

 

https://decibel.ni.com/content/docs/DOC-41897

 

Regards,

JohnnyM

 

 

In Diagram Disable Structure, if there is an option provides "Selector Terminal" that could help to control programmatically. This could be optional selection in RCM (Right Context Menu).

 

Connecting Enable/Disable as Constant/Control to Case Structure would not do all purpose as the functionally of Diagram Disable Structure Enable/Disable individual does.

 

Diagram Disable Structure have unique behaviour if this Selector Terminal is given as optional that will add even more vale to the same.

 

As programmer myself felt that why do this be controllable, because while developing big codes we use to much of diagram disable structure , when we are suppose to change to Enable or Disable, I has to search for around my code. If this has controllable option that help to do my work even more efficient specially while testing code. 

yrfj.png

 

I mean when it's used for indexing array...

It could be really useful if someone wants to skip some initial indexes...
It has already been done?

So I often find myself wanting "pointers" Smiley Frustrated But they are weird and not flowish in the labview world. Most of the time I don't want them for concurrency i want them for the ability to create complex data structures like link lists and such. And yes we can make them using DVR or priority Queues but it just seems like unnecessary overhead. I mean Pointers are really Really fast. So what options do i have.Options.png so who wins above? fastest to slowest:

 

Flow Count

ArrayRef

Variant Count 2

DVR Count

Queue

Variant Count

 

So I guess i could use a array and use indexes for reference but that would be tedious! Plus I can't remove an element from an array without ruining all the other references! So I suppose i would makes something a mix between a ARRAY a Variant and a DVR the data flow would be like the array and the references would be typed like a DVR wire. I Imagine it looking something like this:

 

I call it a SCOPE because i honestly don't know what to call it.

 

SCOPEIDEA.png

 

Well what do you think would this be useful to you?

When i finish my working day I often start to build a installer and execution. Because I don´t want my computer to run the whole night, I initiate a windows shutdown after for example one hour (shutdown -s -t 3600). In this case it would be nice if I could say "Save project and quit LabVIEW after building installer execution" or even "Save project and shut down computer after building installer and execution" so I would not get an error message when I start LV again.

In the current version of DETT (2014) it does not appear possible to trace into VIs in vi.lib and intr.lib. This is unfortunate since we rely on using development packages deployed with VIPM - and these packages are often installed into the LabVIEW folders in one of this sub-folders. Debugging these VIs can be very useful during development and adding custom trace messaging in the application or to the VIPM packages can be cumbersome.

 

Ideally it should be possible, as an option, to include or exclude these folders.

Hi, in large application where you have many parallel loops you must to be sure to put for all of them the correct out condition (even for "For" loop if they are long). i.e. in case of error or when user press "Stop" while the program is running.

 

I think could be useful if you can define somewhere a list of boolean variable and when you place a loop in the block diagram it is automatically connected to the list of boolean variables. For that particular loop you can select wich variable (one or more) defines the stop condition.

 

To select the variables you could use the same approach used for  "Timed Loop".

 

The list of variables should be linked to the project and active only for that project.

 

BR.

I've been working on a project for the last few months using the Actor Framework, very happy with it and would definitely recommend it to a friend.  I noticed the accessor methods for the "Caller Enqueuer" and "Self Enqueuer" have a class input but no class output.  This results in branching the class wire in most of the calls to these methods which can get a little bit ugly and I also believe results in an additional copy of the class being made in memory.  I appologize in advance if there is a good reason for these methods being implemented the way they are, or if this has already been asked.

AF Accessor Method Image.png

Hey everyone,

 

here is my first suggestion.

It is a bit annoying to have two Projects open within a single Labview.exe Process.

 

Why?

For example if i want to compare my Project Settings of the two Project to sync them, i have to:

- open project settings of Project_1

- memorise the settings

- close project settings of Project_2

- edit setting with memorised informations

- repeat for every settingpage

 

This works for every dialog, Open, save.....

 

You have to do this because the SettingsDialog blocks every opend project. Please treat every instance independent of each other.

 

Regards

Ronny

I would like the option to save data from LabVIEW using the Hierarchical Data Format. This would make it much easier to share data with Matlab and other programs.  

This is a real pain point for us at the moment and drives many of our engineers away from using LabVIEW, quite rightly. The tdms import dll for Matlab is slow and the 3rd party .mat export toolkits for LabVIEW are not sufficiently developed or only licensed for single-seat environments.

Hi all,

 

it would be useful if the FOR LOOP had an indicator which is set to true on the last iteration of the loop. This terminal could also be set to true if the conditional terminal is used to abort the loop.

 

My use case:

If have various "channels" (Bits and Bytes) over which I communicate with an external ProfiBus device. These channels are identified by enums. The data values themselves are organized in a predefined numeric array in a FGV, and depending on the enum value I replace parts ("chunks" of bytes) in the array.

 

In most cases, I have to update more than one parameter in the external ProfiBus device. I change the values in the data array FGV using a for loop, and after the last array subset replacing action, that is in the last iteration of the loop, I actually transfer the new data array via an "update ProfiBus" notifier.

 

To "detect" the final iteration, I could check  "i < (ArraySize - 1)", which means to have this additional (tiny) piece of code in each iteration. Another option - which I currently use - is to provide an addtional array to the loop with just as much boolean elements as in the "channel enum array", in which only the last element is set to true, to set the "update notifier" only once.

 

To make it short:

Please provide an additional for loop indicator which is set to true in the last iteration of the loop.

 

Greetings

A-T-R

Can we include a Temporary File Path terminal to NI_HTML.lvclass: Print Report.vi, and consequently NI_ReportGenerationCore.lvlib: Print HTML Report.vi.

 

NI_HTML.lvclass: Print Report.vi will merely pass this path down into NI_ReportGenerationCore.lvlib: Print HTML Report.vi.

 

In NI_ReportGenerationCore.lvlib: Print HTML Report.vi, if Temporary File Path is Not a path, then continue to create a temporary file path.  If it does exists, then add some code at the end to clean up the temporary file.

 

 

 

 

Download All

So today it seems that my company has reached a critical enumerator value of 2147483647. It caused some trouble since I'd never expect a "%d" to be restricted merely to 32-bit signed integer! A provided picture shows a solution to a problem, treating a number as 0-precision float.

Also, what kind of idea is to coerce an input value into the range unrelated to input's data type?

 

I use LabVIEW 2011 SP1.

LabVIEW 2013 and 2013 SP1 Known Issues

 

377385

Return
Error 1390 on Dynamic VI Call to Friend Library
The error is returned when two Community scoped LabVIEW Libraries are Friends to each other, and one Library performs a dynamic call to a VI in the other Library.

Workaround: Change the dynamic call to a static call, or change the scope to Public on the Library containing the callee VI.

Reported Version: 2012    Resolved Version: N/A    Added: 01/28/2013

 

366921

Return
Community scoped VIs within classes in a LabVIEW library will break a packed project library and cause Error 3
N/A

Workaround: N/A

Reported Version: 2012    Resolved Version: 2013 SP1    Added: 01/29/2013

 

Having a set resolution date would be nice. Getting these fixed in the near future (LV2014 or 2014 SP1) would be awesome!

I thought this would be useful in many scenario. Most often we do require to transpose the 2D Array after bundling some 1D Arrays. So, like the Concatenate Array option in the Build Array function, a Transpose Array function would be very helpful, reducing one another explicit node on the BD.

 

Any takers... ?! Smiley Happy

 

 

P.S.:- I did a search before  posting this idea, but it yielded zero result.

It would better to have a console for Shared Variable, to monitor the value inside shared variable if it has so many cluster variables in it

Hi,

 

Probing a Front panel shall be easy to debug.

 

Thanks All.

 

Before :

 Idea 3.png

 

After : 

 

Idea 3 1.png

As a debug tool, it would be incredibly helpful for me if I could pause at a certain point in the code when a value meets a certain criterion, without having to edit the code.

This functionality already exists as the "condition" tab for an error cluster in the Probe Watch Window, but does not exist for any other type of data.  (In the image below, I'm showing that the "condition" tab will enable me to pause execution when the data on the error wire I've probed is updated, and the "error" boolean of that cluster is TRUE.)

 

probe window.GIF

 

In other words, I'd like to see this behavior become more robust/flexible for other data types.  The alternatives are:

1. In run mode, put in an unconditional break point somewhere in the code, and manually step through the code as I watch the probed wire of interest update to the value of interest, so that I can continue debugging - or

2. Stop the VI an all the VIs which are running on top of it, and in edit mode, create a case structure which evaluates as TRUE whenever the wire of interest is updated with a value I care about (as in this image):

 

Work_around.gif

 

The problem with #1 is obvious - lots of lost efficiency.

 

There are several problems with #2, being that you must enter into edit mode for this work-around to debug your code:

  • I may be inheriting a lot of complex code for which the architecture is already pre-determined, so I cannot effectively influence the VI hierarchy to make this kind of breaking work-around for debugging convenient
  • I may have some other design constraint that requires me to makes breaking in this work-around inconvenient.
  • There may be a lot of data which is loaded/unloaded dynamically by the VI, so this is lost efficiency.  Perhaps I'll need to wait hours or days for the same data to occur, such that the code is back into the same state where I can take the next step.
    (There's never a guarantee that putting in just the one brekapoint will be sufficient to capture everything I need to know to debug, so this just gets me one step closer to finding out what kind of edits I need to make next, to further debug.  That iterative process would be much easier if I didn't need to enter "edit" mode.)
  • I must often make changes to my data flow in order to ensure this debugging pauses at the correct instant in time, since the value I am waiting for probably influences something later on in the code that I want to watch with Highlight Execution or whatnot.
    (e.g. above image, I cannot simply branch off of the I32 data wire to create this case structure/breakpoint work-around.  I must re-route the wire through each case of the case structure, or something equivalent, to enforce that I break at the appropriate time.)
  • VI recompiles due to edits
  • Lots of clicking to set this up
  • I must go back and undoall the edits to the code again to put it into its original state once debugging is finished.

 

So here's what I'd like to see:

 

 

Other considerations:

  1. Obviously, we can be all sorts of creative and crazy on the implementation, asking what-ifs for if you want to pause for multiple values, or an array of values, or whatever.  That's not the 90% use case.  I really only care about pausing with one, simple comparison on one primitive value (like boolean, string, integer, and floating point.) The kind of comparison would depend on the data type under investigation (e.g. you probably wouldn't need greater than, less than, etc. for boolean, and may not need them for string.)
  2. Let's say hypothetically someone implements this, and lots of people begin using it.  THEN maybe you could consider adding support for non-primitives, such as a clusters and arrays of primitives - but I make no suggestion of how to handle those in the probe watch window.  Doing comparisons on arrays would require more processing, and at that point I think the coder is on his/her own put the right hooks into the code to pause and debug when something doesn't look right.
  3. Something I could see a more immediate use for - pause in another area of the code based on an update to a wire value.  So in other words, lay down a breakpoint in one VI, and set it to conditionally pause based on a value in another VI.  This brings up a synchronization/communication problem that could possibly be resolved by setting a flag from one VI when the value updates, and when the breakpoint of the other VI recognizes that flag, it activates upon execution.  I'm sure that's more complex than my above suggestion, though.
  4. Perhaps you could do something like this with an X control (I'll admit I don't know much about them), but that requires a preconceived notion of whether or not I'll ever need to debug by pausing for a certain value on that data type.  Also, I don't really feel like creating a custom control for an I32, just so I can try to future-proof all of my debugging.

I think it would be nice to have a for loop that has an automated iteration constant in the tools/structures pallet.

This would be equivelent to a:  "for <a>  from <begin>  to <end> by <step_size>" statement in Maple. 

When start end by terminals are unwired, the loop should behave as an traditional for loop. 

 

 forFromToBy.png

 

This loop will produce an array [0.3 , 2.4 , 4.5 , 6.6 ....,4.2]

In other enviroments, such as TestStand, you can change the values of variables at run-time, which is extremely useful when debugging.  It would be really nice if you could dothe same thing with the values on wires in LabVIEW.  Perhaps this could be implemented by allowing you to change the value of a wire using the Probe Watch Window or, if that isn't possible, there could be a separate window altogether such as a dedicated variables/watch window.