jacobson

You're doing better than jeffk, he's still a newbie. I guess LAVA just has high expectations.

I currently use Git through SourceTree. I like it although I am very rarely working on a project with someone simultaneously so I'm the opposite of a power user and just need the core features to work well and be simple to use. Most projects will be on some GitHub or Bitbucket page so having straightforward integration with those two services was important to me. I used to use GitHub for desktop as a client for a while but there was an update I didn't like so I moved to SourceTree. I've tried GitKraken as a client as well which I thought worked well. I have also used TortoiseSVN for a few projects for which I only wanted a local repo and it worked fine but I still prefer putting things on GitHub and using SourceTree if I am able. The last time I had any big issues with my source control was when I was working on some FPGA code and I had to add a few more FPGA resources (FIFOs/DRAM) which caused changes in the .lvproj file that I figured would merge but didn't. It ended up being a lot less of an issues than I thought it would be and probably only cost me an hour or so. This isn't strictly true and it's not something I would worry about too much if you're working by yourself. I still find it useful to create a branch when I start working on a new feature and then merge that branch when it's done. As long as you don't touch the main branch once you create your feature branch (and if you're by yourself it's easy to make sure this doesn't happen) there won't be any conflicts and your code will auto merge.

Very cool video series, thanks for sharing.

That's fair, I don't think I ever tried debugging a built application.

Wasn't this something NXG could do though? One NXG window could contain multiple tabs of VIs but you could have multiple NXG container windows all open to the same project. I had my own issues with NXG but I've seen this type of complaint brought up and never really understood the problem. I've been in the "tons of VIs open debugging mode" but I often wont even remember which window is which and will just Ctrl+Shift+E and open the VI from the project to force it to the front.

Pretty useful if you have hardware and really want to understand the effects of different failure modes.

Interesting, although I'm not sure how often I would actually use this feature. If I'm working out of some class or library I've never really been concerned with creating a subVI that may only be called that once and just throwing it into some private-scoped virtual folder. I've created quick drop shortcuts in the past and that's probably been the only time I remember when I would have wanted a feature like this (lots of sequential logic and more convenient to just distribute a single VI). Sharing example code might also benefit from this (although other users would probably be confused).

I also wonder if there would be some way to get a "if you liked this package you may like these packages" type of recommendation. I'm not sure if it would be all that helpful for API packages but it's something that might be cool for quick drop shortcuts, right-click plugins, or other editor enhancements like the class method browser. Having recommended packages could also be helpful for "framework" packages that have plugins or tools associated with them. As an example, if I end up at the JKI SMO package it would seem reasonable to point me to packages like "JKI SMO Template (DAQmx)" or "JKI SMO Template (Graphs)".

I don't think I would find myself browsing packages without first looking for a specific package but I do like using tags as a way to find alternatives I didn't find in a direct search. As an example, at some point I got to the following VS Code plugin page which seemed nice but also had a set of tags on the right which I used to look at a bunch of different alternatives. https://marketplace.visualstudio.com/items?itemName=vscode-icons-team.vscode-icons

Not all R&D work leads to the same change in revenue. If you can better prioritize what you are working on, you can get more out of the same amount of work. On the second point, I'm not an accountant but doesn't gross margins only account for the cost of the physical goods so that can get skewed heavily by including software and services in the "system" price?

I agree that you should probably push back a bit on the requirements. If you want to get real weird with it, I've worked with a group that did all of their hardware interaction in LabVIEW, built that code into a DLL and then called it from an excel macro that was continuously running.

Is the 7-day trial for community edition or Base/Full/Pro? If it's for the later you can try just removing the license file from the usual license folder to see if it lapses into using the community edition license just fine. I don't know how exactly how the community edition is licensed but that type of thing happens a decent amount with volume license servers (LV complains about software that's about to expire but once it expires it just finds another license and is perfectly happy).

Thanks for finding and posting this link. Visual design isn't something I would say I'm good at but I find it fascinating to read about the decisions behind this stuff. I think the video of the NI logo materializing is also pretty slick. https://player.vimeo.com/video/429461827

Ideally this is how it works but I've been surprised at how many higher level technology decisions (usually some standardization effort) are made without any or with little engineering input. I actually wonder if the problem is worse for managers who used to do technical work because they are over confident in their ability to make technical decisions without input from the current engineering team.

@Chris Cilino I think having this sort of request area can also add motivation to polish up some existing work. I would guess there are a lot of unpolished libraries sitting in a lot of private repositories and having a few requests for that functionality might give more motivation to return to the project, polish it up a bit, and actually publish it.

Not a lawyer but I'm pretty sure all of the open source projects that the NI systems engineering group maintains just have the license in the repo's root. My understanding is that no license means you have no permission to use the software (https://choosealicense.com/no-permission/) so I can't imagine you could get sued for someone using a VI without a license because the default would be that they were never able to use that VI in the first place. Never heard of this one before but I might just use that for some of my GitHub repos. I feel like the only reason I put a license in any of my repos is to explicitly state that I really don't care.

From the Data tab you can enable logging but I don't think you can export the trace after the fact for some reason. The wall of text is very intimidating but I'll try to give some advice. The way I see most people use DETT is by logging some giant 10,000 line trace and then they just dive into it hoping to find something useful. I usually find that this strategy is a giant waste of time. Ideally you have some specific thing you want to check with DETT (am I leaking references, I shouldn't be reaching this case but am I actually enqueuing that) at this point you can go into View > Filter Settings to filter out all of the garbage, leaving yourself a much more manageable trace to look through.

File > Preferences > Editor > Wiring lets you change this back to CG behavior. NXG gives you the hand tool when you hold the space bar instead of Ctrl+Shift like in CG. One minor improvement (my opinion) is that, in NXG, the scroll wheel will move the diagram up and down but if you shift+scroll, the diagram will move right to left (CG just scrolls up/down faster). That's about the extent of my NXG knowledge.

The equals check should mean that private methods are not discarded for the class you right-clicked on but the private methods of any parent classes will be discarded. It shouldn't be difficult but I don't know how fast it would actually be. From the class wire you can get the path to the .lvclass file and locked/password-protected libraries seem to just be defined by a single XML tag which isn't there for unlocked libraries. From my experience though, very few classes are locked. <Property Name="NI.Lib.Locked" Type="Str">locked</Property>

Probably not too difficult of a change to make. My quick approach was to just ignore all private methods that are not part of the original class. This doesn't exclude Community scoped methods but I think you would need to get the LVClassLibrary reference to figure out who its friends are and I'm not sure how to get the reference from the information we get from the framework. From Set Palette for Class All I did was remove items from the list which were private and not part of the class you right-clicked. I didn't test it all that much but it seemed to work for the simple cases. Deleting elements from the array ended up being ~4 times faster but this way still works through 1000 elements in ~400us so I can't imagine anyone would have a hierarchy where it would really matter. Class Methods Shortcut Palette.llb

That's pretty cool, does the menu change based on method scope?

I I'm remembering everything correctly, you'll also have to be careful of which elements need to be redrawn when deferring FP updates. If you haven't deferred FP updates then toggling visibility of two controls will force LabVIEW to redraw just the area of those two individual objects but in the case that FP updates have been deferred, the visibility has been toggled, then updates are undeferred, I believe LabVIEW ends up redrawing a single rectangle which encompasses both objects (so for N objects just draw the smallest rectangle that would cover all objects needing to be redrawn).

You can post it to the idea exchange if you want but I would see this making it hard to normally select the tunnel (just to move it around) for everyone using the auto-tool.

Where can I sign the petition to hand over NI's social media accounts to you?

As a contributor to other packages I would like acknowledgement for those contributions. This was from our user group and the general idea was that package owners can build a self-brand of sorts by being attached to popular packages but if someone makes significant contributions to many successful packages there should be some sort of recognition. I think the OpenG libraries are a good example where there may only be one owner but I'm sure there were some large contributions from several people that led to the overall success of the project. I don't know the best way to do this but the simplest might be to have a list of projects that you are a major or minor contributor to. You might be regarded as a minor contributor for any packages which you submit any meaningful code (some bug fix or new feature) while being a major contributor might be an acknowledgement from the package owner. In my mind a package may have a field for major contributors and the package owner could curate that list and link to other users.