Configurable beam flyback time

[q3k]

I've just brought up an OBI on a Jeol T330A and I'm noticing significant artifacts on the left hand side of the acquired images:

I'm guessing this nonlinearity is due to the SEM's beam taking a while to settle on the left side of the raster on each line?

I didn't check this out on an oscilloscope yet so I can't be sure this isn't eg. some other hardware issue impacting slew rate. Although I do remember old captures looked fine. There's other visible nonlinearity in this particular image, but that's just a bad acquisition I think (sample charge up, 40 year old SEM, etc).

Being able to configure flyback time per line and per frame seems to actually be a TODO: https://github.com/nanographs/Open-Beam-Interface/blob/main/software/obi/applet/open_beam_interface/__init__.py#L603

If I'm not missing anything, I'm happy to try implementing this. Would having two constants (frame_flyback, line_flyback) expressing flyback time in ADC cycles in microscope.toml be a good approach? Or should this be runtime configurable and integrated into the command stream, like dwell time?

[isabelburgos]

Having line and frame flyback time as constants declared in the configuration file makes a lot of sense to me since they correspond to physical attributes of a microscope, and it seems the most straightforward and practical to implement. I would welcome this as a contribution.

Technically, you can define frames with line blanking intervals using existing commands: define a RasterRegion that's one line by one pixel, scan to the end of the line (RasterPixelRun), count out a specified interval with Delay, and repeat. This will be good enough for some applications, but when commands are streamed live, execution is only as consistent as the data transfer rate.

For additional context -- In practice when we use this software on an ion beam instrument, the raster scan macro serves the function of milling a rectangle in addition to capturing an image. To mill a rectangle with an even dose, you have to use another set of optics to blank and unblank the beam during and after flyback, respectively. That means down the road we'll want to expand on the RasterScanner module with additional configurable delays. I think adding frame_flyback and line_flyback is an effective step in that direction.

Thanks for taking the time to write up your thoughts, it's really really helpful to get opinions on development directions for this tool.

At the lowest dwell times (like 1-4) my SEM images look exactly like yours, with visible flyback. In practice I usually just compensate for flyback time by slowing down the scan.