Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


jacobson last won the day on August 17 2020

jacobson had the most liked content!

About jacobson

  • Birthday 06/05/1992

Profile Information

  • Gender

LabVIEW Information

  • Version
    LabVIEW 2013
  • Since

Recent Profile Visitors

2,788 profile views

jacobson's Achievements

  1. 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.
  2. Very cool video series, thanks for sharing.
  3. That's fair, I don't think I ever tried debugging a built application.
  4. 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.
  5. Pretty useful if you have hardware and really want to understand the effects of different failure modes.
  6. 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).
  7. 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)".
  8. 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
  9. 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?
  10. 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.
  11. 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).
  12. 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
  13. 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.
  14. @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.
  15. 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.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.