SPF WAIT command waiting an incorrect amount of time (i think)

[neko]

Hello all,

SX-100, PeakSight 4.0, modern beefy computer that's 99% too powerful for the software.

As usual I've got something unusual - I was having to take a bunch of photos, and I already have hotkeys programmed in to set the screen to our "standard" imaging modes (2500fov, 600, 300, 150, a few others). I have them programed to un-freeze ("acq fixe off 1" in the interpretor) set the resolution to 1024x786 and scan time to 12.8.

Today I got lazy, and decided to figure out if I could automate the wait/freeze so all I or users would have to do is press button, press save, name file. It works! I can post my command.keys if anyone would like my special sauce.

However, I noticed that despite having the wait command set to 12 seconds, it takes 20 for the "acq fixe on 1" command to trigger.

I've also noticed that while performing video scan maps, the program waits an incorrect amount of time to freeze, grab and move on - way worse on fast scans than slow scans, e.g. 256x192 video scan maps *always* take 6 seconds per frame, no matter what time interval I specify, but other modes are closer (i think 1024 and 12s takes about 20 but I haven't timed it recently). I just shrug this off and don't try to do quicker maps.

I am now wondering if the video map wait issue is related to the issue with the SPF WAIT command while also being a bug in the acquisitions set-up.

Does anyone know? Is there a better way to test the wait timer? It's entirely possible that there's some communications lag between the computer and the SX100 that causes this. Is my timer chip bad?

Is the timer for SPF WAIT also used for timing quantitative acquisitions?

In the mean time I'm just going to test different wait values until I empirically determine the quickest way for lazy imaging!

Cheers!
Neko

[Philipp Poeml]

I use the SPF WAIT quite a lot. On my machine 387 Cameca seconds are about 600 real time seconds.

[neko]

Cameca Seconds, noted. Somewhere between 8 and 9 Cameca seconds is equal to the real-time 12.8 second scan on our SX-100. Best my human timing could get when testing the scan was 12.6 seconds which is within the error rate of human reaction times so I'm not worried about the internal timers. Very curious effect, the Cameca Seconds on the SPF WAIT.

I'll see if I can test it a bit more by running commands that get timestamped in the logs separated by a wait. This does explain why I had to set a 300 second wait for 10 minute intervals in my filament EZ-BAKE script.

I've never asked before - does PfE know when the scan resets to auto-freeze the screen? One of the last scopes we got while I was in school did freeze-on-scan-reset automatically when you were slow-scanning for pictures, very handy!

Thanks for answering my silly questions!

[Probeman]

I've never asked before - does PfE know when the scan resets to auto-freeze the screen? One of the last scopes we got while I was in school did freeze-on-scan-reset automatically when you were slow-scanning for pictures, very handy!

For image acquisition PFE calls the video imaging firmware macro directly on the instrument, so it starts when it wants to start, and finishes when it decides to finish, but I haven't noticed a problem with the slow scan acquisition on our SX100.

Right now Cameca firmware macro allows scan speeds from 1 to 7, with 7 being the slowest, but I wish they had an 8 or 9 scan speed for even better quality images...  on the older JEOL instruments one can slow the speed down by setting the number of A-D conversions to a large number.   Paul Carpenter once showed me some stunning BSE images from his 8200 that were acquired with 256 or even 512 A-D conversions per pixel. But even at 512 A-D conversions per pixel the image doesn't take that much longer I seem to remember him saying...  The JEOL UNIX software is fixed at 8 A-D conversions per pixel, so not very flexible for high quality BSE images.
john

[neko]

If I was superstitious, I would say this probe is out to get me. After a year plus of working "properly," all of a sudden Cameca seconds are 1:1 instead of 1.3:1. So everything I have with wait timers programmed into it will have to be adjusted up by ~30%...

Until it magically changes again, presumably right after I finish updating everything that has timers in it. 

[Probeman]

I've never asked before - does PfE know when the scan resets to auto-freeze the screen? One of the last scopes we got while I was in school did freeze-on-scan-reset automatically when you were slow-scanning for pictures, very handy!

Hi Nick,
Just saw this as I was re-reading your saga described above.

When PFE acquires a video electron image, the driver is interacting at a very low level with the instrument firmware, and so it automatically waits for the frame to be complete no matter where in the frame the image acquisition starts or stops.

That is to say, the image acquisition is handled at the driver level so one always gets a full frame image. 
john