[Scope.Measurements aqcuisition number and auto complete]

On 6/21/2023 at 11:57 AM, attila said:

Hi @danaur

Try using measurement names without underscore and "~!@#$%^&*()+{}|:\"<>?,/;'[]\\-="

The underscore is considered by the autocompletion as the end of word, and therefore does not display child nodes, functions, properties correctly.
Fixed for the next version and adding note about this feature in the Help.

Thank you for the observation.

Hi! Sorry for necroing this: Has this fix regressed in 3.22.18? Because for me, it works sometimes, then only shows some, and then doesn't at all in others:
If I press Ctrl+Space after only alphanum characters, it shows all matching attributes.
If I press it after an underscore, it only shows some (!).
If I press it after another alphanum after an underscore, nothing is shown.
See attached images.

[DIO selection limitation with I2C, SWD]

Thank you, both, for a quick answer.

While I could manage without clock streching on that bus, I need it on the other that I switch to (that would be within allowed range), and I would prefer more analog buffer. To avoid future mistakes, I'll probably bodge the 5 rev1 PCBs to match rev2, instead of software workarounds.

If I may suggest, the title of this thread could be changed to something like "DIO selection limitation with I2C, SWD" to make it better searchable for future people.

[DIO selection limitation with I2C, SWD]

Hi!

Waveforms 3.22.2, AD3

Protocol.I2C.SCL.text = "DIO 14"
Protocol.I2C.SDA.value = PIN_TEST_SDA;

Expected: SCL set to DIO 14

Actual: SCL set to DIO 10

I can't set Protocol.I2C clock or data pins to values (or texts) above DIO10 (DIO9 on AD2). For that matter, with SWD it only goes up to DIO 9.

Is this a hardware limitation? Is there any workaround? Where might such limitations be documented?
I'm bringing up a custom "functional tester" board, that implements the pinout of the AD2/3 connector... but the on-board IO expansion is on pins 7 and 14 (because that made routing make more sense, and because I didn't know there were limitations)

EDIT: Also confirmed on 3.22.18

[Waveforms crashes when opening "Script" window]

This is the most operative tech support from the manufacturer I've had in my 7 years of active engineering life. Kudos!

[Waveforms crashes when opening "Script" window]

Okay, found it.
If this static configuration (in "C:\Users\xxxxx\AppData\Local\WaveForms\static.dwf3") is used, then the crash happens. When i renamed it and allowed waveforms to recreate it, the workspace now loads every time. Restoring this static config restores the bug.

static.dwf3

[Waveforms crashes when opening "Script" window]

Workspace sent privately.

Additional info: I installed 3.21.22: On first run, the workspace opened successfully. I immediately closed the app, then tried to reopen the workspace, and it failed.

EDIT: 3rd and 4th attempt were successful, 5th failed. Fully stochastic AFAIKT :)

[Waveforms crashes when opening "Script" window]

Hi!

Title says most.
The installation may be a bit messy, as I installed beta 3.21.19 for a while to get SWD support. I then discovered that a workspace I'd been using successfully to do production testing on my EExplorer failed to load.

I downgraded to 3.21.3 where the issue remained, then fully uninstalled (using Digilent Software uninstaller), then installed 3.20.1 where the issue remained ( and additionally, where StaticIO doesn't work on EExplorer) and am now at 3.21.2.

Trying to open Script crashes the app whether I:
* Open a workspace that contains Script
* Open Script from the Welcome menu
* Regardless of if I use a physical or demo device
* Regardless of which Demo device is selected

Weirdly enough, I did get the Script window to open sometimes (feels like a 10% chance) and it worked fine, but I've yet to find any rhyme in what steps of flailing around result in a functional Script window.

Another potential hint is that the SWD tab has remained available in the Protocol window, and the app seems to remember my "recently used workspaces". So it would seem the uninstall was not as thorough as one might hope.

Of course, this first manifested when I was trying to teach production how to use the test rig, but that's just life.

[Electronics Explorer Troubleshooting]

35 minutes ago, attila said:

On workspace save or load all the instruments are stopped, including the power supplies for which the stop means turn off.

The way I tested, was to turn on the power supplies, and check what the display showed me (and then verifying with a multimeter). It wouldn't have shown anything if the supplies were off, so I'm positive that I enabled it. Also: toggling the physical power switch changed the output level between 0 V and 23 mV. Also also:  the problem was apparent in one workspace and not in the other, over several back-and-forth switches.

EDIT: To avoid a triple post: Now all the calibration is gone, my scopes show anywhere from -90 to 90 mV while connected to ground. So it doesn't store it in EEPROM?

[Electronics Explorer Troubleshooting]

Okay... Update: After encountering an issue where in a new workspace the positive supply refused to work when current limiting was set to below 200 mA (Output current at the time was 34 mA), I went back to the old workspace (attached in previous post) and tried to see, if the same happens there (ie. does raising the current limit enable the supplies). Well, now in that workspace, the supplies just work, current limiting and all... and returning to the new one, it also, again, works. Whatthe?

[Electronics Explorer Troubleshooting]

Hi!

The VP+ and VP- supplies have stopped working. Opening a new workspace restores them. Reloading the same one from disk disables them again. Happened after supplies and/or reference and/or scope calibration and/or saving the workspace and/or duplicating the scope display, not necessarily in that order. I've attached the offending workspace file.

Board S/N 210151263040, if it helps.

default.dwf3work