jacobson

4 hours ago, Rolf Kalbermatter said:

Buaaah, not fair. I'm still only a Rookie! 😂

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.

On 2/25/2021 at 12:25 PM, rharmon@sandia.gov said:

Just read Crossrulz's reply and it states "just don't branch and you will never have to worry about merging"  Cool.... I guess I'll just have to cross that bridge when the time comes.

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.

4 hours ago, Mads said:

For the first versions of NXG it was not possible. Then it started to allow you to have multiple instances of the VI open and hence to see both the diagram and the front panel at the same time, but each window had so much development-stuff surrounding it that it was not practical to have much more than one or two open. Hiding any of it to free up space and/or to see something closer to what you would see in the built application was not an option.

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

On 12/23/2020 at 5:04 AM, Mads said:

Having multiple front panels and block diagrams open at the same time, and being able to jump from run to edit mode quickly to do debugging and GUI-testing is one of the core strengths of LabVIEW.

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.

On 10/1/2020 at 12:40 PM, flarn2006 said:

Hedge, is that you? 😉

 

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

2 hours ago, hooovahh said:

Luckily my current boss knows NI and their offerings, but trusts my opinion over theirs.  They need to convince me something is a good fit, before they will convince him. 

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.

1 hour ago, Neil Pate said:

I don't really want to hand edit 700 VIs. As I said, if I do release it I really don't mind what others do to it. Sorry my question was a bit vague, I actually wanted to ask if I *have to* put a license on every VI. I would be more than happy just putting the "do whatever you want" license (probably MIT License) on the GitHub page if that was sufficient for me to not get sued if someone's heart lung machine stops working due my code.

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.

23 minutes ago, Mefistotelis said:

And if you completely don't care about license and want to mock it a bit, there's always DBAD - it's quite popular for underground tools.

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.

1 hour ago, Neil Pate said:

Why can I not easily branch off a wire by clicking on it somewhere? Now I have to right click and select the option to create a wire branch

File > Preferences > Editor > Wiring lets you change this back to CG behavior.

1 hour ago, Neil Pate said:

• I like the really like the zoom but please let us pan with the middle-mouse or something similar

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.

On 4/24/2020 at 11:35 PM, Aristos Queue said:

I don't want to just remove the privates completely ... if you're working inside the class, you may need those. 

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.

On 4/24/2020 at 11:35 PM, Aristos Queue said:

But there's an old compromise in the actual palette code... if a library is locked (not just read-only but actually locked) or password-protected, then hide the community and private scope methods. Our theory was that if a class is locked then its internal development is finished and published and any of its friended components are probably also done (or they know that they are friends and can go get that information). Similarly if all children are either non-existent or also locked, then remove the protected scope stuff. 

I don't know how hard it is to get that info without opening a class library refnum.

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>
 

On 4/20/2020 at 9:24 PM, Aristos Queue said:

No. I didn't take the time to do that. Would be cool if it worked though. If you decide to patch it up (there's no passwords on those VIs), I'm happy to ship the revision. 

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?

On 3/24/2020 at 4:46 PM, LogMAN said:

The front panel should be visible during the test to ensure that it is actually redrawn. It should also contain the necessary number of indicators to make both cases are comparable. If you reuse the same reference multiple times and defer panel updates, it only measures the iteration time of the For-loop + a single redraw, which is not the same as updating the UI on every loop iteration.

Here is a version of your VI that has 100 boolean indicators on the front panel and is visible during test (it is also important to have all indicators visible on screen during test): MethodPerformance.vi

On my PC the differences are much smaller with this version (if you set the number of elements to 1, the number of updates is roughly the same)

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.

14 hours ago, Dataflow_G said:

I assume you meant this video?

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.