2461: when pulsing with 100V range, extra 50ms spurious output after trigger

Running into some odd behavior with the 2461. When using source current / digitize voltage in pulsed mode, if the pulse amplitude limit is >21V (such that the 100V range is required) I see some unexpected voltage output after the trigger model has been initiated, but before the digitize begins.

Looking at the trigger model it seems to fall about where the first 'Source Output: On' block occurs.

Of course, since this is before the digitize starts, it does not show up in the 2461 output data; it is necessary to monitor the load with an external scope to see it. The spurious output is just over 50ms long, and appears to be around 750mV (not exact.)

So far I only see it happening when using the 100V range for the 'top' of the pulses. The 'standard' (or 'bias') range remains at the default of 7V (the bias current amplitude is 0A, limit should be low.)

The only other mention of a similar issue I could find was this thread on the old Tek forum:
https://forum.tek.com/viewtopic.php?f=263&t=142365&p=288913
where user JosefG remarks,

If the voltage range is too high the error happens and before the 10A pulses are generated there is an additional 500 mA [artifact] (width: 50ms) on the output.

(Based on suggestions in that thread, I left the 'default' limit at 7V but it does not resolve the issue, seems to have been related to another issue.)

This is particularly irritating because there seems to be no way to detect this has happened. I am using the digital IO lines to synchronize the SMU pulses/data capture with external equipment; this 'spurious output' causes all of the 2461's actions to be delayed by ~50ms but there is seemingly no way to detect that it has happened (since it comes after the "wait for trigger pulse" block in the model.)

Is this a bug? Or, if this is intended as some sort of "probing before output turns on", is it documented anywhere, along with an exhaustive list of conditions that cause it to happen? As it stands, this makes accurate & reliable synchronization more or less impossible when using the 100V pulsed range.

Additional notes:

* this is using 2-wire. (edit: also happens with 4-wire)

* To achieve the required trigger line behavior I had to input my own trigger model, but it is very similar to the model that is generated using the front-panel pulse wizard, and/or the `SOURCE:PULSE:TRAIN:CURRENT` command. After the config-list recall, it sends NOTIFY1 on DigOut 1 (set up as trigger output), and then waits for a pulse back on DigIn2 (set up as trigger input). Then, proceeds into the "Source On" block and the rest of the pulse train.

Any assistance would be appreciated, thanks!

PS - post editing on this new forum software is completely broken; the post gets converted to some markup format and does not get properly converted back when saving the edits. I had to basically re-write this to fix it after I tried to edit. This new forum software seems like more of a regression compared to the previous...

I got a capture of this happening into a 10 ohm load, the scope is seeing 1V into 10 ohms, so around 100mA for around 52msec.

Blue trace is the SMU output voltage, green/yellow are trigger pulses that are output as part of the trigger model (in this case they are being used to trigger the scope capture.)

The trigger model includes a 10ms delay before the pulse begins, but in total I see around 70ms:

* 5ms before the mystery pulse,
* 52ms mystery pulse,
* 13ms after (10ms of this 13ms is expected, per the trigger model)

Additional experiments confirm this seems to be related to the use of 100V range. Even if I request a lower pulse amplitude (say, 1A into RL=10), if I set the 100V range for the source pulse Voltage limit (using SCPI command SOUR:PULS:CURR:VLIM:LEV 100) I get this output.

With the limit back on a lower range (say 20V), I do see a much shorter pulse (~100mA for around 1.5-2ms, but not 50ms!) I would expect no additional pulse, or at least something predictable - the unpredictable (and undocumented) nature of this behavior makes it impossible to synchronize the SMU data with other instruments.

I came up with what might be a workaround: I already had a 2-way "handshake" between the 2461 and another instrument. I modified the trigger model on this one (that will be using the 100V range) to turn on the output (and thus, "get through" the ~50ms pulse) before waiting for the "ack" trigger from the other end. Also, I modified the other end to add a ~70ms delay before sending the "ack". That way, both sides can agree that the "ack" trigger pulse is t=0 without the uncertainty caused by the pulse when the output is enabled.

It's still not ideal (the timing is not predictable, it's not documented anywhere, and so there's additional energy being transferred that wouldn't be accounted for, among other reasons!), so a fix would be nice. Also, I verified that it happens when using TSP protocol as well (you can modify the "K2461 pulse" example in TSB to use the standard pulse train, and set 100V range for the pulse amplitude, and it should occur then.)