Support galvo control and sensing on OCPI2

[Cody-G]

I propose that we reserve analog inputs and outputs for galvo mirror operation on OCPI2. Details are below, values are based on the specifications of our galvo mirrors:

• AO channels AO2 and AO3 will be reserved with names galvo1, galvo2.
  - Valid voltage range: +-10V
  - World units: degrees (1.0 degrees per volt)
  - Maximum allowed speed: not sure, let's say 100V / second for now?
• AI channels AI2 and AI3 will be reserved with names galvo1 monitor, galvo2 monitor
  - Voltage range: +-5V
  - World units: degrees (2.0 degrees per volt)

[kdw503]

Now AI range is set as +-10.
I'm not sure we can set this range differently for every AI channels.
And, old imagine is using AI2 as camera2 monitor.

[Cody-G]

Now AI range is set as +-10.
I'm not sure we can set this range differently for every AI channels.

It would be nice to change the range at the DAQ level, but it's not necessary. Actually I think Imagine can ignore that number, we only need this within ImagineInterface. (I'll give a warning or something if the loaded ai file goes outside of the +-5V range)

And, old imagine is using AI2 as camera2 monitor.

I still hope that we can stop using the old imagine on OCPI2 soon. But maybe to be safe we shouldn't use that channel. What channels do you suggest?

[kdw503]

I still hope that we can stop using the old imagine on OCPI2 soon. But maybe to be safe we shouldn't use that channel. What channels do you suggest?

If we stop using the old imagine soon, it's ok to use AI2 and AI3.
If not, I suggest AI4 and AI5.

[Cody-G]

I will ask current users whether they're ok with switching. I think it's worthwhile to keep the unreserved channels continuous.

…

On Tue, Sep 26, 2017 at 1:05 PM, Dae Woo Kim ***@***.***> wrote: I still hope that we can stop using the old imagine on OCPI2 soon. But maybe to be safe we shouldn't use that channel. What channels do you suggest? If we stop using the old imagine soon, it's ok to use AI2 and AI3. If not, I suggest AI4 and AI5. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#47 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE78hIvHsNWaLJ-EMByZpblshJ076zHGks5smTzEgaJpZM4Pkcnv> .

[kdw503]

Yes, that would be better.

[Cody-G]

It seems people are okay with moving to the new version exclusively! I'll be doing heavy testing this week and next week, so I think we can make the transition at the end of next week if that's good for you.

At that point it will finally be time to merge the waveform branch and delete it. I propose that we manage the branches this way:

1. The current master (which is very old) should get tagged with a version number
2. The current waveform branch merges into dev and gets deleted
3. dev gets merged into master

Any further changes after next week will go to the dev branch, and hopefully we can merge that branch into master more regularly than we have done so far.

How does that sound?

[kdw503]

That plan really sounds good to me!