Leaving output on after get_samples() in non-continuous mode

[jmball]

I have an application where I want to take periodic, single-shot DC measurements of a device and have the output stay on between measurements. However, when I use get_samples() (or write(); run(); read()) for the measurement the output always turns off automatically.

Is there a way I could mod libsmu to prevent this and have the output stay on after the measurement? I have looked through the library and can't spot an obvious way to do it but I just wanted to ask to make sure I'm not missing something. If not, is this something that can be changed at the firmware level?

I have also tried doing this in continuous mode but I find there's always a ~0.2s delay after a write before the output updates and I'd like to minimise data transfer times by not having to read the whole buffer for every measurement, so it isn't ideal for this application.

[cristi-iacob]

Hi @jmball!

If I understand your use-case correctly, you basically only need the continuous mode, but without that ~0.2s delay. This delay most probably comes from the buffers/variables/threads initialization for the continuous mode mechanism, so I don't think you can prevent this delay.

One idea of how you can hack libsmu in order to remove this delay is to simulate a continuous behavior using single-shots. I think you can simulate this by sending multiple single-shots (maybe in a while (true) loop - or something similar) and you should somehow tell that while loop when it should stop (maybe using a flag) and start with the new value. You can do this directly from your program or you can try to implement this mechanism directly in libsmu. Probably one good place to do this in is the write() method from the M1000_Device class. Anyway, I don't know if this method will remove the whole delay (or at least minimise it to a supportable level) as there are a lot more single transfers involved, but it may be a solution for you.

Please let me know if you have any further questions!

Thank you, Cristian

[jmball]

Hi @cristi-iacob, thanks a lot for getting back to me!

Yeah, that's basically it. The motivation to use continuous mode here is purely to be able to keep the output on at the set DC value after taking a measurement. If I could do that in non-continuous mode that would be even better because I wouldn't have to read the whole 100000 sample buffer again before the next write.

What I've been trying so far to get close to the desired behaviour is a non-continuous write-run-read and then immediately reset the channel ouptut mode to SVMI. This turns the output back on again at the value used for the measurement, which is what I want, but with about a 3-4 ms delay where the output is off, which I'd like to avoid. I think your suggestion with the while loop would have the same issue because the output will turn off after every measurement.

I guess the auto-off setting after a run in non-continuous mode is at the firmware level so I'll try there next.

Thanks!

James

[jmball]

@cristi-iacob, just to follow up on this again, I found the part of the code in libsmu that turns off the devices after a measurement here. Simply commenting this out gives me the desired behaviour: the outputs stay on after the measurement is performed. I can then choose when I want to turn them off by setting the channel modes.

I think it would be great to have a feature in the library that gives control of this behaviour to the user, i.e. an "auto-off" flag that determines whether or not that code block gets run after a measurement. It's really useful to be able to keep the output on when performing measurements of a device over a long period of time but where you only need to sample data infrequently.

[jmball]

Contrary to my previous comment, this behaviour is already supported by calling start() instead of run(). start(), unlike run(), doesn't wait for the measurement to complete so never attempts to disable the outputs.