Jump to content

Jon S

NI
  • Content Count

    8
  • Joined

  • Last visited

  • Days Won

    4

Jon S last won the day on September 26 2018

Jon S had the most liked content!

Community Reputation

7

About Jon S

  • Rank
    LAVA groupie

Profile Information

  • Gender
    Male
  • Location
    Austin, TX

LabVIEW Information

  • Version
    LabVIEW NXG 2.0
  • Since
    2008

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I got some more information on the flickering. It is caused when we do a redraw of the canvas. If you slow down the video of LabVIEW 2015 and before you can actually see the flicker once, when we redraw the canvas. We introduced live redraw in 2016 which makes the flicker obvious because it happens multiple times. I did file CAR 713251 for this which one of my colleagues will prioritize among the other work his teams have on their backlog. With respect to the CAR 493662, I agree that the workaround isn't great. It's only an option if you are both the author and consumer of the .NET
  2. Thanks for the video Nate. I'm seeing if we can get some more info about what is causing that flickering behavior. I did test it out and it looks like it was introduced in LabVIEW 2016. I'm not sure how many on here are aware, but we've recently went through a re-org within application software here at National Instruments. Along with creating vertical teams with full stack knowledge, one of the biggest things we've done is create the role of Product Owner within R&D. This role takes on a lot of the responsibilities of an Agile product owner. It is our product owners' responsibility t
  3. Hey Everyone, I was pointed to this thread by a colleague and wanted to answer some of the questions that were posed as well as gather more specific feedback on some of the things that were asked. First off, we do have engineers at National Instruments that are using LabVIEW for real world-applications. Our Systems Engineers and Applications Engineering Specialists work on some of our largest customer applications. They specifically create and work on real-world code. For LabVIEW NXG, we have a LabVIEW Lead User team that has met with a number of customers and converted their applica
  4. Hmm..."commands which involve many files" screams virus protection software to me. Are all of the problem areas you see when doing disk I/O? I know I've seen cases where building a large project in Visual Studio can be slowed down by a factor of 2 or 3 if you have a virus protection on. Can you try disabling this or any file indexing programs that you could have on these machines? If it is a virus protection you could see about adding exceptions to folders that you commonly build to.
  5. Are the installations the exact same on both machines? As I mentioned before if you have DSC activated we do an additional check that requires loading libraries. There could be other things that I'm not aware of but that is definitely one possibility. Another thing to look at is processing power of a single core on the machines. Some older machines have a higher CPU speed with only one core while a newer machine may have multiple cores that are lower power. When building an application is single threaded because of the way our compiler works. If your older machine has a higher speed on o
  6. Are you using the property node implementation of the read/write accessors? If so then I believe this slow down is what we have found and reported in CAR 313044 that is published in the known issues. This was a specific bug that wasn't a problem with the overall architecture. I'll give a little bit more information on what Paul commented on about build time with classes (CAR 316145). With DSC installed we give the user the option of including custom I/O servers in a build. Right now the only way to see if there are custom I/O servers is to load any library within the project to see if it
  7. Hey Everyone, This has been logged under CAR 305157. Thanks for reporting this.
  8. Thanks for the Info Paul. We believe that the underlying solution to CAR 279298 is the same as CAR 255982. So when these bugs get fixed if there are any special instructions in the readme (possibly recompiling) about CAR 255982 you should apply them to CAR 279298 as well FYI: Both of these should now show up in the LabVIEW Known Issues even if they are specific to RT.
×
×
  • Create New...

Important Information

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