LabVIEW Idea Exchange

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

 

Batch message class should have a public static method to build a batch message that can be sent to the Time-Delayed Message.vi.

tkendall_0-1643323757644.png

 

I would like to wait xxxx ms then send three messages in order.

tkendall_1-1643323849848.png

Yes there are twelve other ways to do this but this would be much cleaner and it is an easy one change.

An add-on to the highlight execution that makes the highlight execution go into the subVIs and keeps doing highlight execution in the subVI

I would like a shared memory region accessible from both RT and FPGA. LV FGPA has memory regions accessible from anywhere in the FPGA, however you need to use DMA or front panel controls to exchange the data with RT. I envision a much larger memory region within RT's memory space where RT and FPGA could peek and poke values. The user interface would be like the current FPGA implementation with a matching interface on RT.

One of the major obstacles to LabVIEW adoption is the difficult learning curve (perhaps it’s easier than learning a text-based programming language, but still). A simple reevaluation of whether certain options are in the most logical place might help make it easier for first-time users.

 

The two that caught me up the most when I was first using LabVIEW:

  1. I expected to find the Tools Palette under Tools not under View. This tripped me up a number of times, saying, “Where on earth is the Tools Palette!?” Over the last several years I have observed a number of new users have the same difficulty. If the first place the average user looks for something is not where it is, then it is either in the wrong place or perhaps something is poorly named. The things under Tools may be better thought of as “Utilities” or something so I wouldn't keep looking for the Tools Palette there.
  2. I expected to be able to click View>>Block Diagram to view the block diagram, not Window>>Show Block Diagram. Again, you watch someone who is new to LabVIEW poking around trying to navigate and I guarantee they’ll click View before thinking to look for it under Window.

The more I use LabVIEW, the more I find things that just seem to be in weird places. I know this may seem silly, but I think it would be worthwhile to do some new usability studies on things like this.

When adding a control as a cluster constant it's important to see what's the controls name in order to use the constant correcty.

 

As you can see on the right side of the image there's how a control will be added when you drag&drop it into the block diagram.

 

Vorschlag 2.png

 

To show every label it's quite a lot of work to click on each single item (it's hard enough to hit the control correctly!) open the contect menu and select "Description" to show up.

 

It'd be a great relief, if you can simply select "Show all labels" to perform the same operation with 3 but 20 clicks.

 

Also there should be a function to automatically select if the text should be upper, lower, left or right to the constant.

Quite often I stumble over a control or indicator that truncates a value

/ because that *#~%! - programmer didn't think of it Smiley Mad

/very nice if it's a runtime, and I can't change it ....  Oh, where is the data stored? At least the drive is shown 😉 /

 

So why not always display the full value in the help window ?

 

Full value in Help window.png

The current way to bind many shared variables to an OPC client, is through browsing a tree and selecting.

This is very time consuming when you have hundrends or thousands of tags to bind. Specialy if the all the tags are not in the same path.

A better way, is to bind the variables, by simple text.

Example: We will insert the following text

A1M01Z1:value

A2M01Z1:value

A3M01Z1:value

 

and LabVIEW will automatically create 3 variables, bounding to those addresses (with the same name, prefered). Many OPC Servers supports this type of address.

Note that the true path of A1M01Z1 could be something very big, like:

My Computer\OPC ABB.lvlib\_OPC1\[Control Structure]\Root\NETWORK 1\Nodecm3\Extended Process Objects\MB300 AI\A1M01Z1\VALUE

 

This way you can add thousands of items in minutes. It is quite easy for the R&D team to implement and will help many professional engineers.

Most probably, this idea will not accept many kudos, but i think R&D must consider to implement this.

 

(this was discussed with NI technical suport, Reference#3279019)

 

Thank you all, for reading

Please add to AF:

Interface based messaging. The need to create messages for all communication is a major decrease in productivity and speed of actor programming. It also decreases readability. It is a better with the BD Preview in Choose Implementation Dialog in LV19, but still.

 

I wish there was a simple check box or rotation option for the Y-Axis name label on charts/graphs rather than having to do it programmatically.

 

Here is what I mean:

 

Y-Axis.PNG 

 

I emailed tech support and they confirmed there is no direct way but sent me a workaround which I've attached for reference.

 

Regards

 

Mitch

A value change for the autoscale setting of a graph / chart scale is currently not registered. It can only be detected by polling for the scalefit value. The range of detectable events on charts and graphs is currently incomplete. The scale range change event and the autoscale range change event trigger at the same time in unpredictable order. This makes it hard to detect whether a user manually adjusted scale minimum and maximum or adjusted the autoscale settings value in the scale attribute. Different user actions all trigger a scale range change event without any way to discriminate the cause of this event. 

Allow type casting between Strictly Typed VI References

TypeCastVI.png

Why:

The asynchronous methods require strictly typed VIs. Strictly typed VIs depend on the connector pane and terminal wiring type (Required, Recommended, Optional). Depending on your development environment and configuration options (Front Panel > Connector pane terminals default to required), newly connected terminals may be Required -or- Recommended. 

Opening a VI reference or calling an async method with the wrong terminal wiring type will result in Error 1057: Type mismatch. 

TypeCastVI_Justification2.png

To work around the connector pane variance, we need to type cast check every connector pane terminal variance in order to call the proper async method without getting the Type Mismatch error.

TypeCastVI_Current.png

The amount of unnecessary complexity to call and collect a thread is infuriating. There is already enough complexity when it comes to spawning a new threads; between the conditional options (Non-Reentrant, Reentrant, Async Forget, Async Collect), VI type specifier (Generic, Strict), Connector Pane Type (Pattern, Rotation), Terminal Wiring Types (Required, Recommended, Optional), etc. Threading in LabVIEW needs improvement.

Idea:

To better support Asynchronous calls, we need the ability type cast the required strictly typed VIs to:

1. Add an option to Start Asynchronous Call and Wait on Asynchronous Call methods to ignore the VI terminal wiring type flags:

     Required (0x21000), Recommended (0x20800), Optional (0x20000)

2. Support type casting VIs To More Generic Type and To More Specific Type to avoid the error 1057 Type Mismatch all together

TypeCastVI_Idea.png

Regards,

A LabVIEW Enthusiast 

>90% of the time when I need a File Path Control I never need it in the default Selection Modes "Files" and "Existing". My idea: change the default state to the more generic "Files or Folders" and "New or Existing". Or at the very least make it an option.

Add a confirmation dialogue when changing type definition to control. I just experienced changing a type definition to a control by mistake and was scared until i realised that if i just kill LabVIEW at this moment that it would work as an undo. Of course undoing all the other changes also.

 

A simple are you sure dialogue wouldn't be so annoying as this happens rarely and don't believe that it would require lots of resources to implement.

If an error occurred inside a case/event structure, it should include the case/event name in the error source for easy tracking.

It'll save tons of time for large applications with a lot of cases in the process loop.

 

I know I can do it myself.  Just something better to have with a right click.

 

Untitled.png

 

 

How often do you find the need to orginize data into a table format while documenting your vi?  I for one, could & would use it all the time!  Creating a resizable table free label we all use in word & excel seems like a simple task and would aid in organizing and documenting data into a more readable format.  A ctrl+double-click or shift+double-click could serve as an easy access method, tab through the contents, and resize rows and colulmns vis a cursor change while hovering at the specific borders.  Free Label, New type, table format, organize data, rows, columns. 

 

Free Label Table.png

I sometimes need to add (paste) text documentation to the block diagram. This often results in a single line of text that can stretch, as a single line, for what seems like miles off to the right of the text-block insertion point.   I then need to make multiple drag-edge/shift-block/repeat adjustments to beat the text block down to something that will fit on the screen.   It would be nice to instead be able to select the text block and either specify a width or else say to make it the same width as something else on the block diagram.

 

Scroll bars in text blocks would be nice too, as long as I am wishing.

In response to another post, Darren suggested someone start a new topic about how to more effectively spread information about new or esoteric features (sometimes referred to as "tribal knowledge").

One idea is to have a database of these gems and display one at random during the splash screen.  So, while we are waiting for LabVIEW to start, we can learn a potentially useful "trick", if we care to.

 

Example:  "Control-click on some primitives will reverse the order of the inputs.  By also holding Shift, any inversions will follow the connections."

(Note:  the second have of this example is not actually implemented yet.)

Two more suggestions

 

There has also been a need for rising edge and falling edge triggers for boolean values instead of having to manually code this in every time.  I know this would take extra memory space but could be turned on or off maybe in the control settings dialog.

 

I also have to manually code in time delay functions because everything I do is in loops with parallel code.  The timers can't execute properly this way and would be nice to be able to use the built-in timing functions instead of hand-coding.

I find the new Channel wires very useful things! However, I really miss one type/variation which would make a real many-to-many lossless message sending possible, but also with total control over where the msgs end up in case of multiple readers! Imagine that we have a Channel wire which can be branched, and you can also specify a "destination label" (could be a number, or string, etc.) at the Write nodes. This new Channel type would allow multiple Write and Read nodes. At the Read nodes, we could also specify the "destination label", so ONLY those Reader nodes would get the actual message which are subscribed for that particular "label".

 

I can program this functionality, but it would be great to have such features in a single Channel wire...

What do you think? Is this a good idea or you see some caveats/downsides of such Channel?