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

[doc] doc review #96

Open
PhilLAL opened this issue Mar 12, 2019 · 4 comments
Open

[doc] doc review #96

PhilLAL opened this issue Mar 12, 2019 · 4 comments

Comments

@PhilLAL
Copy link
Contributor

PhilLAL commented Mar 12, 2019

Hi,
reading the documentation, I noticed a few remarks I put there.

  1. in Interface.h (https://lima1.readthedocs.io/en/latest/plugin/index.html#hardware-interface), it is written int getNbAcquiredFrames() should be implemented by every cameras plugins. However, I noticed that a non virtual method exists in hardware/src/HwInterface.cpp so is it really necessary?

  2. HwInterface.h (https://github.com/esrf-bliss/Lima/blob/master/hardware/include/lima/HwInterface.h): line 138
    "Running:" should not be "case Running:" ?

  3. in Source code organization (https://lima1.readthedocs.io/en/latest/plugin/index.html#source-code-organization), DetectorNameBufferCtrlObj.cpp is mandatory but in Buffer management (https://lima1.readthedocs.io/en/latest/plugin/index.html#buffer-management), it is written "These buffer functionalities may be implemented by the hardware layer (kernel driver in the case of the Espia). If not, an auxiliary buffer manager class will be provided to facilitate (and unify) its software implementation." which let think this is mandatory only if hardware does not manage buffer. Am I wrong?

    1. in Plugins submodules (https://lima1.readthedocs.io/en/latest/plugin/index.html#plug-ins-submodules), DetectorNameCamera.h and DetectorNameCamera.cpp are missing
  4. Capabilities list (https://lima1.readthedocs.io/en/latest/cpp_api.html#capabilities-interfaces) could add a part on VideoCtrlObj

  5. TriggerSource : https://lima1.readthedocs.io/en/latest/plugin/index.html#synchronization describes not exaclty the same modes between Triggering mode modes and common/include/lima/Constants.h in enum TrigMode (line 57) : Internal seems to be IntTrig (in Constants.h), ExtStart could be ExtGate or ExtTrigSingle, MultExtStart could be ExtTrigMult, Gate could be ExtStartStop or ExtGate, and ExtStartStop is named the same into Constants.h. Some other modes are not described (IntTrigMult, which is probably a trig for each frame into acquisition by soft, and ExtTrigReadout). Do you confirm? Do you have some details about the sens of each mode?

It is possible I misunderstood some part of the doc, if so please let me know.
Regards

@PhilLAL
Copy link
Contributor Author

PhilLAL commented May 29, 2019

Here are also some typo I saw in the doc:

@PhilLAL
Copy link
Contributor Author

PhilLAL commented Jul 24, 2019

Hello,
our users would like to use trigger and encounter some issues.
Could you confirm my guess on the naming of trigger source in 6. TriggerSource in my post?

Especially, I based my suggestion based on common/include/lima/Constants.h I see

enum TrigMode {
	IntTrig,			//!< Internal software triggering
	IntTrigMult,	//!< Internal multiple software triggering (one prepareAcq, multiple startAcq)
	ExtTrigSingle,
	ExtTrigMult,
	ExtGate,			//!< External signal controls start and stop for each frame
	ExtStartStop,	//!< One external start signal to start acquisition of one frame and one external signal to stop it

	ExtTrigReadout,
};

but https://lima1.readthedocs.io/en/latest/plugin/index.html#synchronization relates :

  • Internal: software triggering
  • ExtStart: one external signal to start the whole sequence acquisition (one or more frames per sequence)
  • MultExtStart: one external signal for each frame in the acquisition sequence
  • Gate: controls start and stop of each frame
  • ExtStartStop: one start signal to start acquisition of one frame and one signal to stop it

In this information, Gate and ExtStartStop seems to be the same condition. Isn't it?

Thank you.

@laurent-claustre
Copy link
Contributor

Hi Philippe,
Gate means the detector will start on rising edge and stop on falling edge of a signal.
ExtStartStop means the detector will start on a first rising edge and stop on a second rising edge, so two pulses should be send to the detector.
Now support for such trigger modes depends on what your hardware supports and on the plugin implementation.

@PhilLAL
Copy link
Contributor Author

PhilLAL commented Jul 24, 2019

Thank you Laurent!

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

No branches or pull requests

2 participants