cloomis, actually I've made one already: (see PFS_MCS_MULTI_EXP.sk).

Isn't it enough for our purpose?

So you are going to write a loop around that, to step through the rotations and altitudes? Sure, I guess that does not need to be a skel file.

Well ... I guess we can deal with similar thing with higher level command (ope file), but I'm not sure which is better. 

Anyway, I'll make another skel file to interleave Telescope movement and exposures. 

I think we need also one to move Hexapod in z position and take exposure.

Here is note from discussion with Jim and Naoyuki yesterday:

Jim pointed out that we should move ADC as we use in operation, which is different from HSC configuration. Skel file for moving altitude needs to treat it.

yuki.moritani: what is the status of this ticket? Can it be resolved?

I have already pushed a brunch for this ticket with new commands some times ago, but following discussion with Craig in Princeton, I need to modify the skel file to include ADC movement, and set OBJECT if needed.

cloomis I'd like to confirm how we set OBJECT in the run..
Should we(I) prepare higher-level command to set OBJECT (and arbitrary RA/DEC), or can we set OBJECT with skel file?

If we take the latter, you will need some modification, because, if I understand correctly, we can set  "STATOBS.PFS.xxx" and "MEMORY.PFS.xxx" parameters, while you probably look "FITS.PFS.OBJECT" parameter for FITS header....

Per Eric, OBJECT can be magic, and you only need to pass it as an argument within the Gen2 world:

"The FITS.PFS.OBJECT status value will be set if you call a PFS abstract command with an OBJECT parameter (it's a little special in this way). Most observations define the list of targets with RA/DEC/OBJECT defined and so this is passed in to commands that use the target definitions (e.g. a GETOBJECT command). It thus ends up being assigned to the status "auto-magically"."

Since OBJECT is a Subaru card, we should only use it to indicate what Subaru expects, and we can use the GETOBJECT calling conventions to set it. (And as I suggested in the email thread, we should only access it from the PFS side via the FITS.PFS.OBJECT keyword.)

If we want to note other details about an observing sequence, we should pass down something else through our top-level PFS commands. Umm, COMMENT or DETAIL?

Does that help?

This looks good, with the possible exception of how we deal with OBJECT from the Gen2 script. Can you please do two things: rename your branch to tickets/INSTRM-460 and merge it to master?

I'm sorry, Craig. I thought I had commented, but I didn't.

COMMENT or DETAIL sounds fine to me. Or how about OBJDETAIL, just in case that we have similar case later?

Before merging, I need to modify to treat ADC movement. Anyway, I'll rename the branch. 

I vote for OBJDETAIL.

yuki.moritani: what is the status of this ticket now? Can it be merged to master?

No, not yet.. As I mentioned, modification is needed to move ADC. I couldn't spend my time working it, since I've worked on distortion code and tooling. I'll work for it later this week.

I found that we cannot move ADC as we like ... the movement is determined by the elevation angle and selected configuration (e.g. filter). So, I'll ask Subaru which configuration is the closest to ours next week.

After merging, I was told that ADC can be positioned in mm via Gen2. I modify the code filing another ticket INSTRM-533 and close this ticket.