Bob!! First off, you brought clouds with you to San Jose! :-p Welcome BTW, looking forward to seeing you tomorrow.

On the issue itself, it's the other way around. Right now in AcquireImages.js the check does not exist and it will always try to turn tracking off at the end of the sequence if the mount supports setting tracking.

I put the check in, which basically skips setting of the tracking to off if it is already off.

In any case this was a red herring. Basically here's what happened:
- I managed to get to a run of calibration frames which was short enough that I could repeatedly reproduce the issue (2 frames of 10 sec darks)
- I ran ACP-->Ascom Device Hub-->10micron Ascom driver
- From the Ascom Device Hub logs, I noticed that it would always crash when trying to set tracking off after the last image
- Starting looking at AcquireImages.js and figured let me add the check so that it skips that particular call if the tracking is already stopped

And this did fix the issue. BUT, I then went back to ACP-->10micron Ascom driver. And the problem happened again. I realized that the chaining of Ascom Device Hub to 10micron Ascom driver was probably changing up the timing enough that it was behaving differently than when connected directly to 10micron Ascom driver.

So I restored AcquireImages.js to what it was before. And went back to chaining the drivers. Again I could repro the issue with that minimal set of darks.

Now, I suspected the issue is probably related to timing in how the driver is caching the values and when clients are requesting it. So I disabled caching in the 10micron ascom driver and the problem went away. I turned back caching to make sure I could go back to reproducing the issue, and I no longer can!

For now I will turn off caching, connect ACP to 10micron driver directly and see what happens tonight.