วีดีโอ

Darren's presentation is well thought out, full of useful things, and valuable for any LabVIEW developer. And I understand his perspective of wanting to help LabVIEW developers with their individual issues that need fixing. So telling developers to avoid a major issue in LabVIEW is a good idea. But I would rather see LabVIEW itself be better. All of these things that are broken within LabVIEW should ideally be fixed. Avoiding XNodes, VIMs, PPLs, and possibly Class Property Node Clusters, should not be something I have to worry about. These are features of the language, and should work well together, not cause crashes, and not cause build errors. I understand NI has limited resources, and they can't be expected to fix all issues. That's why presentations like this are helpful. But if NI is serious about reducing the amount of support tickets associated with VIMs, I'd suggest investing time in fixing the corner cases with VIMs. If XNodes are corrupting VIs in a PPL, I'd suggest creating a bug to fix why that is happening, not just to create a bug for when XNodes are used in the Actor Framework, and a bug to fix why the search feature is crashing with corrupted VIs. I have personally filed bugs with NI regarding nested VIMs, when used in a built application. Once they discovered that a VIM replaced with a static VI fixed the build they closed the issue. I strongly suggested they try to fix this issue for everyone, and not rush in closing out my issue. Oh and Darren does express some of these same comments earlier in the presentation, so I don't want it to seem like Darren isn't trying to make LabVIEW better. He specifically says people at NI might not be happy with him presenting it, and shining a light in LabVIEW's issues.

Great presentation. I didn’t know about LVAddons, I will definitely be looking into that.

by Nancy Henson. GDevCon N.A. 2024** AI is a strong tool to promote creativity, but it's crucial to discover the correct tools that complement your creative process. Consider researching alternate solutions that can provide a fresh viewpoint and raise your creativity even more.

This is why the internal LabVIEW developers should be on stage at our events, it's been far too long. Absolutely brilliant insights. Great job!

Nice presentation. Look forward to see more 🙂

Sergio who? what his name? for the OpenSource part

Great Talk Ashish! Thanks for sharing your experiences!

Nice one Laura. Very neat demo to get people interested in this area.

Very useful. Thanks.

An enjoyable listen. Thanks!

Hope they have plenty of chessburger chessburger chessburger chessburger!!!!

I jave message LabVIEW: (Hex 0x4A) Memory or data structure corrupt. How to solve it?

Super interesting!

Entertaining and useful. Thanks!

You should look into functional interfaces and functional programming. It would be cool is LabVIEW had an easier way to do lamdas. The closest I've seen is how you handle .NET callbacks. Learning from FP will work wonders for state management. You would learn a lot from doing functional programming in Java. Hopefully we'll get lamdas in LabVIEW at some point. It could be a structure with some code and well defined parameters that we can pass as an argument to VIs.

In stead of semiphores I use DVRs. They make more sense. An in place element is a really nice way of saying you own this data and you never forget to unlock it. Much much safer. Less complicated.

35:24 Good explanation. A better explanation is that an interface is a contract or a qualification. For example, without interfaces every car will have to be tailored specifically for that individual and their descendants (in the case of inheritance). However if we introduce a driver's license interface and say the car can be driven by any object that has a (implements) driver's license interface, then we don't have to design a car that's tailored for the individual. Here's a code example: the interface is IList. Any class that implements this interface is qualified to be a list. class LinkedList implements IList{...} class DynamicArray implements IList{...} class RingBuffer implements IList{...} class Queue{ Queue(buffer IList){...} // this is a constructor ... } Queue linkedMessages = new Queue(linkedList); Queue arrayMessage = new Queue(dynArray); In this case you have created a queue that can use any list like data structure as it's internal buffer.

42:59 Refactoring with interfaces is nice because it gives you compile time checks. Basically your code will not compile unless you make the appropriate changes to meet the contract proposed by the interface. Thats a good thing. Your interfaces also need to be as small as possible.This is how you avoid mass refactoring.

Beautifully Done! Smart Intern for a smart mentor !

Was going well until 25:45. The demo started and all we can see is Brian moving the mouse and talking. Slides start again at 36:41. Interesting presentation.

What a disheartening demo. NI please get your priorities straight. NXG sucked so much resources, giving everyone else these bugs

It's a pretty strange decision to send metadata through an error cluster. I usually treat error clusters like a try-catch since LV doesn't have a native T-C. If you need to log meta, log it there and then rather relay on hopes and dreams. If it's not important don't add it, you're just wasting cpu cycles. using a try-catch for meta is very strange decision in any programming lang. Edit: Just in case there is a misunderstanding, I'm talking about the case were the bool is false but there is data on the err clstr.

I'm sorry but this needs to be said. Python and .NET should not be first class citizens. G, the programming language that NI uses should be. What LabVIEW needs is one giant quality of life update. By leaving this out you guys are incurring a huge technical debt for both yourselves and your customers. Technical debt is fine if you can repay it, but NI isn't. Writing clean code in LabVIEW is a time consuming process. Classes are an expensive resource in LabVIEW, you can have a limited number of them before LabVIEW becomes sluggish. There is no explicit way of saying cloned reantrant VIs need go destroy themselves completely if the top level VI stops running, this causes a lot of memory leaks in the IDE that don't occur when you compile your code into an executable binary. Wiring needs better prediction. Your native template like creativing static/dynamic methods are not well sooted for development, there is no room for property nodes lol. At least make it easy to create custom templates. A native way to create variants (not variant attributes), like the OpenG stuff (which is slow) (adding a reflection system would also be nice). Separation of the Update and Add functions for Maps and Variant attributes, without this performance is wasted on checking if an item exists before adding it because you dont was accidental updates. Etc. Also a native package manager and builder like JKIs would be nice. Rust has Cargo and it's been a game changer. Again you desperately need a quality of life update. Many people want to leave LabVIEW because it's extremely tedious. You're one good competor away from being obsolete. Many love Python and .NET because they are very intuitive and cut down on development time significantly.

Great video, well done! And thanks for sharing code, though I think it would more convenient for viewers if we could see the screen better during live demos and showing code (or make the video stream larger).

Guys.. really useful information. But poor video quality

This Man is a legend

Thanks for pushing for higher LabVIEW editor and run-time stability. Around two years ago I too was bitten by an issue whereby my LabVIEW 2018 application wouldn't build into an EXE anymore after using my own custom-made malleable VIs deeply nested as subVIs inside other lvlib-owned VIs. The code worked perfectly fine in development environment. There were no broken run arrows. For a while I played tickbox roulette exactly as you described. In the end I refactored the malleable VIs into regular VIs. This worked, but it led to code duplication in the sense that for each malleable VI I had to create two or more regular VIs that were virtually identical, but were adapted to a particular data type. The whole investigation and refactoring cost around a week of work.

I just want something as easy as .NET in LabVIEW. Compare the .NET TreeView or Datagridview to LabVIEW's equivalent. Why dont we have dynamic user interfaces and why is there a billion ways to represent bounds of a control? Why aren't Tabs given the same priority as Panes? The control in essence is a Pane. What about following general programming conventions, like separation of the update and add in Maps, there's a performance penalty for merging the 2, I always have to check if a key exists because I don't want to accidentally update a value. Clearer documation outlining how certain functions work under the hood. .NET like Introspection would be a killer feature in LabVIEW. The current variant VIs are terrible. Returning types as a variant when you have a perfectly fine enum was a bad design decisions. Why cant we manipulate the text on variants? Getting the size of an Array requires coping of data. I can go on for years. My main pain is UI. Please streamline in. Making a mordern interface in LabVIEW is a headache.

1) Call NI and tell them to do better. They should try building NI MAX using LabVIEW. They'll know everything that's wrong with LV.

The best discussion on errors I've seen. Thanks!

Nice video. Thanks Brian and GDevconNA. We had a similar experience with an NXG-based web app (before it became G Web Development suite). Presented here at GLA Summit 2020: th-cam.com/video/sP1ZgkbhZZ8/w-d-xo.html

i use lots of nested malleable VIs with classes that have an inheritance tree with more than 10 levels works fine on Win / Linux / RT Linux

It is unfortunate that the camera was not recording the presentation screen while he discussed the demo code.

Very interesting presentation! Will you add the live demo also to the video? Thank you!

How much of a performance improvement do maps and sets have over the variant attribute solution?

See more at: labviewwiki.org/wiki/GDevCon_North_America_2021/What_comes_next_for_LabVIEW

See more at: labviewwiki.org/wiki/GDevCon_North_America_2021/Reduce_Technical_Debt_Through_Better_Software_Package_Design

See more at: labviewwiki.org/wiki/GDevCon_North_America_2021/A_Practical_Demonstration_on_Using_Interfaces_for_Class_Configuration

See more at: labviewwiki.org/wiki/GDevCon_North_America_2021/Good_LabVIEW_Habits

See more at: labviewwiki.org/wiki/GDevCon_North_America_2021/Per-Project_Package_Installation_and_Configuration_Management_with_VIPM_and_Dragon

See more at: labviewwiki.org/wiki/GDevCon_North_America_2021/Using_SytemLink_to_Manage_LabVIEW_and_TestStand_Deployments

See more at: labviewwiki.org/wiki/GDevCon_North_America_2021

See more at: labviewwiki.org/wiki/GDevCon_North_America_2021/LabVIEW_NXG_Lessons_Learned

See more at: labviewwiki.org/wiki/GDevCon_North_America_2021/Solutions_Architect

See more information at: labviewwiki.org/wiki/GDevCon_North_America_2021/Practical_Framework_Abstractions_-_Maintaining_Legacy_Applications

See more information at: labviewwiki.org/wiki/GDevCon_North_America_2021/Architectural_Regrets:_Refactoring_vs._Rewrite

See more information at: labviewwiki.org/wiki/GDevCon_North_America_2021/The_Error_of_Our_Ways