[rgeneaux]

two issues were fixed in CameraBasePyLabLib,:

1. Set hardware_averaging to False. Running a thorlabs camera at 100 FPS with True would crash the plugin in 5 seconds. According to Claude, this is because grab_data is called each frame and creates an infinite number of acquisition loops, triggering a stack overflow.

2. the two ROI switches update_roi ("Update ROI from Viewer") and apply_roi ("Apply ROI") use the led parameter type. With pymodaq_gui 5.3.x, led is a display-only indicator (its widget is created with clickable = False), while led_push is the clickable one.
   Changing to led_push makes the ROI usable again

[seb5g]

good catch RomClaude!

By the way, SebClaude worked on creating a camera template independant of pylablib but following it's interface. It means nothing change for the pylablib based camera but we can now also benefit for other camera of this implementation. There is a base classe defining the interface and the method the driver/wrapper need to have to reuse the plugin gneric structure. I will apply it to opencv webcams... (there will be soon a cookbook in pymodaq_plugins_mockexamples in how to do it). This is meant mostly for agents to learn the proper way to code in pymodaq!

If you have time, can you look at this for the camera you maintain?
I was also going to ask you to maybe give a recipe for a threading buffer properly working, but If you found the probable bug then it's probably fine! I'll test tomorrow with a thorlabs camera

[seb5g]

@rgeneaux thanks for the report on hardware_averaging. I looked at why it crashes: the cause is in the PyMoDAQ viewer loop, not in the camera plugin, and hardware_averaging = False hides it without fixing it.

What happens. DAQ_Viewer_hardware.grab_data (daq_viewer.py) loops and calls plugin.grab_data whenever waiting_for_data is False. The condition to leave the loop for a streaming plugin is:

if self.plugin.live_mode_available and (not self.hardware_averaging and self.average_done):
    break

So the two flags interfere. I replayed this loop with a fake plugin counting the calls to plugin.grab_data in live mode:

live_mode_available	hardware_averaging	Naverage	current behaviour
False	any	any	one call per image (intended)
True	False	1	one call, the loop exits (intended)
True	False	>1	grab_data is called again until average_done: several streams are started, then the loop exits and emits grab_stopped while the plugin still streams
True	True	any	the loop never exits: grab_data is called again after every frame received, and each call starts another acquisition loop. This is the stack overflow at 100 FPS you saw

The loop mixes two independent questions: "does the plugin stream?" (live_mode_available) and "who averages?" (hardware_averaging).

Proposed contract (to be fixed in PyMoDAQ, see the issue I am about to open):

• live_mode_available: the plugin streams after a single grab_data(live=True). The viewer calls it once per session and stops it with plugin.stop().
• hardware_averaging: each emitted data is already the average of Naverage frames. Otherwise the viewer averages in data_ready, also while streaming.

Once the viewer is fixed, CameraBase can set hardware_averaging = True again (the camera averages inside its buffer, without calling grab_data several times). Your change to False was the right call for now, #12 keeps it.

---

Generated by Claude Code

[seb5g]

I've just tested the PyMoDAQ/PyMoDAQ#1422 fix with a thorlabs cam and it works perfectly well where it was crashing before!!!