LabVIEW Idea Exchange

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

I give an example to explain what I mean:

1.) Create a big array, eg 200x 200 x 200 3D-Array.

2.) Create a sub-VI with a 3D-Array input and output. Inside the VI, use the replace element function to replace one elemente of your choice.

3.) Connect the big array with your sub-VI and check the timing.

With LV8.5 I get about 200 ms for running the sub-VI. Checking the replace element function gets delta t of 0 ms! It looks like, that the output of the sub-VI has to allocate new memory for the array, even if I do not change the size of the array.

 

It would be cool, if I could create sub-VIs, which reuse pre-allocated memory for the inputs and outputs, therefore allowing a similiar effect as the inplace structure. As of how to configure this in LabVIEW you can be creative 😉 Perhaps do this with the conector pane.

 

Regards,

Marc

I haven't checked out LV2009 on Mac yet, so please let me know if this has already changed.....

 

When creating an installer on Windows, we have control of everything within the Project.  Cereate EXE, then create Installer with all options within the project.

 

On the Mac we have the options for the Application but not for the installer.  I know (After I spent a day looking for products) that Apple has an installer packager which ships with the OS (On the developer CD) but why can't we automate this from within the Project shell?  As it is I need to create the Application, then switch to an external program, create the installer (luckily it's relativel easy o use) and then to finish things off go to ANOTHER pogram to create the dmg file.

 

Please give the Mac the same Installer creation options as Windows.

 

Shane.

Sometimes I accidently click on the conditional terminal of a loop and accidently change its stop condition.  Then I may need to look at the code to figure out which condition it is supposed to stop on.  If that conditional terminal had a label, that label could be set by the programmer to say which state is desired and quickly ensure the proper state is set.  This would also help someone else who came along and looked at the code.

 

I currently set the label for Boolean constants for this same reason.

 

Type casting from a number to an enum will use only the first (highest) n bytes that it needs to do the representation.  In most cases I would argue this is contrary to what most people would expect to occur.  To remedy this case, a casting needs to be done on the numeric input before hand so that for example, the number 1 goes to the enumerated value with a number 1. 

 

My suggestion is to have a vi that is specifically designed for typecasting to an enumerated value.  This vi would be free to cast the numeric input, so as to match the enumerated input.  It could also take in an input string, and try to match the string to the strings values of the enumerated type.  I could implement this myself, and might, however it seemed like it might be useful to have that in the same panel as the typecast so that one would be more inclined to use it than the typecast, for enumerated values, and subsequently avoid the problems that come with this unexpected behavior. 

(This is a preemptive idea posting to make sure it is out there and does not get any significant votes.)

 

Don't vote for this!

(Now we will see who is paying attention :D)

 

The seasoned text programmer has problems adapting to LabVIEW because of dataflow. The concept where sections without data dependency can execute in any order really messes with the mind. We don't really want to think that way. It would be so much easier to do a literal translation of text based code to LabVIEW if we had a vertical stacked sequence!

 

Now order is restored, code executes "line" by "line", top to bottom, and all race conditions are eliminated. It also saves energy because we only use one CPU core at any given moment. Keep it green! 🙂 This structure is even Energy Star rated and might qualify for a rebate from your local utility!

 

Look at the picture! Now we have LabVIEW code that even a text programmer can understand. 😄

 

Look ma, no tunnels... no branched wires! 😮

 

Sounds good, right? Please discuss below and prove me wrong! (... and please remember the bold red text above!).

 

Did I mention that this is a bad idea? Oh, yes I did... In the title!

 

 

The idea here is to have the option to create not just a constant when connecting to a property node or indicator, but instead to have an option to connect up a bundle by name with the constant connected to it.  This would be invoked by the usual right click menu, but with extra options if a cluster is present.  I'm not exactly sure how to handle the bundle or bundle by name, but as I am partial to the arrange horizontally arangement of a cluster, it might be nice to have the option to have the constant that is created be either horizontal or vertical, via different options in the selection menu.

 ConstBundle.png

The idea is to be able to replace wires running across a case structure with terminals that take the connection on the left side and connect it to the right side.  I would think the left side should allow a through wire for reading variables, but the right side should not, as then the jumping structure wouldn't really be needed.  This is something that would be specific then to that case or entry in the structure, and not the structure itself.

 

JumpAcross.png 

When a string is the input to a case structure's selector tunnel allow selector labels to contain regular expressions.

Currently the native (by which I mean noncustom) numeric data types for shared variables are pure numbers (i.e., without units).  It is simple enough to add units to, say, a DBL numeric control and define this as a custom type, but the DSC module does not support value-based alarming for custom types.

 

Since

1) we would like to support value-based alarming AND units

and

2) I suggest this is (or should be) a very common use case

I propose that LabVIEW have numeric types with units as native shared variable data types.

 

I suggest that using units for engineering applications would be both more convenient and safer

 

I also think this would be quite simple to implementThe only question is on which unit to do the value-based alarming.  (Likely this would be on the SI unit on the wire.)

 

I have attached a very simple example that shows the current state of things.

I have done it again!  Every so often I get a VI running just the way I like it, save it (back it up as well), but when I go to use it the next time, all of my carefully chosen control values are gone.   Having seen similar problems on the forum (in both questions and answers), I am not the only one.  There is by default no keyboard shortcut to 'Make current values default', I have changed Ctrl-D (default) to do it so I usually go Ctrl-D Ctrl-S.  (Ctrl-D is set to do something else, I forget what, but I never used that shortcut anyway).  I suggest a modest change to the save dialog to add a little checkbox option (default unchecked) to 'Make current values default'.  A gentle reminder the first time we save a VI.

 

NewSaveDialog.png

I would like to see a setting on an lvlib or lvclass that would prevent private and/or protected items from showing up in the VI hierarchy.

 

In a .lvlib or .lvclass we can set different scopes on items, but why not add a property to define (on lvlib/lvclass level) which scopes that should be visible in the hierarchy view? The items listed as private in a lvlib (or lvclass), are mostly not necessary to see in the hierarchy window as these are internal anyway (and are not intended to be used or seen by the end user).


This change would mean that large scale projects could look much cleaner in the hierarchy window, and that the relationship between reuse components gets much clearer.

 

To make this work for older projects, I would also like the end user to be able to filter out private/protected items directly from the hierarchy window, as we today can filter out vi.lib, globals or controls. Turning on private view would still not reveal the items set as not-visible in the lvlib/lvclass, as this was defined by the developer.


 

When you have a lot of cases (or events) in your case (or event) structure it can be tedious to go back and forth between them (yes, Ctrl + Mouse wheel works great but can be hit and miss to get to the right one that is many cases away).  Often times I am in one case, I need to grab/do/look at something in another case and then return to the case I am working on.  It would be nice to have a Back and Forward button (similar to a web browser) so after I can quickly jump back to where I was.  The only way to do it now is to click on the case titles, scroll up/down (which can be very tedious if you have enough cases that it goes off-screen) to switch between.

Would like to target Labview embedded on a host of platforms. Specifically x86, lynuxworks, Vxworks and xilinx platforms - boards, SBCs, COMs, stacks, PC/104... Like PXI, the way to get the users onboard is to show that the industry supports this direction and you are not tied to one vendor. It would be expensive if in an iterative learning process (necessary but collaboration is also necessary with well established & matured platforms/standards) the users one chosen platform vanishes (maybe like fieldpoint?). Packaging options is also very important to achieve something like Adlink's MilSystem 800 that the application demands.

 

Pavan Bathla

  Why?

- To implement OO design patterns.

A conditional terminal for each frame of a sequence structure would allow one to exit the sequnce at any frame.  This could be useful in case something occured in one frame that meant the remaining frames should not be executed.  Easier than having to use case statements in the later frames.

 

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:

 

Currently VISA only has a single timeout value and there are use cases where a different read and write timeout is required. Today you need to constantly modify the timeout between each read and write. It would be prefered if these timeouts could be set independently.

On a Mixed Signal Graph with two plot areas, dragging the splitter that is located between the two plot areas changes the absolute height of the top plot area while keeping the height of the bottom plot area constant.   So if the splitter is dragged down to increase the top plot area height, the bottom plot area scrolls down off the graph and a vertical scrollbar appears.  I wish to keep the total sum height of all the plots constant and instead have the relative ratio of the two plot areas change when the splitter is dragged, i.e. the scrollbar would not appear and the bottom of the lower plot area would remain fixed at the bottom of the graph.  This behavior would be general for multiple plots.

Wiring an array (1 D) to a For Loop's Count (N) Terminal would automatically set the number of iterations to the array size.  This would avoid having to insert an Array Size primitive to accomplish that.