LabVIEW Idea Exchange

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

I installed LabVIEW 2020 on my PC and my friend is working with LabVIEW 2016 every time I open his projekt now it gets upconverted and if I downconvert it to 2016 I can only do it via the special option, which does not even allow me to overwrite the original 2016 files. Iam stuck with 2020 since I did not buy SSP GREAT, how is this in any way userfriendly? Its worse then the compatibility of Word with Libre office.

 

That was Bryans original post 12 years ago, its still the same.

https://forums.ni.com/t5/LabVIEW/How-do-I-continue-to-save-for-previous-version/m-p/4143151#M1194547

pbpatel_0-1617942167348.png

It would be nice to have this facility for splitter lovers.

while loop can stop/continue on Boolean or Error, why not also on default value.

 

gnilsson_1-1613944658719.png

Could be

gnilsson_2-1613944794749.png

 

Report Writer BEFORE WIndows 10 was SUPER ROBUST! Now that Windows 10 came along there exist many "turds" left in the Registry when folks UPGRADE from Office 7 to Office 10.

What happens is the Registry NEVER NEEDED to be kept clean of extra junk because NOBODY EVER UPDATED Office.

 

Now every Joe on the planet updates their Windows 10 with the latest Office 10..


What happens if they do NOT FIRST UNINSTALL, is the Registry is left with "turds"


When Report Writer uses ActiveX to make calls to use Word, in the old days, there was a SINGLE key in the registry to allow the calling program to gracefully start Word or Excel, or whatever.


NOW< with Windows 10 there are FREQUENTLY multiple "keys" in a Registry that causxe the LabVIEW Report Writer to "Gag" and "Hang up" doing nothing.


The SOLUTION is for the Report Writer to PARSE the Registry for valid keys and allow the request to be passed to the propper called process.

 

If this is not clear, please look up the SR below. There are a TON of examples and videos explaining how to fix it.

 

I have been working with LV since Dr. G was roaming the halls on LV 3...

 

This is the FIRST TIME Report Writer has gotten "sick".


This is an EASY FIX for the devs and since Report Writer is a purchased plugin they sould be able to update it so it works well.

 

Currently, they have us fiddling with the Registry or telling customers to uninstall and reinstall Office. That is a BIG FAT NO-NO to big companies because Office WORKS COMPLETELY for them and even programs like SolidWorks and DXP that use Word and Excel for stuff.

 

My number 831-455-0418

 

DEVS:

Please see: Request #: 00994109] Can not get EXE BUilder to run on WIn 10

 

The code below will execute without error or warning. The value returned will be 127 in this case.

 

Why is that? I understand the error 91 is returned if the typedefs are incompatible but if the type is different but compatible I would expect a warning maybe?

 

Cheers,

Jimmy

 

var.png

Hello!

how hard it would have been to include a fancy NXG Style scroll bar like this that would could use anywhere in our VIs?

 

Is it because the scrollbar doesn't exist in LabVIEW NXG? Is it possible to customize one by myself?

 

Cheers,

Jimmy

 

NXG Scrollbar.PNG

Through normal programming this can be done, but it does take someone that really understands the problem and how to deal with it.  My proposal would be more useful for a new to intermediate user or when all that's needed is a simple and quick solution.  

 

It would work like this:

 

A simple "Data Control" Express Node that could take data acquired using modules that run at different speeds (like a NI 9211 and a NI 9239 running on a cDaq chassis), that would automatically control the buffer size (through averaging as one option) to prevent a program crash.  Then output the data at a equally consistent rate which could then be graphed or logged at a set rate as determined by a user.

 

As we know if a 9211 is running at 4Hz and a 9239 is running at 20Hz, that could produce a buffer over run.  I'm suggesting that a "Data Control" node be written that a programmer could use to graph and log data at a selectable rate no higher than the slowest module.  In my 9211 & 9239 example it would be 4Hz or less, and that would occur because internally it would be automatically averaging the 9239 data.  If a lower speed is selected (like 1Hz) then both would get averaged before the data gets output at 1Hz.

After selecting "Add Event Case...", place the cursor in the "filter' field so I can immediately start typing the name of the control.

KeyfocusEventFilter.png

Dear Hot Shot Devs!

thousands of us want to be able to build a mobile app from LabVIEW!!!


Can you imagine??

 

All that power with full responsive features on any device, like Swift and Android Studio??

 

you can “hook into” those tools to let us design the User Interface and evening do Bluetooth and Wireless with all’s y’all’s stacks and wizardry!!

 

Consider me as an Alpha tester. I know what is needed. Let me know the plans!

 

I have been using LabVIEW since before rev 3.0 when we could actually talk to Dr G!!


great work you are doing. Sometimes I do not enjoy the “abstractions” you do to make it easy. Kind of liked the good ole “bit banging” direct link to Comms and I/O but I understand.

Front Panel array controls and indicators could have an optional (by default off) array dimensions field just under the array indices fields, that would display the current array dimensions and allow changing them if the array could be edited, such as for a control or for an indicator when not running.

 

If an array dimension is increased, it would fill in with the default value. If an array dimension is decreased, it would shorten by cutting from the end.

I initially came here to suggest that there should be an exclusion added for error terminals when selecting the option in Tools > Options... > Front Panel. But then I thought, why not just let us configure which data types default to required and which default to recommended. I'm probably being nit picky here, but I think this would be a really cool thing to add.

 

Check the box, then a nested list underneath, where you can add exclusions, becomes un-grayed out. Data types you don't want to default to required.

 

FireFist-Redhawk_2-1598535516598.png

 

It would be useful if the Search Results window would show the number of callers not in memory (screenshot 1).

 

1. The Search Results window, with extra information about the number of callers not in memory

Find all instances 1-edited.png

 

Screenshot 1 was generated by right-clicking the icon of 'SubVI.vi' and selecting 'Find all instances'. The dummy project is shown in screenshot 2. Screenshot 3 shows the Find Callers window that pops up when right-clicking SubVI.vi in the project and selecting Find>Callers.

 

2. The project

Find all instances 3.png

 

3. The Find Callers window

Find all instances 2.png

 

When refactoring, it is often necessary to find and replace all instances of a VI, before removing that VI from the project. A typical workflow for me would be:

  • Open the main VI of the application (to load in memory as many subVIs as possible)
  • Open the VI to be replaced/removed from the project, right-click its icon and select 'Find all instances'
  • Navigate to each instance replacing/removing the VI as necessary
  • Ctrl-Shift-E to select the VI in the project, right click the VI and select Find>Callers.
    • This sometimes brings up callers such as tester VIs that are not loaded in memory by the main VI of the app. In this case:
      • Open each caller previously not in memory. Use 'Find all instances' again.
      • Final check: Use Find>Callers one last time to ensure no callers.
    • This sometimes shows 'No items were found'.*
  • Remove VI from project and disk

*If the number of callers that are not in memory was displayed in the Search Results window, and if that number was 0, it would remove the need to check via 'Find>Callers' before removing the VI from the project.

 

The 'Find all instances' feature would become more complete if it displayed information about callers not in memory.

 

Thanks!

The idea is to add a return value option to user events:

Create User Event.PNG

Event Structure.PNG

Generate User Event.PNG

If there are multiple event registrations, the return value is passed through them. Pretty much like existing filter event.

 

Optional icing on the cake:

Spoiler

The Generate user event could be split up in a send and receive part.

 

A time out could be added to the receive as well. 

 

Waiting for return data could be optional. The data will still propagate though all registered event structures. 

 

Disclaimer

Spoiler
I've read all "User Event" search hits on the idea exchange. Closest\only related one I could find was Register-User-Event-as-Filter-event, which is mostly concerned about discarding the event. But the idea exchange search is terrible, so it could be right under my nose...

 

I have two arrays I'd like to pivot into an array of clusters of a particular typedef. I could index and bundle it myself, but it's just weird that I can't use this builtin function just because the typedef has an element that's an array.

 

Also, it's kinda weird that it won't take a typedef as prototype. Casting it after takes up about as much room as doing the bundle in a loop!

 

I can see some reasons that letting us pass in 2D arrays would lose the tight optimization of the original (maybe it can compile-time determine the size of the cluster elements if none of them are arrays... except that you can put in object data. I guess either that's a reference under the hood, or there's some other reason)

 

Or maybe it's that it could cause confusion between making a 1D array of clusters with 1D arrays, or making a 2D array of clusters of single elements? That seems like it could be solved either by only doing the former, or requiring a typedef in that case, to disambiguate.

If you are instantiating classes dynamically or calling VIs dynamically through VI server, you may need to include the source files under "Always Included" when creating a build. If you are dealing with a large number of files in a multi-developer environment, you might also be using an auto-populated virtual directory. The problem with this is that everything under directory will be included in the build. Say you are building a hardware abstraction layer with 100s of different instrument drivers, you will likely have all sorts of different files like programming manuals, unit tests, project files, lower level instrument libraries, and VI trees. You might not want all of these files included in the build. Some of the files might not even compile (ie. VI Trees), which will prevent you from creating a successful build. If you are instantiating the classes dynamically, all you really need to do is include the lvclass files since that will automatically bring in the dependencies for that class. You could separate these files, but it would likely be a less cohesive directory hierarchy. For example, if a developer is implementing a driver they will probably want to access the programming manual under the same directory hierarchy, while at the same time, a programming manual probably wouldn't be beneficial to a user when the build is deployed so you might not want it included.  Being able to define 1 or more file type patterns on either auto-populating virtual directories or on the build specification UI for source files, would quickly resolve this issue.

When right-clicking on a VI in a class, there's an option to "Remove From Library".  This option removes the VI from the library, but leaves the file on disk.

 

95% of the time that I'm removing a file from a class, I'd also like to delete it from disk.

 

The wording might need a bit of work, but it'd be great if there was an option to simply "Delete" or "Remove From Library and Delete".

 

(In the meantime, I'll continue to "Explore...", then "Remove From Library", then delete from my file system.)

 

carls___1-1590689294408.png

 

When working with classes, you can modify "Access Scope" for VIs either by right-clicking on the VI, or by going to Items Settings section of class properties.

 

carls___0-1590686557507.png

 

However, in order to change override settings for a VI, you must go to the class properties page.  These are not accessible through the right-click menu on VIs.

carls___1-1590686651627.png

 

It'd be quite convenient if these override options were also available through the right-click menu.


I think it would be really useful to have a Quick Drop shortcut installed by default that toggles label visibility for selected items. I know you can select multiple objects and right click> Visible items> Label but this takes me several seconds.

 

How I imagine it would work
Select GObjects on front panel or block diagram --> Ctrl+space, Ctrl+L --> label appears if it wasn't visible or disappears if it was visible.


If multiple items selected with a mixture of visible and non-visible labels, use the same logic as what happens when you try to embolden partially bolded text : toggle all to the opposite of the most frequent state.

 

I might write something that does this, but it would be really great if it was standard. 🙂

hi forum

 

always find it difficult to read the subdiagram label whenever the structure exceeded 2 screen widths (when avoiding stacked sequences). Can we have subdiagram labels that will always be visible, like its text will center itself within the subdiagram label portion that is within the viewable workspace, or left adjusted when the label text length exceeded the subdiagram label space.

It would be great if we could close the documentation editor window by entering <Shift> + Enter.  Several other LabVIEW IDE dialogs and text entry objects work this way already.  We can open the properties with a keyboard shortcut, and if we were last using the documentation, no mouse work is needed, except to close the dialog.  When I already have both hands on the keyboard, it would be nice to not have to grab the mouse just to close the dialog.

 

 

 

Edited to suggest using unused modifier key, Ctrl is already taken.