Jump to content

Error generation preview in Installer Properties caused by Automotive Diagnostic Command Set 1.2.0


Recommended Posts

The Automotive Diagnostic Command Set (ADCS) in version 1.2.0 when used will prevent the installer to generate a preview, set properties of any application executable, and building the installer, due to a bad linked VI. The installer dialog will just show '<Error generating preview>' in the application details section. I got this issue on a new installation of LabVIEW 2013 and this behaviour has since been reproduced by an NI technician. A bug report has been filled in:

 

CAR 429636

 

There is currently no way to build the installer including the application. It is not possible to add the offending VI to the library, as the library is locked & password protected. My solution was to build an installer for just the additional installers (runtimes, etc..) and to manually copy the application files to the target system. Here is a copy of the issue details from the initial thread that is also linked below. Please reffer to the thread to get more detailed information about the circumstances that causes the issue (and to see some actual pictures):

 

-----

 

The Automotive Diagnostic Command Set in version 1.2.0 does update the compatibility to LV2013 and adds a new feature that causes my problem.

 

Add an INI key to the LabVIEW.ini

NI_Appbuilder_logging=TRUE

The build log is created next to the *.lvproj file and directly shows the problem. Here is the important line of the build log:

The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'.

 

-----

 

Notice: I was able to start the build, because the installer has already been configured in LabVIEW 2011 SP1 & ADCS 1.1.0.

 

Here is the related topic:

http://lavag.org/topic/17137-error-generating-preview-in-installer-properties/

Edited by LogMAN
Link to post
Share on other sites
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Jim Kring
      [Update: NI Bug 974336]
      There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here).
      Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet.
      Coerce to Variant Fail (LV2019).vi


       
      Note that adding another element to the outer cluster causes the problem to go away.


    • By ShaunR
      Maybe others have seen this but I only became aware of it recently so I apologise if there is already a CAR for it.
      The following demonstrates a difference in behaviour between LabVIEW 2017 and previous versions (back as far as 2009, maybe further).
      The VI registers an event when it starts (in the timeout case) and generates a user event when the Increment button is pressed.
      The expected behaviour is that the counter will increment by one every time the button is pressed. This is the case for LabVIEW versions prior to 2017. In 2017, the user event is never fired, nor is there an error emitted by the generate user event.
      To get the VI to operate as expected in 2017; change the event refnum tunnel to a shift register. This seems to indicate that the refnum prototype is stomping on the dynamically allocated reference whereas in previous LabVIEW versions it would not. Note also, that when using the shift register, the cases do not need to be "wired through" as would be expected with similar functionality in a normal case statement.
      evnt.vi
    • By A Scottish moose
      Hey everyone,
       
      I am working on a backup function for a test executive.  The backup uses the 'class to XML' vi to create an XML string and then save it to a file to be reloaded later. All of my test specific information lives in the class (or one of it's children).  I like this functionality because it makes backup and reload brainless.  It just works.... until now... I've got a test class for my current tester that's grown rather large.  Everything works fine, until the tester loads some waveform data into either of the waveform arrays.  Without data in this field the class reloads just fine, otherwise if fails and says the XML is corrupted.
       
      As you can see in my backup vi I have built in a work around that flattens the waveform arrays to strings, drops them back into the class private data, deletes the waveform arrays and then writes the class.  This works! Much to my surprise both waveform data and the rest of the class data are written to file and reloaded without error.  
       
      Does anyone have any knowledge or experience with this? 
       
      Cheers,
       
      Tim


    • By Stobber
      If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why? See the attached code (LV15) for an example.
      I don't want to use the ACBR node right now because I want to set some control values of the VI ref on a different diagram than the one that will run it. (I just want to pass the VI ref between calling diagrams, not all the values that'll be passed into it.)
      DVRtest.zip
    • By drjdpowell
      OpenG’s Trim Whitespace fails on a string of all whitespace, if set to trim the front only.   It returns the last whitespace character.
×
×
  • Create New...

Important Information

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