Hi, I'm a EE currently working on a project with a group of others. Some in the group have significant Labview expertise and are developing .vi's to control NI-device-interfaced hardware that others & I have developed. Those in our group that "speak Labview" are fairly comfortable reviewing and debugging each others' designs by reviewing the .vi files. Unfortunately others of us such as myself have minimal Labview expertise and will remain that way for the foreseeable future. To accurately/readily review .vi code, we would like more traditional formats such as Timing Diagrams. In my experience, such formats not only can serve a broader scope of reviewers (thereby being more appealing in the marketplace as well?), but in many cases they hold potential for being more illuminating for reviewing, debugging, communicating, and so forth.
One of our software developers offered to develop such a tool, but as with most projects our staffing & time resources are scarce, and like many projects, software is currently on critical path.
I suspected that one or more tools to generate Timing Diagrams from a .vi already existed from NI and would have been in routine use by some developers. Or if not from NI, then 3rd-party, or somewhat redundantly developed by thousands of project labs around the world. NI Technical Support Engineering has suggested that I submit this entry here, so I am, first-time NI submitter. The suggestion isn't tied to our project's particulars, but if the above suggestion isn't sufficient, possibly the below info about our application will help. Thanks!
about our own application
Our medical-therapeutic research device will use a myRio-1900, interfacing with a user via wireless to a laptop. The laptop will use code being developed with Labview. Rio code is being developed with Labview-RT for the processor, and with Labview-FPGA for Rio's FPGA portion. Interfacing to Rio's I/O, much of our custom circuitry is SPI-based, but with particulars that preclude using Rio's native SPI, so we've developed lots of SPI in the FPGA. Among the external circuitry there's a total of about 100 SPI-interfaced a/d's, d/a's, and GPIO-interfacing chips. 16 battery-packs, each recharged by the instrument under software control, provide >500W of power to various regions of circuitry that spans 32 voltage-isolation barriers.
Here's one example of how the proposed tool would have helped us in the recent past. (This would have been easier without COVID19 so that we could all be co-located and with the prototype, but ....). During some debug, we eventually found that some bits were being generated or sampled on SPI clock (SCLK) edges that weren't compatible with some of the peripheral chips. This would have been readily apparent if we had had timing diagrams showing the .vi outputs nCS, SCLK, and MOSI. Those by themselves would have been highly helpful. In addition, also helpful would have been to see some nodes that are internal to the .vi if possible, such that we could know when the incoming MISO line was sampled relative to SCLK. We didn't need to see propagation delays etc., we just needed to see the logic manifestations on a diagram or equivalently easy for a .vi-illiterate human to digest.
Hope that's helpful.
-- Bruce P. 8/10/20
