Custom Device Template Tool as a Configuration Utility

[griffindore]

Custom Device development does not have a very good design/develop/test work flow. To improve this, the custom device template tool needs to be rewritten so that it better incorporates design before creating the project/library/VIs.

In order to better incorporate design into the process, I envision a custom device template tool that is configuration based. From this tool, a developer would be able to specify the pages, actions, RTM, dynamic buttons, help topics, and glyphs. The developer should also be able to specify any options the custom device or a given page, RTM, or button may use such as multiple target support RT driver VIs, delete protection, rename protection, RTM/button dependencies and behavior, etc.

Once the developer finishes designing the custom device, the XML should be fully implemented and all the necessary VIs (actions, pages, RTMs, etc.) would be created in the library. This would greatly cut down on the overhead of creating new files from templates and modifying the XML over and over. It also encourages developers to do more design of the custom device up front instead of designing while they code.

For completeness, it would also be nice if the tool had the capability of linking into Requirements Gateway or something so they could do requirements tracking. I'm not sure how this would work, but it's something that maybe should be investigated.

The final aspect of this idea is that there is a need for better testing of custom device developments. I find it difficult to do good tests because my code is always tightly coupled to Item Properties or other things that require VeriStand references. I think this tool could also script some high level test code that would be able to run the pages or RT driver VIs outside of the VeriStand executable. In order to accomplish this, I think VIs could be developed that use the SysDef API to load system definition item information outside of the VeriStand executable so that the references could then be passed to the appropriate page or driver VI. I envision the test VIs are wrappers that wrap up the page, action, RTM, or driver being tested. In the case of pages, the custom device would need to be added to a SysDef and the Init VI would need to be executed. Some pages would also require the section or channel being added to the appropriate section or channel as well. If the configuration tool could script most of this work, I think it would be very helpful.

Regards,

Mike

[Pie56694]

I want the new tool to import an existing custom device project and add functionality to it.  The custom device developer should be able to import a custom device project, click a button on the new template tool, and create a run time menu for a page/add an action VI/add pages, etc.  The tool will make the required modifications in the right place.

[Brandyn]

I have ran into the same issues you are.  I find it EXTREMELY difficult to test a custom tool or device once it is deployed in the VeriStand environment.  I think all of the things you are describing can already be done with the Veristand API and some intense LabVIEW coding.  What I would LOVE from NI is the documentation so I can actually do the things you talk about. 

[Brandyn]

If the API is good, then you can make Unit Tests with the Unit Test Framework.  This allows you to tie in requirements gateway.  Also theoretically, you can also put in the [REQ###] tag in you code and point Requirements gateway to it.