LabVIEW Idea Exchange

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

Swap Long.jpg

(hope this hasn't been posted before, couldn't find it)

 

Since we now have 64 bit numbers, can we please have a Swap Long function?

 

This is a real hassle to do yourself (convert to byte array, rotate array, convert back? or flatten to string, flatten back with different byte order?). If you have large arrays of "quads", it is a real performance hit without the function.

 

Regards,

 

Wiebe.

The shortcut menu should launch the new type def.'s front panel when 'Make Type Def.' is selected. You will need to save it anyway, and if you find the need to edit it right away, then it is already open and ready to go.

 

make type def.jpg

While debugging my application I became curious that if an easy way finding the error is available how the things will be. Am not sure somebody has proposed it already, am giving my suggestion. The VI can have the option of pausing it when an error occurs anywhere in that VI.

 

Error Handling.png

 

 

I guess this would help us much better way of debugging an application.

I want to be able to work on STABLE versions of LV.

 

The last great stable version I remember was 6.1 (I never had 7.1).

 

2009 and 8.5.1 were not bad but please give us a feature-fixed long-term support version of LabVIEW.

 

For anyone unfamiliar with the idea, many Linux distributions offer the same:  Here's a link to the Ubuntu webpage outlining THEIR LTS strategy.

 

Shane.

I often have a situation where certain code parts don't really need to be recalcuated, because their inputs have not changed from an earlier encounter.

 

For example if a function is the sum of two different complicated and slow calculations where each of the two depend on a different subset of parameters, often only one needs to be recalculated, while the other intermediary result could be grabbed from a cached value. (This occurs for example during the calcuation of partial derivatives).

 

In some cases, the compiler could probably recognize these situations, but I think we should have a special structure to allow caching of intermediary results.

 

I typically use a case structure and two feedback nodes as shown in the example on the left. If the value is different, the code in the TRUE case is executed, else the value stored in the SR is returned immediately. (If the code depends on several values, I bundle them all before the comparison operation)

 

I propose an simple Caching Structure as show on the right that retains that same functionality with less baggage.

 

 

Details: The containing code is calculated at first run and stored in the output tunnel. In later calls, it is either (A) recalculated, or (B) the previously stored value returned at the output tunnels. Recalculation only occurs under some conditions (.i.e. usually when actually needed)

 

The structure has the following features:


  • Two possible types of input tunnels (the functionality is indicated by a different look).
    1. One where a value change triggers a recalcuation of the containing code
    2. One where a value change does not trigger a recalculation of the containing code
  • A special boolean terminal to force a recalculation unconditionally
  • output tunnels that retain data between calls

There can be an unlimited number of input and output tunnels of any type described above. A recalculation of the inner code occurs if any of the triggering tunnels have a changed value.

 

We can think of it similar to "short-term folding". 

We are logging shared variables with the citadel database via the variable logging. In some cases (reset of PC ...) citadel makes a repair of the database after restart. When having databases greater than 20-30 GB this operation takes at least one hour. During this operation the Shared Variable Engine is not responding. When using the shared variables not only for logging purpose but also for controlling options and visualizations on that same pc this is very critical - this stops also the production for one hour.

 

It will be better to activate the Shared Variable Engine although during the repairing process of the database. We could pass on the data during the logging process but not on the controlling part of that aggregate.

 

Best Regards,

 

--

Joachim

The current typecast function does do a buffer allocation and copy operation even if a inplace typecast would be possible.

 

Please optimize the current function or provide an advanced version of the it.

 

Original discussion: Lava - Inplace Typecast possible?

Deallocate Queue Memory.PNG

 

Many people do not realize that memory allocated by a queue is never deallocated until the queue is destroyed or the call-chain that created the queue stops running.  This is problematic for queues that are opened at the beginning of the application and used throughout because all of the queues will always retain their maximum size, causing the application to potentially hold a lot of memory that is currently unused or seldomly used.

 

Consider a consumer that occassionally lags behind and the size of a queue will grow tremendously.  Then the consumer picks back up and services the elements out of the queue in a short period of time.  It is unlikely the queue will be this large again for quite some time, but unfortunately no memory will be deallocated.

 

I'd like a primitive that will deallocate all of that memory down to just the current number of elements in the queue.  Since the queue won't need that much memory again for a long time and the queue will auto-grow again as needed, I'd like to recover that memory now instead of waiting for the application to be restarted (which is currently the only time the queue is created.)

 

The alternative is to add some code to periodically force destroy the queue and have the consumer gracefully handle the error and open a new reference.  Then replicate this change for all queues.  Seems messy and puts too much responsibility on the consumer.  I'd rather just periodically call a 'deallocate queue memory' primitive on the queue reference within the producer, perhaps once every few minutes, just to be sure none of the queues are needlessly holding a large amount of memory.

 

I believe this will:

  • Improve performance in other areas of the application because less time will be spent looking for available memory to allocate.
  • Reduce the chance of Out of Memory errors because large blocks of memory will not be held [much] longer than they are needed.
  • Improve the common user opinion that LabVIEW applications are memory hogs or leaky.

I realize this will hurt enqueue performance when the queue begins to grow quickly again, but this area is not a bottleneck for my application.

 

Thanks!

Here is an idea that I have wanted to make happen for a while. It is the Asyncronous Call By Reference. Basically, it is just a Call By Reference, but split in half so that the call is not syncronous (blocking), and return data can be obtained from multiple locations.  Plus, there should be ways to check the status of the asynchronous call and kill it.  I've even implemented this, to some degree, here http://forums.openg.org/index.php?showtopic=88
 
 
Message Edited by Jim Kring on 06-10-2009 08:14 AM

It's been great to be able to find Items with No Callers in Project. How about Find Broken VIs as well?

 

FindBroken.png

Idea:

Double-click to a wire + holding <ctrl> or <alt> will call the wire-cleanup tool for this particular line => much faster than via context menu

cleanup

I really think this is a bug, but I'm going to file this as a feature request, just to add more weight to the issue...

 

The VI Server Application method Library.Get File LV Version claims to be able to tell you the version of a Library (or XControl, XNode, LVClass) on disk, without loading it into memory.

 

noname.gif

 

Here are the docs:

 

12-1-2010 4-18-09 PM.png

 

But, when you try to call this method on a Library saved in a version of LabVIEW newer than the version of LabVIEW in which the method is executing, you get the following error:

 

Error 1125 (LabVIEW: File version is later than the current LabVIEW version.)

 

Why an error?  It had to read the version in order to generate the error.  Why not just return the version?

 

Thanks in advance for your kudos 🙂

On a For Loop that is configured to have parallel iterations there is a nifty feature when using errors on a shift register.  This feature is explained in an article here.  It basically ensures that For Loops that run 0 times, will preserve the incoming error as if the tunnel was a shift register.  However this feature also means that errors from iteration 0, won't be passed into iteration 1.  What is returned if the loop runs 0 times is just the incoming error.  But if it runs for more than that, the errors are all merged and returned will be the first error seen.

 

Untitled.png

This idea is just to allow this already existing feature to work on non-parallel configured For Loops.  When would this be useful?  Say I want to delete an array of files.  I want to attempt to delete all files, even if there is an error in trying to delete some, just keep trying to delete the other files.  Initially you may think this:

 

Untitled2.png

But that has the clear problem that if the incoming array is empty, then the error will be cleared.  So we often do something like this.

Untitled3.png

And honestly this bit of code isn't that big of a deal, but this feature already exists.  However it only works on For Loops that are configured to run iterations in parallel.  In this case I might be attempting to delete files in a specific order due to their placement on disk, and running in parallel isn't what I want.

 

Since not everyone wants all errors in loops to act this way it would need to be a right click menu to turn the tunnel into a normal one, a shift registered one, or a preserve and merge one.

Untitled4.png

That is what I want.

Currently, the VariantDataType  are buried deep in VI lib but they are very useful when trying to program based on datatype. Can we bring some of those functions into the light?

 

https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-10-05-2009/m-p/996866

https://forums.ni.com/t5/LabVIEW/Darren-s-Occasional-Nugget-03-25-2014/m-p/2791974

 

Get items from enum

Hi, i wanted to suggest the creation of a separate utility software that would convert a VI from any version to any other version. This would save people a lot of time by not waiting to get it converted from their respective threads. Also it would serve for more people to able to reply on the forum(me included since i am using LabVIEW 8.6 and most of the posts contain VIs made in 2009 and 2010 even though most of the time the same functions are avalable in 8.6 😞 ).

 

 

PS: Sorry, got no pictures

 

So many times, Darren's history probes have been a great help while debugging my code ! This concept may be enhanced. But at least, these probes should ship with the LabVIEW installer.

After 2011 we have the option to ignore all the missing vi's which are missing. But after loading the project if a vi is loaded and if it has a missing vi then there is no way to check from where it has to be loaded (Expected path of the missing vi). So it would be a good option to check the Expected path of the missing vi after loading its caller (May be in the properties of the missing vi).

Apparently VI Analyzer toolkit doesn't support any 64bit LabVIEW version, this is really something I miss!

 

With all the good reasons to use it that NI gives it's hard to understand!

When building Installers for an updated version of an executable, you can't select whether or not to overwrite the current source files directory. The reason this is a problem is when distributing to computers that need different configuration files that are installed with the original version but have since been customized to the specific computer. If you try to only include certain source files and not others then it still overwrites the entire directory and you lose the files you were trying to save. If there was an option in the Source File Settings window to "Overwrite", it could be automatically checked for the same default functionality but you could uncheck it to allow writing into existing directories.

 

Source File Settings.png

 

If you like this idea then give me some Kudos and hopefully we can get it in the next version of LabVIEW!

 

Peter W.

Applications Engineering

National Instruments

www.ni.com/support

I would like to see the Join and Split Numbers function to be expandable and polymorphic. I’m not arguing big vs little. Just accept there are two Endian worlds and work with them. Have you ever joined two or four numbers from a data stream in Little Endian? You have to change the order and cross wires as shown in figure (1).

Join Numbers Figure 1.GIF

This is not that clean and it gets worse when you need to split numbers and send them back to a device. Because I join and split a lot of numbers I created a library of vi’s that are clean on the diagram and visually indicate Big vs. Little Endian. A simple arrow works for me to indicate Big vs. Little Endian shown in figure (2). This Library is also attached.

Join Numbers Figure 2.GIF

I know the Join and Split two numbers in Big Endian is the same function in LabVIEW. This provide visual consistence on my block diagrams. An example of block diagram code that shows the difference between Big and Little Endian form is shown below in figure (3).

Join Numbers Figure 3.GIF

Here is what I would like to see National Instruments create. Make the Join and Split Numbers function to be expandable and polymorphic. The words are only going to get bigger and there will always be two Endian worlds. Make the Join and Split Numbers vi’s expand like the build array function. Click and drag possibly in groups of 2 i.e. 2, 4, 6 and 8 inputs or outputs for the Split Numbers vi. Of course the output data type would correspond to the number input connections. The polymorphic examples are shown below in figure 4.

Join Numbers Figure 4.GIF

To take the polymorphic function one step further it could include the data type. There are times when I need to join numbers and convert to a signed integer or a double floating point. A demonstration of the polymorphic data type is shown in figure 5 and 6 with before and after examples.

Join Numbers Figure 5.GIF

Expanding the functionality of the Join and Split Number vi’s will reduce block diagram clutter, increase coding speed and maintain visual readability. What do you think?