Snd xcs3 - check delay scan motor

[silkenelson]

Expected Behavior

The virtual motor should scan the delay as expected.
It needs a feedback/PV that could be used in the smallData & scan tables. The motor should report a reasonable name to the DAQ scan/control data (aka not something too long or starting with a '_')

Current Behavior

not sure.

Scientist

Yanwen Sun (for the motor functionality)

[ZLLentz]

Some useful info for this card:

Link to where the snd delay stuff is defined:

hxrsnd/hxrsnd/macromotor.py

Line 456 in 8f566f9

class DelayMacro(CalibMotor, DelayTowerMacro):

Link to the full "split and delay" object:

hxrsnd/hxrsnd/sndsystem.py

Line 21 in 8f566f9

class SplitAndDelay(SndDevice):

Which is instantiated with the prefix "XCS:SND"

Reading these, the delay motor is probably currently called snd.delay in xcs3, with the data key snd_delay

[Yanwen-Sun]

I tried to do something like this. The reason for scanning the delay in this way is that I will need to move a few other motors together with the snd.delay. Is it still a scan in DAQ? I found ISSCAN returns 0.

daq.configure(record = True,controls={"delay":snd.delay})
for i in range (npts):
print(delays[i])
snd.delay.mv(delays[i], verify_move=False)
snd.t1.th2.mv(t1th2pos + corr[i,1]/corr_th)
snd.t4.chi1.mv(t4chi1pos - corr[i,0]/corr_chi)
time.sleep(1)
daq.begin(events = 500)
daq.wait()

[silkenelson]

Hi Yanwen, for ISSCAN and the related information to work, you do need to use a "proper" scan which is now using BlueSky in XCS3. If you look at the experiment files (or macro.py), you will see the definition of "ascan": it's basically a BlueSky scan with the DAQ setup and then the scan takes the DAQ as an argument (so that it knows how to run the calib cycles). There are also scans that would e.g. move three motors each along their list of positions in BlueSky and they should take the DAQ just like the 1-d version - you can look at the documentation and/or import plans and look around there. The tricky part is that BlueSky will try to do the 'right thing' which means wait with the DAQ until all moves are completed - because it seems like you should be able to do that. This behavior you would need to modify (either if you need a larger tolerance or plain want to change the check to a sleep). This is something that I would hope Kan or Zach can help you with to set up an example and/or simply guide you. When that then does not work as expected with regards to scanPVs, controlPV etc, then yourcan create a bug-report.

[Yanwen-Sun]

Can we have snd.delay as a PV always recorded in the data even when there are no scans?

[silkenelson]

This request was to have it recorded when we scan it in the usual way.
If the virtual motor has a feedback PV, you should include this in the epicsArch file anyways, but it will NOT behave the same way for automated scripts that e.g. use the control data to figure out how to plot a given run. We should make sure that the virtual delay motor has a feedback PV in the new way (which is better than the old solution from what I remember)

[Yanwen-Sun]

I tried to do x.ascan with the motor snd.delay, but it asked to verify move and thus the scan failed... there used to be a argument to set verify_move to false

[Yanwen-Sun]

Ok.. we have set all the verify_move default to False. But there is still error in moving the Aerotech motors which I reported here: #99