Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CCD multi-track capability for Princeton cameras #6

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

pheest
Copy link

@pheest pheest commented Nov 17, 2020

I would like to query a couple of issues:

a. Is there any policy regarding use of asyn:READBACK, as opposed to use of _RBV records?

b. The st.cmd file does not currently select a specific camera (it will select the default camera 0, i.e. whichever is the first detected).
This is an issue because camera settings are loaded from the hardware on start-up.

Heesterman, Peter J added 2 commits November 13, 2020 14:17
…rack class previously used for ADAndor.

Updated picam library - added 32-bit library version that Princeton now have available.

Corrected some printf string parameter errors.
Enhanced error detection and handling behaviour.

Added Linux build capability (was previously missing), 64-bit only.
This requires ftp://ftp.princetoninstruments.com/Public/Software/Official/PICam/Picam_SDK.run installed.

Tested end-to-end (on Windows only) using a ProEM camera.
@MarkRivers
Copy link
Member

a. Is there any policy regarding use of asyn:READBACK, as opposed to use of _RBV records?

The use cases are quite different. _RBV is used to indicate what the hardware currently is using. It does not modify the output record. asyn:READBACK updates the output record based on the readback. I have typically only used asyn:READBACK in specialized cases, for example the FileNumber in the file plugins, which can be autoincremented by the driver, or manually set by the user. For most parameters I don't like the driver to modify the output record. Having the output and readback be different can give the user an indication that something is wrong, whereas updating the output record could hide this problem.

b. The st.cmd file does not currently select a specific camera (it will select the default camera 0, i.e. whichever is the first detected). This is an issue because camera settings are loaded from the hardware on start-up.

I don't think many people are using ADPICam, so I think you will probably find a number of issues like this that have not been addressed yet. It would be great if you can test and improve the driver! I am currently using ADLightField rather than ADPICam, but ADLightField has its own issues, and I would be happy to know that ADPICam was a viable alternative.

@pheest
Copy link
Author

pheest commented Nov 20, 2020

The current software has a capability for selecting a camera (by it's enumeration order) from the AvailableCameras_RBV record.
This is a concern because the enumeration order is not guaranteed by the Princeton API.

It's more useful to select a specifc camera by it's serial number.
I've added that capability, used from the constructor.
And added it as a parameter used within st.cmd (0 selects the first available camera).

The AvailableCameras_RBV record is populated (with camera model) through the readEnum method.
If there is more than one identical camera model, this could be an issue.
What does Asyn do, if the enum strings are not unique?

I've prepended the camera serial number to the enum string.
This changes (in my case):
"ProEM-HS: 512B eXcelon-2" to
"#12546318 ProEM-HS: 512B e"
(The string is clipped because it's length exceeds MAX_ENUM_STRING_SIZE)

I don't understand the cause of this reported error:
2020/11/20 15:47:11.421 NDPluginDriver::createCallbackThreads error, queueSize=0 must be >= 1, setting to 1
2020/11/20 15:47:11.425 NDPluginDriver::writeInt32 ERROR, status=3, function=64, paramName=QUEUE_SIZE, value=0, connectedToArrayPort_=1
This doesn't seem to cause a problem.

Heesterman, Peter J added 2 commits August 25, 2021 12:52
width/sizeX and height/sizeY variable names were used in an inconsistent way.
Included other completed pull requests.
Added Linux SDK files.
Added (optional) build using Acton spectrometer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants