Scan setpoint failing when live monitoring is executing

[ajgdls]

SCAN SETPOINT
This works very well in the GUI, provided that LIVE MONITORING is disabled: otherwise some steps look to be missed in the scan! Check why the two things interfere and find a solution, hopefully allowing to continue monitoring and scan at the same time without problems.

[ajgdls]

@lstebel I have been testing out the setpoint scanning now that I have the power board operational. One statement is that currently it looks to take nearly 10 seconds to send each setpoint to the hardware because it is sending all values to all channels every time. Is that the same for your setup? During that 10 second period the TXRX is effectively saturated which is why I think turning on the live monitoring is causing issues.
Also, how can you tell that values have been missed, it wasn't clear to me?

[lstebel]

@ajgdls The problem was observed by chance while scanning from setpoint 0V0A (everything off) to setpoint VDD_ON. In the STATUS panel (live monitoring) we were looking at "Chip supplies", VDD_D3V3, VDD_A3V3, VDD_D2V5, VDD_D1V8 and VDD_A1V8. We used a high delay value (kind of 5s) and we had the evidence that some steps got missed.

[lstebel]

@ajgdls With your setup you could try to scan between setpoint 06_0_PixelVoltages_ON and 07_0_VoltageReferences_ON, with 4 steps, 1s delay. In the meantime keep looking at V_02_Chip_References in status panel. VRef_ADC_XX, Vref_DB_XX, VCasc_XX and VRef_PGA should be changing.
I MUST SAY THAT I DID THIS (on the system without a sensor) WHILE DOING LIVE MONITORING AND I HAVEN'T SEEN ANYTHING WEIRD! IN THE PAST DAYS I DARED DOING REAL SENSOR POWERUP AND POWERDOWN WITH LIVE MONITORING AND THE POWERUP WAS SUCCESSFUL. I WILL KEEP INVESTIGATING.

[lstebel]

The scan is indeed very lengthy, and that's my reason for asking #66

[ajgdls]

Yes @lstebel I think that what is happening is that it takes maybe 8 seconds for each setpoint to complete. During this time the live monitoring is often blocked and cannot update but the values are still being set.

I think the best idea might be for each scan point of each channel, if the value requested is the same as the current set value then do not send the messages. This would work for every case and there would be no need for a "fast" option. Each time I'm about to send a new demand, check the current demand (which is read out from hardware during the last set) and if it is the same I do not need to request it again.

What do you think?

[lstebel]

Hi @ajgdls, I agree that rather than being an option, a faster procedure could become the default and only behavior for the command.
Regarding what you suggest on this regard for the implementation... I am not sure of how faster the initial operation of just reading values would be if compared to applying and verifying them. I would rather maintain a set operation of the initial setpoint to all channels (lasting about 8 s) and then set operations only for the channels that need being scanned. This is a safer approach, I think.
To decide whether or not to set a channel to a value, you could check the values in the scan array:
e.g. Vref_ADC_H0 [255, 255, 255, 255] meaning set initially , then don't scan
e.g. Vref_PGA_H0 [0, 20, 40, 60] meaning set initially , then proceed with scan

[ajgdls]

@lstebel can you confirm this is considered complete now?

[lstebel]

Yes, I think so

[ajgdls]

OK then I'm closing this down. We can always re-open etc.