Coder Social home page Coder Social logo

niveristand-custom-device-wizard's Introduction

NI VeriStand Custom Device Wizard

This project template is a consolidated version of pre-existing project templates for creating custom devices. It includes the following templates:

  • Asynchronous
  • Inline HW Interface
  • Inline HW Interface (Inline-Async)
  • Inline Model Interface
  • Inline Timing and Sync
  • Asynchronous Timing and Sync

The scripting code uses a LabVIEW Class-based design that allows you to easily add support for creating new custom device project templates.

LabVIEW Version

The source for this repository is written in LabVIEW 2020.

Dependencies

Git History & Rebasing Policy

Branch rebasing and other history modifications will be listed here, with several notable exceptions:

  • Branches prefixed with dev/ may be rebased, overwritten, or deleted at any time.
  • Pull requests may be squashed on merge.

License

The NI VeriStand Custom Device Wizard is licensed under an MIT-style license (see LICENSE). Other incorporated projects may be licensed under different licenses. All licenses allow for non-commercial and commercial use.

niveristand-custom-device-wizard's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

niveristand-custom-device-wizard's Issues

HTML generation fails if CD is not placed under a folder with same name as CD

Describe the bug
If users copies and pastes the destination folder into the Project Root without putting the string at the end, then HTML chm file generation fails.

To Reproduce
Steps to reproduce the behavior:

  1. run the wizard
  2. Paste a folder path into the project root field
  3. create custome device
  4. build configuration release spec and notice error 7

Expected behavior
I suggest to create the final destination path of the CD as a combination of the project root + CD name, so user does not remove the naming at the end of the path, as marked here below:

image

Include Dependency on HTML Help Workshop

Describe the bug
User needs to know to have HTML Help Workshop installed. This is not documented in the CONTRIBUTING.md or README.md.

To Reproduce
Visit CONTRIBUING.md or README.md

Expected behavior
That this software is documented as a dependency.

Screenshots
N/A

Desktop (please complete the following information):
N/A

Additional context
N/A

Replace Linux x64 cRIO target with PXI

Is your feature request related to a problem? Please describe.
VeriStand 2021 custom devices are required to be compiled with LabVIEW 2021 64-bit. cRIO targets are not supported in LabVIEW RT 64-bit, so the cRIO target in the generated projects can not be built.

Describe the solution you'd like
The cRIO Linux target should be replaced with a PXI target that is supported in LabVIEW RT 2021.

Describe alternatives you've considered
None

Additional context
None

Generate SLSC Plugin code

Is your feature request related to a problem? Please describe.
SLSC plugins deviate sufficiently from HW plugins such that they require numerous edits to show up in VeriStand.

Describe the solution you'd like
Add a new option to generate SLSC plugin code. Also update post-build step to copy files to correct location. This is similar to synchronization code generation. http://zone.ni.com/reference/en-XX/help/372846M-01/veristandmerge/cust_device_xml/

Describe alternatives you've considered
Developers can create HW plugin and modify XML file to match expected SLSC format.

Add instructions for use in Readme

Is your feature request related to a problem? Please describe.
I want to use this tool in my project and it is pretty difficult to understand how to actually install it into their LabVIEW environment.

Describe the solution you'd like
Instructions on where to find the package installer and how to get started.

Describe alternatives you've considered
There are some directions in CONTRIBUTING that could be followed, but it doesn't seem like it was meant for users.

Update to dependencies

Describe the bug
The dependencies list should include LabVIEW Real Time to be able to successfully open templates such as the "CONSOLIDATED NI VeriStand Custom Device" template. LabVIEW RT is not a dependency to run VeriStand itself. However, since some of the templates use LabVIEW RT libraries, this could be a forgotten step. See NI case number 01247929 where customer did not realize this. They thought VeriStand would install it and that is not the case.

To Reproduce
Steps to reproduce the behavior:

  1. Go to Readme page such like on main Github page here https://github.com/ni/niveristand-custom-device-wizard.
  2. Notice that VeriStand and LabVIEW are required, but not LabVIEW Real Time Module
  3. Not having LabVIEW Real Time module causes dependency errors when opening many of the templates(customer and I did not test all)

Expected behavior
No dependency issues when opening templates

Screenshots
image

Desktop (please complete the following information):

  • OS: Linux RT and Windows 10

RT System Destination XML for Linux Targets

The existing XML template places the RT Driver VI.vi for the custom devices for Linux Targets in a c:\ni-rt\NIVeriStand\Custom Devices\ directory, not in a native Linux directory.

Should we be using a Linux directory, like /home/lvuser/ or something like that?

System Storage DLL is missing on load

Describe the bug
Opening in 2017 searches for System Storage DLL

To Reproduce
Steps to reproduce the behavior:

Open in 2017
Expected behavior
To not search for the DLL

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: Windows
  • Version [e.g. 22]

Additional context
This can be fixed with a .NET config file

Create unique name for Inline Async VIs during build

Is your feature request related to a problem? Please describe.
Compatibility-breaking changes to the Inline Async API can cause deployments of system definitions containing custom devices built against different API versions to fail. The wizard should handle creating build specs that insulate new custom devices from this failure.

Describe the solution you'd like
The Inline Async template should create a unique name for each of the Inline Async VIs included in the engine builds. See this SLSC EDS Custom Device PR for an example of what needs to change in the template.

Describe alternatives you've considered
There really isn't anything else we can do with the current templates and current VeriStand engine because everything must be built into an LLB, which has no namespacing.

Additional context
This change won't fix the problem in existing custom devices, but will provide a starting place for new custom devices that will not have the issue.

Rename PXI target to "PharLap" in generated project

The PXI target in the generated project is named "RT PXI Target".

This made sense when RT PXI targets only supported PharLap, but is ambiguous now that NI Linux RT is supported.

The PXI target should be renamed to "PharLap" to be unambiguous.

Make configuration file have correct assembly versions

Is your feature request related to a problem? Please describe.
The .lvproj.config file generated by the wizard does not update the assembly versions for the version of LabVIEW being used.

Describe the solution you'd like
The assembly versions for the config file should be valid for the version of LabVIEW used to generate the custom device.

Describe alternatives you've considered
None.

Additional context
N/A

Error on ImportExport.lvlib:Sysdef.SimpleImport.vi

When I try to create a CD I found an error on "Initialization Vi.vi" and another one on RT Driver VI.vi.

I'm not able to attach the png to show you the issue. In order to reproduce it, try to create a custom device and then open the Initialization VI.vi and the RT Driver VI.vi you'll find broken wires.

I'm working on LV VS 2020 and the wizard is 20.5.0.1

Create a package installer

Is your feature request related to a problem? Please describe.
Customers need to install the custom device wizard into the project template folder to use it.

Describe the solution you'd like
I would like a package installer (either NIPM or VIPM) to install the template files into the correct year based folders.

Describe alternatives you've considered
Developers can copy the files by hand, but that is error prone.

Support PPL based Async Custom Device Template in Wizard

Is your feature request related to a problem? Please describe.

  1. First of all, it's related to user experience. The custom device wizard template has a PPL Build check box for every type of template, but only few of them worked, which is quite confusing
    image

  2. Second, I do meet an issue when I use the LLB based template.
    I was developing an Async CD and the configure behavior worked well but when I deploy the system definition containing this CD it will report deployment error like
    image.

The error says the RT Driver VI.vi is non executable. Then I do some investigation and find that the built engine.llb contains extra files dependency as follow
image
But VeriStand won't deploy these dependency files so it's broken on the RT side. To verify this, I manually copy the depdency VIs onto RT and then the error goes away.

I think the root cause of this is LLB doesn't support namespace so when it tries to include VIs with duplicate names from different library it has to put them outside the LLB. And I think PPL could solve this issue because it always generates one single file(?).

Describe the solution you'd like
Add the PPL based templated support for Async Custom Device

Describe alternatives you've considered
Maybe manually do that? Or play with some LLB build spec option combinations? No time to digging into details so far.

Additional context
Add any other context or screenshots about the feature request here.

An ActionVIOnCompile VI is always generated, but the custom device XML does not always reference it

Describe the bug
Creating an asynchronous custom device generates an ActionVIOnCompile, but does not declare it in the XML. This is a pain point when getting started.

To Reproduce
Steps to reproduce the behavior:

  1. Generate an asynchronous (not inline-async) custom device.
  2. Note that an ActionVIOnCompile has been generated.
  3. Examine the custom device XML and observe that the action is not referenced.

Expected behavior
We should declare all actions we generate in the XML.

Cannot move the customproject and successfully run a Configuration Build.

Describe the bug
I created a custom device, but then wanted to move the project to a location that I use for development. After moving (and before building in the original location), I cannot successfully run a Configuration Release build. I get an error dialog with the message:

Error 7 occurred at Copy in LLB Pre-Build CHM Build.vi …
LabVIEW: File not found. \Help<cd_name>.chm

The generated Custom Device project Help path seems to be hard-coded at generation time in file \Help\Build.cfg. The path is stored in element name Base Path.

To Reproduce
Steps to reproduce the behavior:

  1. Run the wizard using Create Project... within LabVIEW (NI Veristand, Consolidated NI Veristand Custom Device).
  2. Name the custom device and Finish.
  3. Explore to the location and move the entire cd project folder out of its location to another location on disk. do not just copy the project as this will leave duplicates in place and will mask this bug.
  4. From its new location, open the LV project and run a Configuration Release build. You should see the error dialog quickly and the build will fail.

Expected behavior
You should be able to move these custom device projects around and run successful builds without having to modify a file each time.

Screenshots
image

Desktop (please complete the following information):

  • OS: Windows 10
  • Version: LV 2017 (but can be any version supported by the new Wizard

Install to 64-bit LabVIEW

Is your feature request related to a problem? Please describe.
VeriStand 2021 will be built against 64-bit LabVIEW. The nipkg generated by building this repo only installs to 32-bit LabVIEW. This will need to be updated. This is likely dependent on ni/niveristand-custom-device-build-tools#118.

Describe the solution you'd like
We should be able to install to either 32- or 64-bit LabVIEW, depending on what the build architecture is.

Describe alternatives you've considered
None.

Additional context
None.

Custom Device Wizard package should have a VeriStand Custom Device Development Tools as dependent package

Is your feature request related to a problem? Please describe.
If you only install the Custom Device Wizard from the release package, the Wizard will be placed in the Template project of LabVIEW but the generation will take arround 5 min and will fail at the end with error 7 on "Copy Template Files.vi"

Describe the solution you'd like
Make this package part of the dependencies so the user don't need to install it manually

Describe alternatives you've considered
Make the explanation a bit more clear of what dependencies need to be installed

Additional context
Add any other context or screenshots about the feature request here.

when creat new project with wizard , it will report file not found , I use the version 23.0.0

Describe the bug
when creat new project with wizard , it will report file not found . I use the version 23.0.0 and the labview is 2020 .

The report version is below:
LabVIEW: (Hex 0x7) File not found. The file might be in a different location or deleted. Use the command prompt or the file explorer to verify that the path is correct.
VI Path: C:\Program Files (x86)\National Instruments\LabVIEW 2020\project_Compiled HTML Menu Tool\Wizard\Copy Template Files.vi

_Compiled HTML Menu Tool folder seem that didn't generation by install step .

屏幕截图 2023-05-15 143653

Error -2202 LabVIEW: (Hex 0xFFFFF766) The specified name does not exist.

This is just to relay bug 1042483 (NI internal) - VS Inline-Async Custom Device template introduces a race-condition. It can be caused by NI VeriStand custom devices using the inline-async template. A temporary workaround is increasing the timout in C:\Program Files (x86)\National Instruments\LabVIEW 20xx\vi.lib\NI\NIVS Inline Async API_VS Inline Async API\VS Inline Async API\Methods\Async.Engine.Initialize.vi to something larger than 5000ms (e.g. 15000ms) and then rebuilding the custom device.

image

Hope this saves someone else from countless hours of debugging.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.