add support for triggering parameters #58
Conversation
this allows setting the following AcquisitionControl parameters: * TriggerMode * TriggerSource * LineSelector * LineMode * LineSource with this it is possible to configure cameras to either issue trigger commands or receive them (or both). see e.g. also [this post] from VAimaging about how to set this up with their cameras. this was done as a quick-win, IMHO the proper solution is to implement support for arbitrary parameters (see FraunhoferIOSB#57). [this post]: https://va-imaging.com/blogs/machine-vision-knowledge-center/i-o-control-how-to-hardware-trigger-a-machine-vision-camera-using-a-trigger-sensor-and-how-to-trigger-machine-vision-lights
rursprung
force-pushed
the
add-triggering-param-support
branch
from
feae44e to
0d23046
Compare
|
|
||
| /// Selects the I/O line to configure. Once a line has been selected, all changes to the line | ||
| /// settings will be applied to the selected line. | ||
| std::string line_selector = "n/a"; |
There was a problem hiding this comment.
i just realised that LineSelector, LineMode and LineSource are under DigitalIOControl and not under AcquisitionControl.
however, this works just fine since the grouping is completely ignored by aravis when setting the parameters (see #59). i don't have the time to implement this, but i think implementing #57 might be the wiser approach compared to adding yet another struct here for DigitalIOControl.
WDYT?
There was a problem hiding this comment.
Please refer to #57 (comment) on the choice of grouping.
|
Thanks for the effort @rursprung. As you already pointed out, it would make more sense to just pass these parameters as generic parameters to aravis. This can be done using the The main advantage of explicitly adding parameters as you did here is to ensure the correct order (plus some debugging prints, but we should add that for the generic case as well). I think this is not necessary in this case, so we could keep the codebase leaner by not adding it. Instead, we should provide additional launch files or examples that cover use cases for specific cameras where the above parameters should be set. What do you think? |
this allows setting the following AcquisitionControl parameters:
with this it is possible to configure cameras to either issue trigger commands or receive them (or both).
see e.g. also this post from VAimaging about how to set this up with their cameras.
this was done as a quick-win, IMHO the proper solution is to implement support for arbitrary parameters (see #57).