DigilentFan

That is great news, Attila! Thank's for your quick response and keep backwards compatibility alive...

Hello DIGILENT SW-Developers! When will Waveforms become compatible to VirtualBench again? In Waveforms Version “digilent.waveforms_v3.18.1_64bit” I had access to NI Virtual Benches. I installed digilent.”waveforms_beta_v3.18.58_64bit” and could no longer find my NI VB. After reinstalling “digilent.waveforms_v3.18.1_64bit” it was shown in Waveforms device manager again. v3.21.3 does also NOT support communication with Virtual Benches. At least not self-explanatory. I hope the compatibility/support for NI VB is not actively abandoned (for what reason ever). I am wondering since NI acquired DIGILENT. Waveforms has some outstanding advantages compared to the YSWYG VirtualBench Software. It will be hardly possible to explain to customers (that bought multiples of virtual benches as well as analog and digital discoveries) why the support was actively abandoned by NI from waveforms v3.18.1 onwards. I like DIGILENT since years (cope with NI HW/SW) and hope NI as new owner will stick to the right ideas https://www.ni.com/en/perspectives/letter-to-customers.html . Thanks in advance for every efforts making Waveforms work with VB (again)! Digilent Fan

Thank's a lot for the quick response!

Sometimes, (if digital protocol analysis struggles) it is desired to decode protocols at analog input signals (for e.g. to look in depth into rise/fall times, signal levels changed by pull resistors etc.). Is there a way to select the analog inputs as source for the protocol decoders in waveforms? If yes, how are the signals mapped to LOW - HIGH? How to use it? Is it possible to mix up analog and digital signals (for e.g. in case of I2C: SDATA as analog and CLK as digital input)? If not is there a suggested way around (for e.g. acquire analog data, and feed this data into a script, performing the one bit AD conversion as well as the protocol decoding) with the advantage to get decoding done by waveforms?

Thanks for your quick response! If a high impedance is a must (for e.g. with weak pulls) only DIOs DIO 34 to 39 work (not surprisingly) as desired. For DIO 1-23 results are not as good since the pulls in the Discovery conflict with the bus pulls... The restriction is given by design. since D³ always pulls at DIO 1-23, even if not desired.

The pull resistors are selectable (0/Z/1) for DIO 34 to 39. For DIO 0 to 23 the only Option available is (up/MIDDLE/down). For some application a HIGH impedance (not MIDDLE but Z) would be useful, for sniffing signals for e.g.. Is there a hidden option/workaround to get high Z working also for DIO 0 to 23? Thanks in advance for every hint!

Dear Digilent Discovery and Accessory Designers no question but a note: In my application I designed a PCB to reduce patching the D³s cables to one time at setup. This works fine, however (in contradiction to the probes of my MSO-Oscilloscopes where the digital probes are less or max. 2,54mm) the pins of the D³s adapter cables do NOT fit standard 2,54mm pin headers. It would be advantageous if Digilent could sell these cables (the solution with the color map is perfect) in dimensions with no over tolerances of the pin’s footprint leading to that problem. In the meanwhile, I will subdivide the pin headers and rearrange with voids between for my upcoming PCB designs.

In some test setups/test systems for low power devices it is desirable to have as little impact on current consumption as possible by the test setup itself. For test systems this is achieved by separating the IOs physically (relays, opto-couplers (bad for signal integrity), ...) to get rid of or (at least) minimize current flow across IOs and its protection circuitry. A simple approach to keep cross supply (and sinking) via IOs low is to track VDD of the device under test and adjust VIO according to the measured VDD. (I use this by tracking the analog voltage with an analog discovery and setting VIO of the digital discoveries). However, it would be very nice if the Digital Discoveries could support a “VIO sense” input to define/set VIO (port wise) and replace this (software based) approach by hardware to guarantee least voltage offset (between VDD of the Device Under Test and VIO of the Digital Discovery), tracking response (regarding time) and in general saving system resources. Did you ever plan to implement such a feature in upcoming versions of the D³s devices?

Hello Attila, thanks for your immediate response, resuming the possibilities to control the discoveries without Waveforms. The information how to save the setup information in a readable format is missing, maybe because Waveforms does not support it. For the VirtualBench the configuration is accessible as attached. Is there no (hidden?) feature to make (save) the workspaces also human readableVB8012_.vbconfigVB8012_.vbconfigVB8012_.vbconfig for the discoveries?

Hello Digilent specialiststs! I am working with 2 D³s and one NI VirtualBench, all 3 controlled by separate instances of Waveforms. Saving and reloading workspaces works fine for all of them. To automate measurements it would be favorable to modify the ".dwf3work" files and reload them programmatically. Up to now I could not find a way to get these files in a human readable format to edit the workspaces (i.e. test setups). Further I could not find a way to import the workspaces to my planned application (in Python). My favored way would be: Setup measurements by the Waveforms instances (since setup by GUIs is very user friendly, fast and well (reproducible) documented by the “.dwf3work” files) Save the workspaces for every test and Waveforms instance Write code (for e.g. in Python) to recall workspaces (from 2.), perform the measurement and process measurement data for every test. This would be a good trade-off of test development time, test duration and test cost for my project. Off course it is clear, that you could setup the whole tests in Python (with the API) without the Waveforms UI. And it might be possible to perform it by “script” in waveform, but I am afraid to run into script’s limitations … I am convinced, the graphical setup and automated reload would speed up my work and improve test documentation if the workspaces are human readable (or could be may human readable). All references and suggestions are welcome, thank you in advance