Skip to content

Commit 7b0688f

Browse files
dihmdihm
committed
Increasing doc details for flycapture2 and pylon cameras.
1 parent e597a0a commit 7b0688f

File tree

3 files changed

+58
-5
lines changed

3 files changed

+58
-5
lines changed

‎docs/source/devices/flycapture2.rst‎

Lines changed: 40 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,9 @@ Like the :doc:`IMAQdxCamera <IMAQdx>` device, the bulk of camera configuration i
2929
2. Mirroring the FlyCap Viewer parameter names and values.
3030
3. Connecting to the camera with a minimal configuration, viewing the current parameters dictionary, and copying the relevant values to the connection table (preferred).
3131

32-
Below is a generic configuration.
32+
The python structure for setting these values differs somewhat from other camera devices in labscript, taking the form of nested dictionaries. This structure most closely matches the structure of the FlyCapture2 SDK in that each camera property has multiple sub-elements that control the feature. In this implementation, the standard camera properties are set using keys with ALL CAPS. The control of the Trigger Mode and Image Mode properties is handled separately, using a slightly different nesting structure than the other properties.
33+
34+
Below is a generic configuration for a Point Grey Blackfly PGE-23S6M-C device.
3335

3436
.. code-block:: python
3537
@@ -40,8 +42,43 @@ Below is a generic configuration.
4042
FlyCapture2Camera('gigeCamera',parent_device=parent,connection=conn,
4143
serial_number=1234567, # set to the camera serial number
4244
minimum_recovery_time=36e-6, # the minimum exposure time depends on the camera model & configuration
43-
camera_attributs={},
44-
manual_camera_attributes={})
45+
camera_attributs={
46+
'GAMMA':{
47+
'onOff':False,
48+
'absControl':True,
49+
'absValue':1},
50+
'AUTO_EXPOSURE':{
51+
'onOff':True,
52+
'absControl':True,
53+
'autoManualMode':False,
54+
'absValue':0},
55+
'GAIN':{
56+
'autoManualMode':False,
57+
'absControl':True,
58+
'absValue':0},
59+
'SHARPNESS':{
60+
'onOff':False,
61+
'autoManualMode':False,
62+
'absValue':1024},
63+
'FRAME_RATE':{
64+
'autoManualMode':False,
65+
'absControl':True},
66+
'SHUTTER':{
67+
'autoManualMode':False,
68+
'absValue':0},
69+
'TriggerMode':{
70+
'polarity':1,
71+
'source':0,
72+
'mode':1,
73+
'onOff':True},
74+
'ImageMode':{
75+
'width':1920,
76+
'height':1200,
77+
'offsetX':0,
78+
'offsetY':0,
79+
'pixelFormat':'MONO16'}
80+
},
81+
manual_camera_attributes={'TriggerMode':{'onOff':False}})
4582
4683
start()
4784

‎docs/source/devices/ni_daqs.rst‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -90,7 +90,7 @@ An example configuration of a `WaitMonitor` using a NI DAQ is shown here
9090
# Necessary to ensure even number of digital out lines in shot
9191
DigitalOut('daq_do1',daq,'port0/line1')
9292
93-
Note that the counter connection is specified using the logical label `'ctr0'`. On many NI DAQs, the physical connection to this counter is PFI9. The physical wiring for this configuration would have port0/line0 wired directly to PFI9, which PFI1 being sent to the master pseudoclock retriggering system in case of timeout. If timeouts are not expect/represent experiment failure, this physical connection can be omitted.
93+
Note that the counter connection is specified using the logical label `'ctr0'`. On many NI DAQs, the physical connection to this counter is PFI9. The physical wiring for this configuration would have port0/line0 wired directly to PFI9, with PFI1 being sent to the master pseudoclock retriggering system in case of timeout. If timeouts are not expected/represent experiment failure, this physical connection can be omitted.
9494

9595

9696
Detailed Documentation

‎docs/source/devices/pylon.rst‎

Lines changed: 17 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -76,7 +76,8 @@ Below are generic configurations for GigE and USB3 based cameras.
7676
'Gamma':1.0,
7777
'BlackLevel':0,
7878
'TriggerSource':'Line 1',
79-
'TriggerMode':'On'
79+
'TriggerMode':'On',
80+
'ShutterMode':'Global'
8081
},
8182
manual_camera_attributes={
8283
'TriggerSource':'Software',
@@ -91,6 +92,21 @@ Below are generic configurations for GigE and USB3 based cameras.
9192
9293
stop(1)
9394
95+
Utilities
96+
~~~~~~~~~
97+
98+
The Pylon labscript device includes a script in the `testing` subfolder that can automatically determine the full-frame sensor readout time and maximum possible framerate. This tool helps in correctly determining the appropriate `minimum_recovery_time` to set for each device. The minimum recovery time is a function of the model used, the communication bus used, and minor details of the setup (such as host controller firmwares, cable lengths, host computer workload, etc). As a result, live testing of the device is often needed to accurately determine the actual recovery time needed between shots.
99+
100+
The script is run from within the testing folder using
101+
102+
.. code-block:: python
103+
104+
python ExposureTiming.py [camera_sn]
105+
with `[camera_sn]` being the serial number of the camera to connect to and test.
106+
107+
The script reports the minimum recovery time between two shots of 1 ms exposure each, without the use of overlapped exposure mode. Editing the script to include your typical experiment parameters will help in more accurately determining your minimum recovery time. Typically, the minimum recovery time should be slightly longer than the reported sensor readout time.
108+
109+
Note that in overlapped exposure mode, a second exposure is begun before the first exposure has finished reading out and *must* end after the readout of the first exposure frame is complete. This allows for a series of two exposures with shorter delay between them, at the expense of limitations on the length of the second exposure. The script will also report the minimum time between the end of one exposure and the beginning of the second (nominally `readout_time - exposure_time`). Note that this feature is automatically handled at the Pylon API level; this labscript device is not actively aware of it. As a result, incorrect uses of overlapped mode will not be caught at compile time, but rather during the shot as hardware errors.
94110

95111

96112
Detailed Documentation

0 commit comments

Comments
 (0)