Jump to content

JeffP

NI
  • Content Count

    23
  • Joined

  • Last visited

  • Days Won

    7

JeffP last won the day on June 2

JeffP had the most liked content!

Community Reputation

23

About JeffP

  • Rank
    Active

Profile Information

  • Gender
    Male

LabVIEW Information

  • Version
    LabVIEW NXG
  • Since
    2006

Recent Profile Visitors

784 profile views
  1. Can you elaborate on your concern? Generally speaking - directly sharing source across multiple projects can easily lead to making changes in one project which unintentionally breaks another project. The recommendation is that if you have a piece of code that you want to reuse in multiple projects (maybe its a framework or a library) you should separate that code into its own module. The projects would then depend on the built component - a gll for example, so this enables you to maintain versioning and avoid the case I described. Alternatively you could distribute the shared component as
  2. I agree with both your points. For your first point - we debated about how much customization should be available in the conversion wizard. We want to make you aware of any issues that you should fix up before conversion, but we didn't want to duplicate IDE functionality. For example - refactoring your architecture is easier with all the tools in the editor, so we wanted to get you through the conversion wizard quickly so you could use those tools instead of duplicating them in the wizard. This breaks down a bit in the case where we generate multiple projects. Customization like you are d
  3. I may be incorrect in my assumptions here - but when you converted the single project how did you specify which files to convert in the conversion utility? The logic for creating multiple NXG projects works something like this: If you just selected a lvproj file its easy, we load the project, all files in it, and their dependencies. Then we determine which files will be converted and put them all in the same NXG project. Similarly, if you just select VIs, we load the VIs and their their dependencies, determine which files will be converted, and put them all in the same NXG projec
  4. Let me get back to you on this - we are internally discussing some options for improving this - as you noted the activity on the existing beta forum is pretty limited. We want a forum that everyone has access to where we can have collaborative discussions on NXG. The specifics are still being hashed out but I will update when I have more information. Regarding your question about Links - LogMAN's explanation is correct - files under Links are non-addon dependencies located outside your project folder on disk, for example if you use a subVI that is saved elsewhere. This should be uncommon
  5. Hi everyone, Apologies for the slow response - this thread kicked off a number of internal discussions within NI and I was waiting for some of those discussions to shake out before setting up these engagements. First of all - I have set up a calendly link for scheduling time slots for 1x1 discussions. This is my first time trying calendly, so I have set up 30 minute time slots for three days later this week. Let me know if you have any suggestions or tweaks to make this more effective. Thank you in advance to those of you willing to take the time to talk to me, I appreciate it! In th
  6. So first I want to acknowledge some areas we could have done better. I have been involved in a number of discussions around what our migration strategy looks like, and the biggest gap we immediately identified is a lack of clear external messaging, so that is something we are looking to address. I have talked to all different kinds of users, and in a relatively short discussion we are able to align on whether or not NXG is ready for their use case. That is great, but you should be able to make that determination yourself by looking at public documentation, it should not require a call with me
  7. First of all, hi everyone and thank you all for the feedback. I really do appreciate it, and I want you to know that I generally read these threads even if I don't always participate. Stephen also periodically sends threads to me and the other relevant product owners. I am the product owner responsible for G language in LabVIEW NXG. There are other product owners responsible for other aspects of LabVIEW NXG and the related technologies. Our role in LabVIEW R&D is to advocate for the user within the development team. We am ultimately responsible for making sure the functionality we add
  8. LabVIEW 2013 SP1 was released March 3rd (Monday), it will be going out through Update Service on March 10th which is why there is the confusion about the release date on the download page (the download page is wrong). Thanks
  9. I looked up your crash report and it seems to be crashing in agtrmsimulate.dll, which looks like a 3rd party driver dll. Hopefully that helps you narrow it down. I would double check how you are calling the driver.
  10. Great to hear! The fix in that file will be included in the next f patch for 2013 (when/if that occurs), it will also be included in LabVIEW 2013 SP1 when that gets released. After that time, it will no longer be necessary to manually replace that file. Thanks
  11. Hi LogMAN, I looked into this more and found a case where the patch did not fix the issue. I have tested with your specific case against our new fix, and I believe it should now be fixed. If you take the attached VI and replace the file at LabVIEW 2013vi.libAppBuilderEngineAB_Engine_Update_Source_from_Linker.vi with it, you should be able to build. Please let me know if that doesn't work. Thanks AB_Engine_Update_Source_from_Linker.vi
  12. Hi, To close the loop on this, the LabVIEW 2013 f2 Patch is released on the web and will be going out through NI Update Service in the near future. One of the fixes it includes is for this specific installer builder CAR 429282. The details for the patch are located here and the 32-bit download is located here Thanks
  13. Hello all, I just wanted to let you know that we are aware of the issue described in the first post (the problem with builder an installer with certain VIs). In this case it is a VI from the automotive diagnostic command set library (CAR 429636). This is caused by a change in LabVIEW 2013 to the installer builder. There are two parts to this issue - 1) If your project contains VIs in certain libraries, you are not able to build an installer that contains these VIs. There is no workaround for this and we intend to issue a LabVIEW 2013 f2 patch which will address this. (CAR 429282)
  14. Hi John, I was only able to reproduce this with objects, but I filed CAR 422905 on it. Thanks
  15. If you search ni.com/downloads and narrow by 2013 and NI Developer Suite you should be able to see the downloads for the three Platform DVD if you have SSP on the account you are searching with. The search URL I used is here - http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/sn/n1:2013,n8:142,ssnav:pdl/ Hopefully that works for you! - credit to Altenbach for the quick search path
×
×
  • Create New...

Important Information

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