1 / 62

IPN Project template

IPN Project template. 12th April 2013. ANALOG. Problems with an undisciplined structure. LabVIEW and cross-linking. What has tended to happen in the past ? VIs written for a previous project are reused in a new project . (We want to be able to do this and this will continue to happen!)

desirae-wheeler
Télécharger la présentation

IPN Project template

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPN Project template 12th April 2013

  2. ANALOG

  3. Problems with an undisciplined structure. LabVIEW and cross-linking. • What has tended to happen in the past ? • VIs written for a previous project are reused in a new project . (We want to be able to do this and this will continue to happen!) • Issues that arise from this include. • Dependencies of the VIs reused are called from many different locations. • Copies of the SubVIs spring up in many new locations. There is uncertainty which SubVI you should use. • Cross linking becomes a nightmare if you attempt to repeat a test months or years later. The confidence that the VI will run as it did before will be low. It will likely load with missing or broken dependencies.

  4. Preventing Cross-Linking issues in LabVIEW Project explorer Where are all my dependencies coming from? • The project explorer has tools to help keep track of project files and their location. • The project explorer window will warn you when it encounters cross-linking. • VI’s of the same name are opened in different application instances by default when using the project explorer to open the VIs. Do I have cross-linking issues? Previous projects had VIs of the same name.

  5. Project application instances (Demo)

  6. Project Library benefits Preventing Cross-Linking issues in LabVIEW • Project libraries provide a namespace qualifier for VIs and other files that belong to the library. Project_library_name.lvlib:VI_Name.vi • VIs of the same name can be loaded in the same application instant if they belong to different project libraries.

  7. Where Project Libraries are useful. (Demo)

  8. Should I use project Libraries? Project Library Pitfalls • In a group project only one developer should work on any given library at a time. This is an additional overhead that must be considered if you choose to use project libraries. • Conflicts associated with project libraries are difficult to resolve. • Project Libraries are easily corrupted if a VI belonging to a library is inadvertently moved. • Good for distribution post development. Not good if group development is on-going. • My project template is only a starting point. I want people to have the flexibility to easily make changes to the code when required.

  9. Conclusions • All code modules (and associated supporting VI) that make up the framework of the IPN template will belong to one high level labVIEW project.lvproj • For the life of a give evaluation project , all code development should be carried out from inside this high level labVIEW project. • As code is added to the project , use the project tools and file view tab to keep on top of cross-linking issues. • At the end of a project you should have a well grouped set of VIs that will be easy to archive.

  10. Tip: Dynamically Loaded Files • Dynamically loaded VIs will not be in memory until they are loaded by the caller VI. As such they will not be listed in the project dependencies. Recommendations: • Group the dynamic files in a separate folder within the scope of the project. • Refer to these files using relative paths. • Manually add the files to the project if you are not using auto population of folders.

  11. IPN Project template dependencies. • All code I have written to support the framework is stored on SVN. • Dependencies not under SVN control are restricted to Program Files\National Instruments…. (Demo menus dependency)

  12. Missing dependencies. (Instrument drivers)

  13. Missing dependencies. (I2C Driver) Installer for the I2C driver is included within the template. This is also available online at: http://zone.ni.com/devzone/cda/epd/p/id/6080

  14. Missing dependencies. (OpenG) JKI’s VI package manager can be used to download openG dependencies. http://jki.net/vipm/download

  15. Missing dependency risk. (Discussion) • Dependencies under program Files\... Are from sources outside our immediate control. • What if we come back to a project in the future and these dependencies have change? • On downloading the template you find that an instrument driver you need is no longer online. • Any ideas? • At the end of a project, dependencies are zipped up and stored on SVN with the project. • Should the template have a zipped version of the dependencies as they are today?

  16. Starting a new project. (Try this out) 10 to 20 min • Under C:\SVN create a new folder for the project. (e.g. ADuCMxxx) • Export the template code from the repository to this location. ( Do not use checkout, you just want a local copy ) • Open C:\SVN\ADuCMxxx\programs\IPN_DUT_Eval_Project.lvproj. • Install all missing dependencies if there are any. • When all dependencies have been installed or located, resolve any conflict. • Ensure your local copy is clean and as you want it before uploading it to a project folder on SVN. • Note: Make sure all dependencies are present before trying to resolve conflicts. Most initial conflicts are as a result of missing dependencies.

  17. Should we put the *.lvproj file under SCC?(Discussion) • We have already shown that all project work should be done from the project explore window. • Anytime a file in the project is renamed or added, the *.lvproj is altered. It follows from this that only one person should be altering the project (.lvproj) at a time. • If you are the sole engineer working on a project then the .lvproj can be on SCC. • My recommendation for group projects. • Team members should maintain their own local copy of the .lvproj file.(could consider storing this under SVN prefixed with engineers name) • The modules and shared_resources folders should be set to auto-populate. • All new code is added under one of these 2 auto-populating folders. • As team members Update from SVN , auto population will update local projects with new code committed by the team.

  18. Tip: Using Code From a Different Project. (Demo or try) From Project B to Project A (If both are on your C drive) Open both Project A and B’s .lvproj Open the original VI in project B. Choose File > Save As, and Create an unopened disk copy. Save the copy to project A’s folder. Close the original VI from project B. Add the copy you just created to project A, and use that copy in your code. (adding will be automatic if auto population is on.) From Project B to Project A (Project A is local, B is on the repository) Through repo browser find the VI you want to use. Export this VI to a directory under Project A. Use project explorer to ensure all dependencies are present and are coming from the correct place. Resolve any conflicts before using the VI.

  19. SVN tips Before loading files to SVN try and make sure directory structure is correct and the names of VIs are as you want them! Once under SVN control, renaming and/or moving VIs basically takes the 3 following steps : 1) Open the VI to be renamed in LabVIEW editor. 2) Go to file explorer and SVN-rename the file (or SVN-move or SVN-move-and-rename). 3) Back to the opened VI, click "Save as...", choose "Rename", overwrite the SVN-renamed file. That's it ! SVN history line is not broken this way, and the procedure is quite simple to learn and use. "VI not found" warning can safely be ignored. LabVIEW "Save all" and a global SVN-commit logically follow these steps to save pending changes.

  20. shared_resources • shared_resources contains the support files that belong to more than one module. • The VIs contained inside the shared_resources folder do not call on dependencies outside of the shared_resources folder. (Besides those under Program Files\.....)

  21. global_configuration. (demo and try) • A single place where global attributes of the project can be configured. • The configuration is stored in a configuration file at ..\shared_resources\ini_file_support\Configuration_files\Configuration_computername.ini • In a group project , each setup can have it’s own default configuration. • When global attributes are added or modified , delete the configuration file before running the VI. • Communication protocols Implemented so far are • UART • miDAS Serial wire • HSDIO Serial wire • SPI (4 wire) • At start of a new project this VI will need to be adopted for project specific attributes

  22. global_configuration. (feedback?) • There should be a way for the Global configuration VI to be launched from the GUI for quick access. It can be hard to find! • The Global configuration VI must be run every time you reload labVIEW. This is to ensure FGVs are loaded into memory. Look at ways of improving this.

  23. DUT Communications. (discussion)

  24. UART Communications.

  25. UART Communications. • Open ..\shared_resources\dut_communications\UART\type_defs\UART Functions.ctl

  26. UART Communications. (Demo)

  27. coda_to_regmap_converter. (demo and try) • Open ..\ modules\coda_to_regmap_converter\Coda_to_LV_Regmap.vi • Will convert a set of coda .xml files into a labVIEW readable binary .regmap file • Only has to be run if the Coda has been updated.

  28. coda_to_regmap_converter. (feedback?)

  29. coda_gui_interface. (demo and try) • Open ..\modules\coda_gui_interface\labview\ CODA_Register_Interface.vi • .regmap file loaded from ..\shared_resources\CODA_regmaps • Help learn about the part pre silicon. • Initial debug interface when silicon arrives. • Build register read/write sequences. • Search for register bit fields.

  30. coda_gui_interface. (feedback?) • The log feature is implemented using a multicolumn listbox. Usability would be improved if this list box was changed to a simple string field . This would allow easy editing on the fly and allow copy and pasting. • The log window is tied explicitly to the coda_gui_interface. If the log was a separate entity then any code module could update the log. This would be a feature worth investigating. • Bug: CODA GUI is not displaying the latest register values when you toggle between registers. • The Boolean register value field was removed from the latest version of the coda_gui_interface . This feature should be reintroduced in some form. A separate pop up window might be the best way to handle it. • The coda_gui_interface VI and the command_parser VI do similar things. Their functionality could be combined into a single interface.

  31. command_parser. (demo and try) • Open ..\modules\command_parser\ Demo CodeViewer.vi • .regmap file loaded from ..\shared_resources\CODA_regmaps • Interpret and debug user code.

  32. command_parser. (feedback?)

  33. dut_board_support. (Matrix) • …\modules\dut_board_support\Matrix_GUI_and_Support\Matrix_GUI.vi • Based on the ADG2128 12*8 matrix. • Code has an easily expandable architecture to quickly build a GUI for a system using ADG2128s

  34. dut_board_support. (feedback?)

  35. Modules: dut_test_code. Motivation • Provides a test template structure to help build a DUT test quickly. • Integration tools to allow the test step to interface with the test_sequencer code module. • Low level tools to help communicate with the DUT. • The main focus of the dut_test_code module is to help standardise result gathering during characterisation. • Provide code blocks to initialise and store results structurally. • Combine the acquisition and analyses of data. • Tests written should be easily repeatable in the future and with confidence that the results will be consistant • There has been no structure on how this was done in the passed. (discuss)

  36. Modules: dut_test_code. Test data overview • Data can be broadly defined as raw data and scalar data. • Raw data is the lowest level of data gathered and is typically viewed on an XY scatter plot. • Scalar data is the information extracted after analysing the raw data. • Examples: DAC Linearity test. • Raw data = DAC codes vs measured DAC output voltage. • Scalar data = INL, DNL, Offsets , TUE … • Result attributes: • Are the conditions under which the test was carried out. • They help to filter the data. • Provide information to help successfully repeat the test. • Attributes include: Temperature , Voltage, DUT ID , LOT ID …

  37. Modules: dut_test_code. Simple trim test example. Requirements • Voltage reference with a 4 bit voltage trim. • The test must check the reference at all 16 trim settings and choose the code when the ref voltage is closest to a target value. • Part has a secondary current trim that can effect the reference voltage. • The reference has an output buffer which can have compensation enabled of disabled. • Current trim value and buffer compensation state must be captured in the results. • Required scalar results • Target voltage searched for. • Code where the voltage is closest to that target. • Voltage measured at this code. • Percentage error of measured voltage from target voltage.

  38. Modules: dut_test_code. Feedback • Automatically detect if the test step VI was called from the sequencer. • At the code step level , look at a way of determining if global configuration was carried out. • Look at the possibility of easily changing the result file delimiter. • Make sure that no delimiter or carriage return/linefeed characters are present in any result field entries. • Add a button that cleanly abort a running test. Alternative to hitting the LabVIEW abort button. (flush the queue, and run cleanup code on aborting)

  39. Simple trim test.

  40. Raw data.

  41. Scalar Data.

  42. Result_Data_Information cluster.

  43. Trim test raw data.

  44. Trim test scalar Data.

  45. Additional attributes. • The test definition requires two additional attributes. • Buffer compensation state. • Current trim state.

  46. Additional attributes.

  47. Scalar results file.

More Related