---
title: "v2.3.0 - not yet released"
product: "LumiScan Cam Driver"
component: "lumiscan-cam-driver"
version: "2.2.1"
display_version: "2.2.1.10"
latest_version: true
language: "en"
url: "https://docs.hdvisionsystems.com/en/lumiscan-cam-driver/2.2.1/release-notes/v2-3-0.html"
---

# v2.3.0 - not yet released – LumiScan Cam Driver

**Added:**

- **Image stream (experimental).** A camera can now stream its images instead of taking one image per capture request. `<camera name>/control/publish/execute` applies the inputs `control/publish/input/enable` and `keep-latest-output`. While the stream runs, the Cam Driver publishes every image the camera delivers on `control/publish/output/stream/frame` for a subscriber, together with its size, its pixel format and its lineage: the camera, the stream’s start and the image’s number in it. The Cam Driver does not trigger the camera by itself: an image comes on a hardware trigger, on `control/trigger/execute`, or continuously while the camera’s trigger mode is off. Triggered at a fixed rate, the camera we tested delivered every image at up to 66 images per second, against about 34 with `capture/execute`, with its `TriggerOverlap` set to `PreviousFrame` in a feature file. `keep-latest-output` also puts each image on `output/image` and counts it on `output/package-identifier`, at the cost of a copy per image. Counters under `control/publish/output/stream/statistics` show images and losses.

  Every image is delivered on either Data Layer. `setting/settings-hash` identifies the settings the images are taken with, and each frame carries it. Each frame also carries the module’s tag - the camera name, or the one `control/publish/input/tag` gives, which is saved in the module configuration file as `stream.tag` - and the applications that process the images keep it in their results' lineage. The hash says that the settings changed, not what changed; and that it follows a camera feature change has not yet been verified with a real camera.

  While the stream runs, `capture` is not available: `capture/ready` is `false`, `capture/execute` answers `DL_INVALID_OPERATION_MODE`, and a capture request ends with status `-3` without latching a fault. Stopping the stream connects the camera again, so `capture/ready` returns after about two seconds on the camera we tested. See [Streaming Images (Experimental)](https://docs.hdvisionsystems.com/en/lumiscan-cam-driver/2.2.1/lumiscan-camdriver/streaming-images.html).

- **Software trigger.** `<camera name>/control/trigger/execute` sends the camera a software trigger while it is in software trigger mode - its trigger mode on and its trigger source software, read in the camera’s own spelling - and does nothing in any other mode. The command is the camera’s own, `TriggerSoftware` or `SoftwareTrigger`. A camera in that mode without either, or refusing it, reports the new status `-10012` (`softwareTriggerFailed`). While the image stream runs, a camera without a software trigger mode - a simulated camera, or a plugin camera without `TriggerSoftware` - is fired by its own trigger instead, one image per call. See [Software Trigger](https://docs.hdvisionsystems.com/en/lumiscan-cam-driver/2.2.1/lumiscan-camdriver/execute-a-method.html#software-trigger).

- **Feature mappings.** A camera that names its software trigger command, its trigger mode or source, or their values differently gets its own names in the application settings file: an entry under `featureMappings`, named by the camera’s `featureMappingId`. The schema lists the keys. A mapped name the camera does not have is logged as a warning, and the built-in names are used. See [Software Trigger](https://docs.hdvisionsystems.com/en/lumiscan-cam-driver/2.2.1/lumiscan-camdriver/execute-a-method.html#software-trigger).

- **An example of the settings, on a PC.** `-g, --generate-settings [folder]` writes the application settings file, an example module file and their schemas into a folder (the current one by default), names the folder the Cam Driver reads its settings from, and ends. Existing files are never overwritten. See [Creating New Camera Settings Files](https://docs.hdvisionsystems.com/en/lumiscan-cam-driver/2.2.1/lumiscan-camdriver/creating-new-camera-settings-files.html).

- **Settings on the Data Layer.** `hdvisionsystems/lumiscan-cam-driver/system/settings` shows the settings the application was started with: the application’s settings file, each module file inlined in its `modules` list, passwords as `***`. Writing it changes the files. The application checks the change as at start, saves it (the previous file as `.bak`), and then refuses all work until it is restarted: `restart-required`, status `-5`. `hdvisionsystems/lumiscan-cam-driver/system/control/restart/execute` restarts it. See [Settings on the Data Layer](https://docs.hdvisionsystems.com/en/lumiscan-cam-driver/2.2.1/lumiscan-camdriver/settings-on-the-data-layer.html).

**Bugfix:**

- **The Cam Driver started on a ctrlX CORE again.** Since it moved to the new command line, it refused the `-p 8080` its snap passes and ended at once. It accepts and ignores `-p` now, and the snap no longer passes it.
- **A program that keeps calling a refused `execute` no longer floods the log.** Each refusal was written as its own line, so a program retrying `capture/execute` while the camera was busy wrote about 11 MB of log per minute. For each method and result, the first refusal is logged, then at most one line every ten seconds, which says how many were not logged one by one.