Configuration speed of multiple cameras in different threads

@Ben,

you mentioned earlier that you have a question regarding the configuration of multiple cameras in different threads. I thought about it and I think it is the best to open a new topic for this.

You have to configure some cameras at start up of your software and to speed things up you sort those cameras into different threads. It seems that the overall processing time for all cameras did not decrease significantly.

I talked to a colleague here at Stemmer and the first opinion is that the configuration should be faster. On the other hand the communication to the camera should not be to slow and more in the low ms area.
Of course there are some parameters which take longer like “Save User Set”, “Load User Set” and so on.

However, we would like to ask you for more data regarding the setup speed and the time difference you have between multi-threaded and single-threaded application. Which parameters are you setting up?

Have a nice weekend :slight_smile:

2 Likes

OK, I’ll try and do that for Monday

After a bit of research, here’s some extra information.

What we’re actually doing is a Discover, then a Parallel.ForEach of:

Open()
Configure()
Dispose()
Open()

Configure is just an extension method around setting a load of node values.

Why do we Dispose and Open again? It’s related to this question. Because we’ve seen some strange things, and can’t get a clear idea of exactly what settings take effect when, we disconnect and reconnect - in the hope that all the settings we’ve sent will actually work.

If I run in series, I see that discovery takes about 3.7 seconds, then for each camera:

Open() - 2.2s
Configure() - 0.1s
Dispose() - 0.5s
Open() - 2.3s

So logically, if I run in parallel, I should be able to do this in 9s. But with 5 cameras, in series it takes 29s, and in parallel 27s.

Looking at the logs, it seems to me that Open doesn’t parallelise. For example, if you have this (pseudocode):

Parallel.For { log("Open"); Open(); log("Done"); }

All the Opens start at the same time, but the Dones come back at (around) 2 second intervals.

Just to be clear: I can live with this (though it is painful when you have 9 cameras and you’re iterating during development), but if it’s not expected behaviour, I’m interested to work out what’s wrong.

Thanks to @parsd and therefore a second opinion I know something more about this now:

Open and Dispose are both currently not thread-safe internally. Therefore those methods are Mutex-Locked. Each Open() waits for the previous one to finish. This explains the behavior you are encountering.

We will have to discuss internally if and how we can change this in the future.

1 Like

OK, that’s good to know. Now I need to spend more time working out exactly what (if) the problem is that made me want to close and open again.

@Ben,

did you figure out why you close / open again after you already connected to the cameras once?

As my colleagues (@Andreas, @parsd) tell me it will not be easy to change the behavior of CVB in this part.

1 Like

There’s just something weird about how settings are handled, but it might be just my own incomprehension. I’ve tried commenting it out for now, to see if I can provoke an error which will help me remember what the exact problem was.

Actually, the problem is probably with people fiddling with settings from GenICam browser, and then our application not working properly. This was why I originally went with doing a Factor reset on every power-up, then overriding defaults with any specific settings. But a project manager wanted that changed so that ‘calibration settings’ (white balance) could be set directly by technicians. But now anyone can set anything…

Do you have to explicitly Save UserSet settings to the camera, or is automatically recorded for next time when you change something?

You don’t have to explicitly save settings in genicam cameras to a userset, unless you want them to persist over a powercycle.

1 Like

That’s the thing, it feels like some settings are persisted, even without explicit save.
I know that’s not very precise, so I’m going to try to monitor things more carefully to try and narrow down the problem space.