I have a weird issue when using different cameras and the CS2SetCamPort function. I am displaying three cameras in three different display ports, and everything went just fine when using 3x the same camera. However, when a camera with a lower resolution is added to the mix, it starts to go wrong;
x1y1 is about the same as x2y2, which leads me to suspect some buffer or memory issue to be the cause. Sometimes the lower half of the image is completely black, sometimes its filled with old image data.
This is the function I call for loading the cameras, where camImages[] is an array of all my cvxImage objects.
private void loadCamera(int selectedCam)
{
if (camImages[selectedCam].LoadImage(driverPath))
{
// check if opened driver supports the ICameraSelect2 interface
if (Driver.ICameraSelect2.CanCameraSelect2(camImages[selectedCam].Image))
{
// change camera
SharedImg imgNew = null;
try
{
int result = Driver.ICameraSelect2.CS2SetCamPort(camImages[selectedCam].Image, selectedCam, 0, out imgNew);
if (result == 0 && imgNew.Handle != IntPtr.Zero)
{
camImages[selectedCam].Image = imgNew;
camDisplays[selectedCam].Image = (int)camImages[selectedCam].Image;
camDisplays[selectedCam].Refresh();
lblConnected[selectedCam].Text = String.Format("CAM {0} is connected", selectedCam + 1);
connected[selectedCam] = true;
}
else
{
camImages[selectedCam].Image = 0;
var error = new Error(String.Format("Could not set the camport for camera {0}", selectedCam + 1));
error.Show();
}
}
finally
{
// ActiveX controls share the assigned image (shared ownership)
if (imgNew != null)
{
imgNew.Dispose();
}
}
}
else
{
var error = new Error("Image does not support the ICameraSelect2 interface.");
error.Show();
//MessageBox.Show("Image does not support the ICameraSelect2 interface.");
return;
}
}
else
{
var error = new Error(String.Format("Error while loading the driver for camera {0}", selectedCam + 1));
error.Show();
//MessageBox.Show("Error while loading the driver");
return;
}
}
Does anyone have an idea what I did wrong? Its always the first camera behaving this way (which is the first one I load).
Hi, @CvK
The code you use for changing the camera port looks ok for me.
I tried to reproduce your issue with CVB 13.00.005 (64Bit) the GenICam.vin driver and the VCMultiOSConsole.
But i was not successful.
I modified the switchCamPort function of this application and removed the check if the current port is already the needed camPort so that the CS2SetCamPort is executed also for CamPort 0 (Cam1).
Even then the resulting image object for CamPort 0 changing to CamPort 0 is the same than before as it checks internally if something has changed. Therefore this should not produce an issue with the image memory for CamPort 0.
It seems that something else is causing the issue what I can´t see here.
Which CVB Version and driver do you use?
Can you check with the MultiOSConsole example if you can reproduce the issue and if necessary modify it.
Then you can send us the modified code so that we can find a solution.
Or you can send us the code of your application. If you want you can send it also to support@stemmer-imaging.de
I based the code on the examples, so i’m not quite sure what else could cause it. No camera or driver setting I could think of should do this. Extra weird; everything goes fine with 3x the same camera. Running through the code step by step still gives me no clue as to where it may go wrong. I’ll see if I can reproduce it with the pure code samples. I’ll keep you posted on my findings
I got the souce code from @CvK. What I was able to reproduce is an issue with CamPort 0 which did not start the grab.
I found out that this was related to the ImageUpdated Event of the Image OCXs. Within this event the grab was started.
When the second camera is loaded (second call to LoadImage) it opens camera port 0 in the first place where the grab is already active. Then the port is changed to camera port 1. In this situation the grab was stopped.
We will take a look into it if this is a behaviour which we should change in a next version.
The ImageUpdated Events should be used for updating other OCXs and variables which use the Image Object of the Image OCX but not for changing the grab state.
It makes it also difficult to find issues related to the ImageUpdated Event. In this case the event is called when the driver is loaded and when the camera port is changed.
The grab start could be placed into the shown event of the main screen instead which is called directly when the screen is displayed.
Then the grab is started after all cameras where loaded.
I originally intended the auto start in the image updated to serve as an automatic way to start my grabs, the application in question is intended to run autonomously. As I also had an automatic connect/reconnect feature in there, I reasoned that the image updated was a good place to start the grab. After all, when the camera reconnects, the image updated event is also fired.
So, for the initial start of the grab, when the program launches, it’s clear how to avoid using the ImageUpdated event. Any advice on where to place the starting of the grabbing for reloading cameras after a disconnect/reconnect?
I see now that the camport change would result in two grab commands being sent really close after each other. Thanks
Hi @CvK,
You do not need to unload and reload the driver in the reconnected event. It is enough to stop the grab when disconnected and start it again if the camera is reconnected.
Two things are important to note if using our Connection Monitoring to inform the application of a disconnected or reconnected camera.
The callbacks are fired from a driver thread.
To change something in the UI we need to do it in the UI thread. Even the grab state should be changed outside of the driver thread.
This can be done in .net with a BeginInvoke (@CvK you do this already in your project).
With C++ you can use for example a condition variable to inform another thread.
Some camera configurations can be lost after a reconnect
The driver sets some features based on the driver configuration like the packet size and the packet delay.
If important these features need to be set manually after the camera is reconnected.
Other features could be important too.
For example if you change the exposure time within your application it is necessary to reset it to the last known value after a reconnection.
Otherwise it will be the factory default or the one from the default user set in the camera.
We should change the description in the documentation to: “When the camera is reconnected the driver can be reloaded to ensure that the camera and the driver are correctly configured.”
I hope that this will make it more clear when it makes sense or not.
I described the way without reloading the driver because it is easier to manage if you do not need to change settings after reconnection.
And the reconnection is faster as the driver is not reloaded
And yes, the settings are only lost if the camera reboots within the time it is disconnected.
