QuadEM class at SIX does not have progress bar

[ambarb]

For class SIXQuadEM(QuadEM)

Transient Scan ID: 21706     Time: 2018/07/28 10:31:52
Persistent Unique Scan ID: 'cb1b3719-5fb5-4c54-9261-b26214dec33e'
New stream: 'baseline'
qem11 [In progress. No progress bar available.]                                                                                                                                                                     
qem12 [In progress. No progress bar available.]     

This would be good for counting experiments. Using:

count([rixscam,qem11,qem12])

There is not rixscam count down either but this is probably more to do with the ioc. I am not sure about the quadem ioc

@danielballan is it possible to make a dummy based on exposure time and simply counting down the seconds? I know it will not be exact, especially with readout time etc, and it could pile up for very long scans (rixscam readout is nearly 3 sec as opposed to the motor motion, which is a fraction of a second), but the quadem's don't really have a readout time. It would be nice to understand how much time is left for the point to complete from just a quick glance.

[awalter-bnl]

@ambarb This is tricky, the current approach (correct me if I am wrong @danielballan ) relies on the IOC sending back some status info part way through the scan (like 'readback position' for a motor). For most detectors no feedback exists, I think this is not a small rewrite of the progress bar code and may be some time off. (thoughts @danielballan ?).

[danielballan]

I think this is not a small rewrite of the progress bar code and may be some time off.

Actually, I think this is doable with current bluesky/ophyd. The progress API is quite flexible.

Is it possible to make a dummy based on exposure time and simply counting down the seconds?

Yes, progress bars allow for a whole range of "smartness" since sometimes the crude approach is the only one available. Before going there -- Does the QuadEM present an PVs that we might use to tell us how far along things are? For example, Area Detectors tell us num_capture which we can combined with exposure time to estimate the time remaining.

[awalter-bnl]

@danielballan The qem's have an exposure period and a num_exposures (from memory) but do not have anything that indicates progress. This would have to be estimated from elapsed time and the expected time.

[danielballan]

OK. We'll throw this on the pile of beamline-specific dev work to be done. @ambarb If you have the bandwidth to attempt this, with some guidance for us, that would surely expedite it, as it would accomplish the goal of helping SIX and spreading ophyd expertise in one. Up to you, of course, to balance this against your priorities.

[ambarb]

I cannot start this now but am open to attempting when I have the time. It will not be until after the shutdown. But it is a nice to have thing and not a must have.

Perhaps it would be easy to also do this for the scaler. There is the time base signal that counts up to the time base expected. Maybe this one is one that should be global because it can intilize signals that are already available from the ioc.

[ambarb]

@bisogni do yo uplan on using QuadEM in future?

[bisogni]

Hi AndI, Yes, we plan using the quadEM at Six in the future. Thanks, Caleb Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Andi Barbour <notifications@github.com> Sent: Tuesday, September 15, 2020 2:10:08 PM To: NSLS-II-SIX/profile_collection <profile_collection@noreply.github.com> Cc: Bisogni, Valentina <bisogni@bnl.gov>; Mention <mention@noreply.github.com> Subject: Re: [NSLS-II-SIX/profile_collection] QuadEM class at SIX does not have progress bar (#9) @bisogni<https://github.com/bisogni> do yo uplan on using QuadEM in future? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#9 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AF2TZRV5T6L36CEUNVPSEKLSF6UYBANCNFSM4FMUIIZA>.