Rprog output is limited to set voltage or current on DCP405

[fietser28]

Make the rprog (voltage or current) honor the Vset/Iset limits.

In normal operation I always set things low to avoid magic smoke. With prog currently the voltage limit is completely off now. Looking into the schematics it doen't look hard to implement.

Attached is my proposed hardware change. It implements:

• Decouple Rprog setting from internal GND of DCP405 #93
• Allow external current programming? #87
• limits the output voltage or current to the current set current (given by the DAC). The limit is set in software and enforced in hardware (for speed).

Except for the #93 part: It's a design only! I did not test this in hardware!

Explanation of the schematic:

• The TL072 with combined resistors implements Decouple Rprog setting from internal GND of DCP405 #93
• The lower half if the schematics adds current setting thru Rprog (implementing Allow external current programming? #87). I used a free pin (pin 6 of IC13) to turn Rprog for current on/of. This is analog to the voltage setting circuit.
• The comparators LM293/LM393 compare the Rprog input voltage agains the output (Vset/Iset) voltages from the DAC. If the Rprog voltage is lower the analog switch will switch (thru AND gate) to the DAC output (where the limit should be set).

Impact on BOM:

• TL072, LM293, 2N7002 and SN74LVC1G3157 are already use so more of the same components. Parts with annotated numbers are already present in the current DCP405.
• New component is 74LVC1G08 (AND gate). I used a discrete logic gate to make sure the switching is fast (see the issue below).
• I did not check the C and R component but they are very common values.

Needed software changes:

• Addition menu to select current instead of voltage Rprog.
• Turning on/off Rprog for current should make pin 6 @ic13 (GPB5) high/low.
• During Rprog the set voltage or current should be send to DAC to set the upper limit (before turning Rprog on)

Possible issues.
There is a small race condition in this design: If Rprog steps above Vset/Iset, the signal will probably propagate thru the analog switch before it switches to the Vset/Iset limit due to the delay of the comparator, AND gate and switch. This is probably a very short period but is should be tested in the implementation if it is visible or problematic on the output (with or without load). E.q. will a step of Rprog above Vset/Iset cause an overshoot on the output of the DCP405?

[prasimix]

Discussion opened on EEVBlog forum: https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg3530232/#msg3530232

[prasimix]

This is a new proposal for Remote programming presented in #498.
Input op amp is changed to MCP6001 powered from single rail. LED driver is also changed, and 2G08 instead of 2 x 1G08 is used. I also added 10K on all comparator inputs.

[prasimix]

New proposal with corrections suggested by Kleinstein here:

[prasimix]

The tiny PCB for testing latest schematics has arrived, just need to find time to fill it up and test it.

[fietser28]

Nice, I have a EEZ-Flow to test most of it, but it's SCPI is written for a silgent AWG. It figures out (calibrates) the scaling and offset factor of the RPOG interface (and circuits in between), also if you are using scaling resistors in front of the circuit.
It also has a sweep to test the error (linearity) of the calibration over the whole range. Measurement and 'calibration' use the measured values from the DCP405 not an external DDM, I didn't need that kind of accuracy.

If you want to I can rewrite this so it can run with only a BB3 using:

• 1: DCP405 using its rprog as input with this device connected (=DUT)
• 2: DCP405 to program the rprog (I'm not sure if the DCP405 is precise enough, but with some scaling resistors this can be fixed).
• 3: DCP405/DCM floating 5V for board power (if you connect the tiny board to the DCP405 internal V-/V+/GND you won't need this.

Just let me know, I just have to find 1-3 evenings to rewrite the EEZ-flow. It will be Voltage only, I can't risk losing my precious DCP405's, I use them. But once it does voltage, it will be easy to change to current.

Let me know.

[prasimix]

I think that DCP could be precise enough, if not I can rearrange flow to use e.g. AOUT on MIO module. Anyway, no need to rush since I'll not be in position to assemble this PCB before end of next week. I have to prepare the latest AFE2 prototype first and will be busy with v1.7 testing, too.

[fietser28]

Here is the flow to test rprog function. I ran this with the latest studio version from GitHub:
RProgTester.eez-project.zip

It uses 2 DCP405 modules:

• channel 1 = module that is programmed via rprog (including modification or external opamp circuit)
• channel 2 = setting the input voltage for rprog testing.

The flow remembers the BB3 and the calibration data.

Using the flow:

1. Setup the hardware: output of module 2 should go to the rprog. Depending on the configuration you might have to connect the - output of module 1 and module 2 (when using the new circuit) OR NOT (direct connection on current DCP405 modules). Load is not really needed.
2. Setup BB3 settings: set module 1 in RPROG mode, for safety i usually set low current limits. Also set the OVP of module 1 to 40V.
   3 Run the flow:
   4 You have to select the BB3 and connect to it.
3. First time you run the flow you need to run the calibration (=button). This routine measures a low output and slowly increases the high output until 90%. After that is calculates the scaling and offset values (offset is usually equal to GCOM).
4. After calibration you can enter a desired output value, the flow will calculate the required voltage for channel 2 and set it.
5. After calibration you can run the 'errors check' routine. This is on a separate page and when you press start there it will sweep and show the % error between the output of channel 2 and channel 1 with respect to the calibration values.

The flow script honours the OVP setting of channel 1 and will not set higher values and the sweep will also be limited to it. Calibration DOESN'T honour OVP it goes to the max range for most accuracy.

If you put scaling resistors in front of the module, the script will still work. Just run a calibration and everything is adjusted.

I'm interested if setting the jumper to GCOM instead of GND will bring the offset to 0V instead of the 53mV.

And a screenshot:

The DCP405 is precise enough, although 5mV creates some noticeable steps, I worked around this by always comparing the measured values (with my AWG I only have set values).

[prasimix]

Excellent job! I tried flow and everything works. Of course, some things could be polished a little more, for example:

1. Put channels in default at the start (* RST command) to know the initial state. For me, for example, the channels were coupled and in tracking mode, so I had to cancel it manually.
2. The OVP set always generates a beep even though the OVP is set successfully. This is confusing, but maybe this is a firmware bug. We need to investigate this.
3. I managed to get at the beginning that my control DCP (in slot 2) voltage rises over 2.5 V all the way to I think 39 V even though the channel output was in off state. I don't know how to repeat this again, but there will probably need to be added some additional check.
4. the Set offset/DC button should be enabled or disabled depending on whether controlled DCP (in slot 1) is in RProg mode or not. The same goes for Error Check and Calibrate buttons.
5. Of course pasting some comment here and there into the flow would be helpful :)

We also need better support for graphs in upcoming versions of EEZ Flow, for example to see labels on the X and Y axes. My graph currently looks like this:

Anyway, feel free to commit this flow at https://github.com/eez-open/studio/tree/master/docs/tutorial

[prasimix]

2. The OVP set always generates a beep even though the OVP is set successfully. This is confusing, but maybe this is a firmware bug. We need to investigate this.

I found in BB3 Terminal lots of errors that were not visible during flow execution. Some of them may be related to setting up an OVP trip. The situation should improve when EEZ Flow gets a debugger, or we will need to somehow display such errors during runtime to make it easier to modify the flow. Some of them may be related to setting up the OVP trip level: