Jump to content

Jon S

NI
  • Content Count

    8
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Jon S

  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 Assembly. If you are just using an assembly installed on the system, you can't call the other constructor. This doesn't help your situation, but I have a team that is currently working on .NET for NXG and I did make this an acceptance criteria of their work. I verified in a beta build of NXG 3.0 that we are able to call both of the overloaded constructors. This is similar to the model we are moving toward. The Product Owners have the final say of when we toggle on a feature. It's our role to hold the line for quality and workflow completeness when it comes to turning on features. Hopefully our change in process is noticeable as we move forward. Thanks again for the candid feedback here. It does help myself and other POs have a better grasp on the heartbeat of the community.
  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 to understand our users and prioritize features based on their needs. Our marketing department will help identify target personas and market areas, but the product owners are setting priorities as well as signing off on features before they make it into the product. We are changing the way we do development to release higher quality features, create more useful features and validate the features actual solve the customers' problems. I'm know many here are familiar with the LabVIEW Known Issues list which is our mechanism for bug tracking. It's not interactive like many of the options that are listed so I do realize that it doesn't solve all of the problems described. When you do send code or applications that reproduce your issues to our Applications Engineers, one of the things that they try and do is narrow down the issue so that it is more easiliy reproducible. If not, we typically try to reproduce on a VM so that it limits the setup time for the subsequent developers that will look into these issues. I wanted to give you an idea about some of the recent changes we've made to provide more value to our users. The feedback you've provided is good for us to hear and does make a difference.
  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 applications to NXG. Their team goal is to provide feedback to the NXG development teams and Product Owners to help us prioritize what we need to be working on. While a lot of my recent focus has been on LabVIEW NXG, I did want to follow up with the comments about the dragging performance of the LabVIEW IDE first brought up by Neil. I spoke with the developer of live drag about the behavior you are seeing as well as did some testing of it. The behavior you are describing when dragging objects across diagram boundaries (e.g. the drawing delay when dragging from outside a loop to inside) is actually intentional. It was a compromise designed in to help performance when dragging very large selections. The intended user interaction is that if the user really wants to see what the code would look like before releasing the objects, they could stop moving the mouse cursor. If we don't detect movement, LabVIEW will redraw the code. However, it seems this is being inferred is that there is sluggish behavior when moving things between diagrams. If you drag across diagrams and immediate release are you seeing a delay in moving the code? Your comment about seeing the same behavior when moving a single primitive makes me suspect that we aren't struggling to keep up from a performance stand point, rather the UX that we designed is not having the desired effect. Worse off, it sounds like it's having a negitive effect. As an aside, we don't need to do a full compile when we are doing live drag. Type propagation is just the part of compile that determines wire and node data types. When we are doing live drag, this is the only part of the compilation process that we have to do. Thanks for the feedback everyone. I know there were some other generic performance issues that were mentioned, and I don't want to give the impression that I'm ignoring them. I just wanted to focus on the issue presented by Neil first. Jon S LabVIEW NXG Product Owner
  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 one CPU that could make a difference although I wouldn't expect it to be a huge difference How much shorter is your build?
  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 contains a custom I/O server. We were previously loading all libraries (e.g. classes and XControls) to check, only to unload them again. One simple quick workaround (if possible) is to deactivate DSC as we won't check for custom I/O servers if it isn't activated.
  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.