Channel B always reads back as zero?

[damercer]

Hi:

I've been doing some more testing on the new master libsmu and it looks like the Channel B current always returns as zero.

To reproduce use the attached DC SMU program and connect a resistor ( or some load ) like 100 ohms between CHA output and ground and CHB output and ground. Set both to output 4 Volts and turn the channels to source voltage. Run. Display should be 4/100 or 40 mA. Channel A will read correctly but channel B reads exactly 0.00.

dc-meter-source-tool-1.2.zip

Works correctly for old master.

Thanks

Doug

[rgetz]

Doug:

I (or someone else) will double check - but I don't think PixelPulse has the same issue. It's likely a change the is necessary in the application, not the library.

• Robin

[damercer]

Robin:

You are missing the point. The original version of master works ( only discont mode supported ) the reworked version of master ( maybe just the most recent build ) does not work in either cont or discont mode. Function call and method to split out the individual channels is not changed between old and new only the order in the array.

Old:

ADsignal1 = DevOne.get_samples(SHOWsamples)
while index < SHOWsamples: # build arrays
        VBuffA.append(ADsignal1[0][index][0])
        IBuffA.append(ADsignal1[0][index][1])
        VBuffB.append(ADsignal1[1][index][0])
        IBuffB.append(ADsignal1[1][index][1])
        index = index + increment

New

ADsignal1 = devx.get_samples(SHOWsamples)
while index < SHOWsamples: # build arrays 
        VBuffA.append(ADsignal1[index][0][0])
        IBuffA.append(ADsignal1[index][0][1])
        VBuffB.append(ADsignal1[index][1][0])
        IBuffB.append(ADsignal1[index][1][1])
        index = index + increment

Data for only three of the four channels is correct. So if the C+ level of the code works ( I'd like to see proof) then the problem is in the Python bindings in Libsmu. So the point is this is not an application level issue.

Doug

[damercer]

I loaded an older version of rework libsmu (libsmu-0.9.0-g6f33b5a-setup-x86.exe) from early December and it also shows the same behavior so my guess is this never worked or at least was broken some time ago.

Doug

[rgetz]

Doug:

It's expected that the application needs to change when the rework branch was applied. That's the point I was making - it doesn't matter if an old application; doesn't work with the newest master - the application may need to be updated. There was no requirement for backwards compatibility when we started the rework branch.

You are right - we need to check things (and we will check PixelPulse). Right now I'm just guessing.

• Robin

[damercer]

Hi;

I believe is problem is (was?) caused by the firmware issue with 2.16 where writing the new calibration settings fails to return the board to a working state. The issue I posted here was closed and moved to m1k-fw. But I think there may still be differences between what happens when writing calibration settings with the old master libsmu and the new master libsmu when a board is loaded with 2.16 vs 2.09. This may all go away when the firmware is fixed,

I'll continue to experiment with trying to get a proper calibration loaded on to this rev F board with 2.16 loaded.

Thanks

Doug

[damercer]

I've convinced myself that this was due to the calibration settings being messed up by the issue with firmware Rev 2.16. So I'm going to close this issue.