Leaderboard

Hi everyone, Apologies for the slow response - this thread kicked off a number of internal discussions within NI and I was waiting for some of those discussions to shake out before setting up these engagements. First of all - I have set up a calendly link for scheduling time slots for 1x1 discussions. This is my first time trying calendly, so I have set up 30 minute time slots for three days later this week. Let me know if you have any suggestions or tweaks to make this more effective. Thank you in advance to those of you willing to take the time to talk to me, I appreciate it! In the link I specified two different types of discussions, please specify which kind of discussion you would like to have and I will send you a Microsoft Teams link. The first type is a user interview where we discuss how you use LabVIEW today. This is not focused on NXG, it is a way for me to better understand your workflows and pain points that you encounter today. This helps me better inform design decisions we make in NXG. The second type is a feedback discussion focused on NXG - this is more open format where I will do my best to answer your questions and discuss any feedback you have on NXG. Second - I want to address some of the points in this thread about prior engagements with NI. For the last few years we have been very focused on closing the functionality gaps between LabVIEW and LabVIEW NXG - this means we have not done as much iteration on usability and existing functionality as we would have liked. Big gaps like dynamically loading a VI, sub panels, and hardware support were prioritized higher. As we are getting closer and the gaps are getting smaller, we are re-evaluating some of these longstanding complaints and looking to address them. For example Neil mentioned he had a lengthy discussion a few years ago and didn't see any product changes as a result. I discussed this with the product owner that conducted that discussion, and it (along with several other user interviews that expressed similar concerns) led to several significant design changes - including a major redesign of how we handle tearing tabs out of the editor. In that specific case the redesign represented a significant development effort and was deemed lower priority than closing some of the gaps we mentioned earlier, but as we get through some of those higher priority items I would expect us to look at it again. There were several other areas of feedback which did lead to product changes - such as more color on diagram constants and changes to how the palettes work. We know we need to do better at closing the loop so you can see the impact that these discussions have, and we are working on finding the right venue for having those discussions with the broadest possible audience. Regarding dr powells question about areas which I consider significant improvemented in NXG - there are a few which immediately come to mind 1. The workflow of detecting hardware and getting a first measurement has been significantly improved. We have heard consistent feedback from new users that the getting started experience in LabVIEW is difficult - so called 'blank VI syndrome'. We tried a few different ways of addressing this in LabVIEW, but in NXG automatic detection of hardware is improved and reflected directly in the project and measurement panels let users configure their measurement and basic signal processing before being translated to G code. That is not a workflow that impacts many of the more advanced users on this forum, but it makes LabVIEW more approachable to new users which is important to grow the user base. 2. In my opinion the changes we have made to the project are a huge improvement. Requiring a project, using the project and components to manage the dependencies between files, and mirroring the project file structure on disk (which I realize not everyone is in favor of) has eliminated cross linking. Personally I find it speeds up my development for the editor to be picking the disk location of the files I am creating - especially when I am working with classes and creating a lot of files. 3. Components in general are a big improvement over the options in LabVIEW. They simplify dependency management and encourage modular code architecture. They solve many of the limitations of PPLs. Each component translates to an exe or gll when built, which simplifies build specifications. We have also enforced a strict rule of editor run behavior being the same as built application behavior, which should improve difficult to track down bugs where it works fine in the editor but breaks in a built application. 4. Moving to an xml file format will enable us to eventually have a significantly improved integration with git and other third party tools. We are not there today, but that is where we intend to get to. 5. This is less user-visible, but the underlying architecture of NXG is more flexible than LabVIEW and has been designed for extensions and plugins from the beginning. This is easiest with C#, but it means that community members who know C# are able to extend NXG in a myriad of ways that are not possible with LabVIEW. As I said in my previous post - LabVIEW NXG is still a work in-progress. It is not ready for complex projects yet, but we are getting closer and moving quickly. Similar to what Stephen said - I believe the vector is good, and community engagement helps us refine our direction. Please grab a slot for a 1x1 discussion if you want to discuss this further or are willing to talk with me about your current workflows. Thanks!

I do remember discovering the Window Monitor and Ned windows semi-independently. Someone posted a way to show the Heap Peak window, with CTRL+Shift+D+H and I thought that was likely for Debug, and Heap. So why not try D+<every letter combination>. At the time I think only H, N, and W did anything. Most of the time I care to find a window's HWND I use a private function which lets me do what I want. I have never had a need for knowing the HWND of any of the other windows so that Window Monitor wasn't all that useful for me. The Ned windows unlocked more useful information, but just for curiosity sake really. Also I find it really interesting that Heap Peak has been in LabVIEW for such a long time and with seemly no or little updates to it.

Hi! Great article, indeed. I'd like to add some little notes, that I've known of. - I saw Heap Peek in LabVIEW 2.5 already. I could propose, that it was always in LabVIEW, in any version maybe, but I can't check it right now, because I don't have LabVIEW 1.0 or 2.0 distros. - There exists another way to get Heap Peek window visible. You could use some utility to deal with applications windows, like WinSpy++ or Window Detective or any similar tool. Heap Peek is hidden window by default, but it may be displayed easily. - Those hex numbers in the upper right section of Heap Peek are the objects' addresses in LabVIEW memory, so they could be used to explore (or even modify) a single object's properties or any related data in your favourite debugger (of course, if you know, what you're looking for). - I believe, DCO stands for Data Controller Object and there's DDO also, that should be Data Display Object. I didn't study DDOs much (it's either a control or an indicator), but a DCO controls how and which data is passed through a single terminal (on BD) or control/indicator (on FP). You may find any SubVI's/node's terminal w/ Heap Peek and in its properties you should find an address of DCO assigned to it. The same is doable with controls and indicators on Front Panel. On BD DCOs are called Parameters or EFN Parameters (for CLFNs) or somehow else. On FP they're called FrontPanelDataControllers. It's easy to find them using "F" button of Heap Peek. Going to the original topic, there's "Window monitor" debugging tool also, which could be viewed with CTRL+SHIFT+D+W. It's able to display LV windows handles (HWNDs), positions, names and some other info's. Oddly nobody ever mentioned it on the forums, maybe because its use cases are very limited. It's not so convenient to use also, because its interface is very ascetic. WinSpy++ or the analogs do the similar work a way better.

JeffP, in the interest of not letting this conversation die, can you present some positive features of NXG that improve over LabVIEW?

Conversation dead.