LabVIEW Idea Exchange

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

good day forum

 

propose the above, simply for:

 

- automatically building the web panel by populating the control types on the original referenced VI, adding and styling it with the GWeb control style

- automatically linking the referenced vi's and gviweb's controls

- execution mode: clone per session (default, specified connection limit), & single login session; to prevent race

- if VI reference stopped running, broken, missing or irrecoverable error, return 404

 

to reduce recoding works

 

*cannot find appropriate labels in "additional idea" thread, kindly relocate post to appropriate thread, TQ

if only LabVIEW can read and write PDF files, since it is already an open format. needless to say for the function of writing in report generation, but reading from PDF can also provide: text, picture or even CAD data that can then be used from automated mass data entry, QC vision inspection (CAD vs fabricated), augmented reality visualization of measurements (temperature, stress, vibration, etc) and much more...

 

if only...

Interfaces are a great improvement in LabVIEW OOP. For me steepest learning curve was in figuring out how to implement default behavior when interface class doesn't have a private data control.
For example I have created Collectable interface (inspired by iterable interface found in other languages). It has default implementation for methods like Next and Add. It has accessors methods like Read and Write Items, which descendants must override.
When I create a new class which inherits from my Collectable interface, I need to override those accessors, and manually add required controls to new class private data control, and unbundle/bundle elements, and wire the controls and indicators.

data accessorsdata accessors

My idea is that there should be a tool to do automate this code generation.

 

I think the straight forward way would be to use scripting and project providers to create something similar to Actor Framework Create message etc. tools. 
But a more fundamental change would be to implement this as part of property definition folders and property nodes. Which I think in this case should be in protected scope by default.

property nodesproperty nodes

The Collectable interface can be found from lavag.org 

It makes no sense to write the channel name every time with TDMS write. You could easily improve write performance and disk utilization if you stored the channel names once and used a smaller alias to them (see example below). There are other work arounds including buffering

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9reSAC&l=en-US

But the downside of buffering is that the data is stored in memory so if you lost power, you would potentially be missing a large chunk of data. Also, this solution is compatible with the buffering idea in that this would make the files even smaller.

In my example even after just 100 writes, the example using the lookup table is 20% smaller.

We can also get even bigger gains if instead of using hex-ascii strings for the short names, we used an integer.

 

TDMS long name lookup.png

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.

It has been needed for a very long time to have web accessible front panels.  During the development of NXG this problem was solved with the web module.  I am not sure why they stopped development with NXG because was an extremely nice upgrade and was making Labview more future-proof.  NXG was then turned into G web development software.  Personally, I think the web portion should be an addon and native to Labview as eventually, that is where it will need to go anyway.  In the meantime, the only solution we would have is to possibly use G Web Development software as a front end development and regular labview as a backend.  To do this cleanly we would really need the shared variables available in G web development environment.  This would open back up doors that were closed once NXG was not supported anymore and would offer a solution until something native is added to Labview.  In my world, every customer wants and expects web-accessible applications.  I get the response all the time "Your software can do all of this control but isn't accessible from a browser on our LAN - my residential doorbell can even do that".  If I am missing some method to implement this currently (other than SystemLink) please reach out and I appreciate you considering some kind of solution to fill this very large need.

 

PS - I still don't understand why NXG support stopped if anybody knows.  Took a little getting used to but I saw big potential with that development software.   

Add a right click menu item to "Boolean Array to Number.vi" for selection of the output data type. Currently this is buried inside the Properties and is not easy to find.

When building a PPL or exe that's dependent on another PPL, LabVIEW creates the pathing automatically. I would like to specify their new location manually as part of my build spec.

 

Currently here are my options:

 

1- Select "Exclude dependent packed libraries" with PPL and target location on the same drive:

The new PPL or exe will have a relative link between the target build location and the existing PPL. This doesn't work if you want to build your exe to a /builds directory and your PPL is in vi.lib.

 

2- "Exclude dependent" with PPL and target location on different drives:

This creates an absolute path to the PPL, which is basically never what you want.

 

3- Don't "Exclude dependent": This will let you specify a layout for your new exe or PPL manually and, as long as your upstream PPL's are configured correctly, you can specify the final layout for your new build. This lets you organize your PPL's differently for development and for release, which can be handy, but it duplicates the dependencies.

 

I'd like a 4th option- "Act like you're going to include dependent PPL's, and let me organize new folders for them, but don't actually copy them over." I can somewhat do this right now, but it copies the dependent PPL's into my /builds directory for each build I do. I then have to delete them if I do another build that references them. If I don't delete them, LabVIEW complains that the dependency already exists at the target location.

 

I could accomplish this with a custom post build VI but it would have to be manually configured for each build. If I could just check a box for "Don't actually copy this here, but link it like you did copy it here" then I could do everything within the build spec.

I think it would be very nice to add these. A common task is to get object position/sizing pixel perfect. Adding these buttons would help tremendously with that, there is plenty of space for them, and I feel like it would be a minor developmental effort. Upvote if you like it, thanks for reading 😀

 

FireFistRedhawk_0-1638369163977.png

 

Splitters bars are tricky to position exactly. It's a two-step process (because you have to move both sides), and even then it's frustratingly difficult to get them aligned to the pixel where you want them (especially with grids enabled, because they edges will want to stick to grid lines).

_carl_0-1638206727315.png

As with other front panel controls, it's be quite useful to be able to just select the splitter bar, and then use keyboard arrow keys to move it up and down (or left and right for vertical splitters).

 

(Apologies if this has been posted already, but my search didn't find it!)

When manually analysing a project, we can set the target in which the VIs should be loaded. Unfortunately, VIs with RT code are often broken under windows, leading to wrong test results, or even worse, pop-ups asking for VIs.

 

Please add an Application Reference Input for the VIAn Run.v.

 

Maybe this option could also be useful set in the VI Analyzer configuration file?

It's great that the native "Random Number (Range)" VI was added to LabVIEW relatively recently (LabVIEW 2020 I believe).

Currently the VI has instances only for U64, I64 and DBL, as seen below.
1.png

 

It would be great if it had instances for all integer types, especially for I32 which is probably the most common integer type. I am aware that we can easily convert from U64, I64 and DBL to any desired integer type, but it would be nice to remove the need to convert the output.

Thanks

Many or most VIs that ship with LabVIEW have their protection set to Unlocked (no password). The screenshot below shows a selection of such VIs.

1.png

 

It would be much better if the protection of vi.lib VIs was set to "Locked (no password)", to prevent accidental modification.

2.png

 

It seems very risky for built-in VIs to be open to modification, especially to accidental modification.

 

Scenario 1: Developer A is developing an application on their machine which contains modified vi.lib VIs which were accidentally modified as part of work on previous projects. They build an application which passes validation and starts to be used in production. All of the developer's source code is committed to a source code repository. Developer A leaves the company. Six months later Developer B is asked to pull the code from the repository and add a minor improvement. The application behaves very differently when Developer B builds it on their machine. A long and complicated troubleshooting session later, Developer B concludes that the different behaviour was likely caused by modified vi.lib VIs on Developer A's machine. Developer B cannot be sure, because Developer A's machine was wiped when they left, so there is no way to unequivocally prove the conclusion.

 

Scenario 2: A team of developers builds a test system for a defence application. The code is completed, and the test system is put through a thorough  commissioning and validation process that involves testing dozens of known good units and known bad units. The validation process takes three weeks to complete. Management plans to not have to run the whole validation process for future minor changes. Instead they will ask the development team to perform code reviews and record notes for each minor change. Revalidation is not necessary if the code reviewers agree that the changes are non-functional, for example, the wording was changed in a dialogue message, or a logo was added to the UI. This sounds like a great plan, but is technically unsafe. Strictly speaking the whole revalidation process would have to be rerun, even for minor changes, due to the fact that not all of the source code is visible in the repository (there is uncontrolled source code in vi.lib that could have been modified in between builds).

Essentially I don't think it's safe for an app to contain source code that is not visible or tracked in a repository.

I can't think of a simple, quick solution to the concerns above, but having all vi.lib VIs set to "Locked (no password)" could be a quick first step towards reducing the likelihood of this issue. Developers would at least have to consciously edit vi.lib VIs, rather than doing it accidentally which can happen now. Of course, a malicious actor could still wreak havoc by editing a few inconspicuous vi.lib VIs.

The risk would be reduced further if the vi.lib VIs were password-protected. This would come at the expense of not being able to view the source code of native VIs, something which I find useful. Therefore, I personally would prefer "Locked (no password)" to password-protected, but I might prefer password-protected to unlocked.

Similar concerns apply to non-NI third-party libraries that install in vi.lib, user.lib or instr.lib, for example the extremely useful OpenG libraries. These too are examples of uncontrolled source code. For this reason some developers I worked with preferred to copy the OpenG and other libraries into the project repository (this involves a tedious job of opening each library VI and relinking it to the other library VIs in their new location).


This idea is similar but potentially easier to implement than the following idea: Make the VI's from the "vi.lib" Read-only - NI Community

 

Thanks

Navigating long lists in LabVIEW can get painful, e.g. for producer consumer design patterns and message handlers. 

This idea is to add submenu parsing for dot notation items.

NickNZ_0-1637183178741.png

NickNZ_3-1637185590012.png

 

Now your case structure can do this:

NickNZ_6-1637185740149.png

I don't think it will effect ranges in the case selector as it requires two dots... e.g. "Init.Step1".."Init.Step4"

 

Credit: This thread for inspiration: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Case-structure-easier-selection-for-structures-with-a-large/idc-p/4192417?profile.language=en#M43910

 

Suggestions required on how to handle a list in this situation where its a lot of numbered messages. 

 

Also I just learned from a colleague that by grouping controls carefully (& some caveats) with the dot notation on FPGA it allows for a submenu. (And clusters on a FPGA can take up a lot of gates).  So LabVIEW already has some code for this feature. Can it be leveraged? See below:

 

https://forums.ni.com/t5/LabVIEW/Group-FPGA-Controls-With-Dot-Naming/td-p/2767678?profile.language=e...

This post generated this idea which is the same problem in the FPGA space... grouping long lists to make them easier to use.

https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Better-FPGA-FP-Control-Selection/idi-p/3074718

 

 

 

 

In .NET each of the integer data types provides two constant fields, named MinValue and MaxValue. These constants return the minimum and maximum values that can be stored in that data type. For example, for Int32 MinValue would return -2147483648 and MaxValue would return 2147483647.

 

1 C# min and max values.png

 

It would be nice if there would be similar constants in LabVIEW for all eight integer data types. These constants would be similar to the DBL constants that already exist: +Inf, -Inf, Machine Epsilon and NaN, and would be similar in concept to string constants such as Space Constant and End Of Line Constant.

 

The new constants could be placed in the Numeric palette, or in a new sub palette of the Numeric palette, as shown in the image below. I would be happy with any location.

 

3 Where to place the constants in LabVIEW (edited).png

 

I am aware that I can easily create constant VIs to implement this functionality, which would be very similar to how Space Constant.vi is implemented, but it would be nice if the constants were built-in.

 

My current workaround when I need the min or max values of an integer data type is to drop a numeric constant and type something like -9999999999999999 or 9999999999999999, which after Enter is pressed LabVIEW correctly coerces to the min or max value.

 

Thanks

I really like the option to use indicators (connected to the connector pane) as the output for webservice methods. By default, Labview will serialize it to JSON, but text and xml are also options. It works quite well and it saves a lot of coding writing your own serialisation.
I have some suggestions for the serialize functionality:

 

1. order the JSON output by tabbing order when there are multiple output indicators. This prevents that you end up always clustering all controls into one, just to enforce order.

 

2. it would be nice if an enum could be represented by its string instead of its index.

 

3. support for maps

When you get an error from an invoke node or property node, the error message sometimes tells you which node generated the error.  But it often does not.  It'd be nice if these error messages always provided you with this info:

 

_carl_1-1635891908407.png

I've spent plenty of time in the past trying to track down the exact node throwing an error, this simple change would've saved me quite a bit of headache.

Software development has moved on since a similar idea was declined in 2016

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-LVdiff-and-LVMerge-available-for-all-labview-vers...

I would like to suggest just LVCompare is made available in all versions of LabVIEW.

If LVMerge was also available that would be great, but leaving in just in the Professional version would also work.

As a lone developer I use GIT even on very simple projects to give me the ability to rewind and see what changes I have made. Projects are often put down and picked up weeks later. LVCompare lets me see how far I had got. Its also very useful for picking up debugging that should have been removed. In short Software Version Control just make my life easier.

 

I tend to use malleable VIs more often than half of the items in the "New" context menu list when you right-click within a project, however, it's not an option:

_carl_0-1635193396358.png

Instead, I either need to:

- Create a new VI and then make several property modifications, and save it as a ".vim".

- Create it through the file menu and then remember that I need to move it to the appropriate place in my project, because it gets created at the top-level.

 

Why not include this in the context menu?  (Bonus points if Polymorphic VIs get added too!)

 

Aren't you tired or seeing Labview, or LABview or LabView online?

 

NI Certifications (CLA, CLD, etc) should be stripped off people engage in miss-spelling LabVIEW.

 

And those who aren't certified should handwrite "LabVIEW stands for Laboratory Virtual Instrumentation Engineering Workbench" 10 thousand times!