Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by jacobson

  1. So when you start your "Modal" VI you'll just set the FP.Behavior to Modal and set it back to Default when the VI finishes executing? I never thought of doing that but seems worth doing it to prevent ready to run modal windows forcing me kill LabVIEW.
  2. I've seen a few RT applications that use move blocks over type casting as well. Obviously not very safe but it is fast.
  3. Software is being modified by both NI and third-party so I think it would be safe to assume that LabVIEW is included under the umbrella of "NI software".
  4. In past years there was often a meetup at some random bar on the Sunday night before NIWeek to get some drinks and hang out. Anyone know if there are similar plans in motion this year? If not, does anyone want to meet up somewhere Sunday night?
  5. If you're working for a larger customer they also might have brand guidelines that you can follow. A long time ago I worked with someone from UT Austin and just followed their published branding material. https://brand.utexas.edu/identity/color/
  6. For more general data acquisition systems I'll hear about UEI, VTI, Dewetron, and HBM. Beckhoff comes up plenty but the remote I/O or industrial control space does lead to them having different strengths/weaknesses.
  7. The question below that seems to indicate that there may not be a call for presentations because they'll just pull from previously accepted sessions but who knows. Hopefully there will be good technical presentations still.
  8. The two times we had people in our AE team do this we never got them back 🙃
  9. As an NI employee am I part of the legion of doom in this analogy?
  10. VSCode's October update changed it so directional formatting characters are displayed by default. https://code.visualstudio.com/updates/v1_62 GitHub also added a warning if you are looking at a file with these characters so hopefully more IDEs are being updated to make this vulnerability more obvious.
  11. I would generally suggest just using the language you're most comfortable with. I think Python is generally easier to integrate with but you are limited in data types (no classes). If you're just doing some signal processing though that may be able to develop an interface around that limitation without much difficulty. I also don't think LabVIEW supports the ability to call Python from a specific virtual environment which is definitely annoying. I think the C/C++ integration is a little less straightforward than Python but if you're comfortable with the language and you read the help documentation on the Call Library Function Node and how LabVIEW stores data in memory it's not that bad. You may also have to mess with some LabVIEW memory management functions which can be annoying the first time you use them.
  12. Are you talking about VBAI? I thought Vision Acquisition Software is just the different IMAQ camera drivers so I'm not sure exactly what you're looking to embed from the drivers.
  13. You are correct that phone/email support is now being handled by a separate Technical Support Engineering (TSE) team which is now a career position (meaning they have senior/principal level engineers working in the department). As examples, you now have folks like Darren N and Norm K working as TSEs. This is still a relatively new change (2 years?) so there are still a lot of newer engineers but I think things are moving in the right direction with hiring very experienced engineers and being able to keep engineers within the department rather than constant attrition to other areas within NI. I know a few people in that group who started there out of college and are still there 5+ years later which definitely would not have happened previously.
  14. You can always try calling in on a new case or transfer to a different technical support engineer (I know if used to give you this option if someone wasn't picking up). You don't have to ask them the same question but they should be able to tell you what's going on at least (someone's OOO, case is in some bad state, or more often than not both people think they're waiting for information from the other).
  15. I have two 9074 cRIOs I use as bookends at work and even a couple of books I got from stuff people were trying to get rid of. Most of the hardware I would be able to take home is old enough that I don't really want it (I'm not into home automation or maker stuff so I really don't care about old tech).
  16. Even though we know we will never go to the True case, I doubt LabVIEW would ever be able to determine that and properly remove dead code. It would require LabVIEW to know that the timestamp output of a primitive converted to a double will never be less than 0. If you wire a false constant into the case selector the VI won't lock up so it does work in that instance. I remember running into issues with events being queued when the VI is only reserved to run by (accidently) embedding VIs that weren't running into subpanels. The VI isn't running but clicking anything can still enqueue events and cause everything to lock up.
  17. You're doing better than jeffk, he's still a newbie. I guess LAVA just has high expectations.
  18. 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.
  19. That's fair, I don't think I ever tried debugging a built application.
  20. 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.
  21. Pretty useful if you have hardware and really want to understand the effects of different failure modes.
  22. 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).
  23. 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)".
  • Create New...

Important Information

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