acb

Hey! Yes, we're definitely exploring what to enhance with AI, not just creating VIs. The DLL import feature already exists -- and we had a more sophisticated solution in NXG -- but has some limitations, and besides, the way you described your ideal workflow with an AI generating the wrapper VIs... really great. Your ideas welcomed... make a list, however long!

On 5/30/2023 at 2:01 AM, LogMAN said:

What I'm looking for is not so much an AI that writes my code (because I know how to do that), but one that accelerates my development process by suggesting changes in the context of my code

^ Great quote! And what we're exploring: to augment and accelerate the test engineer, whether that is a new VI or navigating a complex workflow like CLFN (like you mentioned).

We didn't show it in the keynote, but all the VIs shown in the chat are VI snippets, letting you drag and drop generated VI block diagrams wherever you want! We've explored the gray code idea, but it presents a few challenges; for example, what if the generated grayed out diagram is bigger than the diagram space it has? Do we push everything out to make room for the predicted code? Do we just clip it at the edge of the structure, move nodes, etc? We haven't dug into that yet. Ideas welcomed.

17 hours ago, Jordan Kuehn said:

Here's one for you. The AXS Port is a modbus device that monitors power inverters. It would be great to feed Nigel the attached document and have it generate drivers/API for communication with the device.

Thanks for sharing these! We will use them as test cases. Will dive into them a bit more in the coming week or two.

Hey everyone! It's Alejandro from the keynote demo. Wanted to shed some light on Nigel and gather feedback from this important forum (my first post!).

A little about myself: Stepped foot at NI in 2007 and had the honor to work on the LabVIEW language design and compiler teams alongside all the incredible folks you already know. In fact, Aristos Queue was once my mentor! Deeply fond of LabVIEW and all its users.

Back to AI --

On 5/24/2023 at 11:48 AM, LogMAN said:

Jokes aside, the copilot looks interesting but it needs much better integration to be useful for any of my day-to-day tasks. It needs much faster response time and it will have to show how well it can work with legacy and non-standard code bases that aren't developed with NI's portfolio and vision in mind.

What types of day-to-day tasks would you want Nigel to help you with?

And yes, I intend Nigel to help you with your hardware and codebases that aren't the latest & greatest.

On 5/25/2023 at 3:04 AM, ShaunR said:

Why does AI type so slowly? [...] Linear coding is never the final solution. I expect it was tuned for very specific requirements but I was more impressed with it reading the emails and specs and interpreting them in context.

It types slowly because we are using GPT 4.0 under the hood, and the demo was live on stage. GPT 4.0 is about that fast, and it varies throughout the day; at night, it seems twice as fast.

This presents a challenge that we are working on; we have lots of ideas to make the generation speed a non-factor. Nonetheless, I'm hopeful that GPT 4.0 will get faster over time, as Open AI fully transitions it out of beta, and as they buy more GPUs. It is possible to retrain Nigel with GPT 3.5 (what ChatGPT uses), but it does not perform as well.

On 5/26/2023 at 4:10 PM, X___ said:

Un-commented spaghetti code is pretty much useless... The flat (single VI) LabVIEW generated code demo doesn't tell anything about the ability for this type of AI assistant to generate structured code.

Nigel is capable of using structures, documenting VIs, and creating subVIs, but we did not show that on stage to keep the keynote short & sweet and focused on the core message of spec-to-test (going from a spec sheet to a working hardware test in seconds or minutes). Nigel can do much more than what we showed.

On 5/25/2023 at 12:35 PM, Jordan Kuehn said:

The demo made me wonder if it could theoretically create drivers from spec sheets automatically. It seems like it would be a well bounded problem, create labview wrappers for the commands listed in the manual. 

Would you share a device you'd like Nigel to create a driver for automatically? That would be a wonderful test for us.