Building C-Wrapper für .Net

Post Reply
Meldur
Posts: 2
Joined: Tue Feb 23, 2016 8:57 am

Building C-Wrapper für .Net

Post by Meldur » Tue Feb 23, 2016 9:03 am

Hello,

I was not able to bring the Kinearx2DOTServer-project to run so I tried to write my own wrapper in C but I'm by the while I'm going crazy. I'm using this simple routines:

#include "cameralibrary.h"
using namespace CameraLibrary;

Code: Select all

// Link following functions C-style (required for plugins)
extern "C"
{
bool EXPORT_API InitCameraSystem()
{
	CameraLibrary_EnableDevelopment();
	return CameraManager::X().WaitForInitialization();
}

bool EXPORT_API AreCamerasInitialized()
{
	return CameraManager::X().AreCamerasInitialized();
}

int EXPORT_API GetCameraCount()
{
	CameraList list;
	CameraLibrary::CameraManager::X().GetCameraList(list);

	return list.Count();
}
}
The first two are reporting true but for GetCameraCount I allmost get 0 or 1 - but 2 cameras are connected. If I'm using the SimpleCameraTest example, the two cameras are detected corectly.
So please give me a hint what's wrong with my Code?

Thanks,
Meldur

steven.andrews
NaturalPoint Employee
NaturalPoint Employee
Posts: 702
Joined: Mon Jan 19, 2015 11:52 am

Re: Building C-Wrapper für .Net

Post by steven.andrews » Wed Feb 24, 2016 10:43 am

Hello Meldur,

If I understand correctly, you are using 2 cameras. Is this correct?

Could you please let us know what type of camera you are using?

Thanks,
Steven
--
Steven Andrews
OptiTrack | Customer Support Engineer

Meldur
Posts: 2
Joined: Tue Feb 23, 2016 8:57 am

Re: Building C-Wrapper für .Net

Post by Meldur » Wed Feb 24, 2016 12:06 pm

Hello Steven,

I'm using two Prime 13. Both cams are shown in your C++ sample but not in my C wrapper.

Best regards,
Peter

steven.andrews
NaturalPoint Employee
NaturalPoint Employee
Posts: 702
Joined: Mon Jan 19, 2015 11:52 am

Re: Building C-Wrapper für .Net

Post by steven.andrews » Fri Mar 04, 2016 12:05 pm

Hi Meldur,

Since we worked through this on help.naturalpoint.com I wanted to close out this topic and confirm the resolution.



Initialization of Ethernet devices requires a bit more code compared to USB cameras. The main problem is surrounding the usage of WaitForInitialization(). USB cameras are 'connection based', meaning once you have them plugged into your computer they are known to be connected to the computer. For example, you can just look in the Device Manager and see them listed there. As a result, after calling WaitForInitialization() you're guaranteed every connected USB camera has been fully initialized and ready to use.

Now it's a bit more involved for Ethernet devices because the computer doesn't know they exist on the network until they've announced themselves. For the cameras, there is some PoE negotiation that takes place and so the computer doesn't know about them right away typically. As a result when you call WaitForInitialization(), only the cameras that the computer knows about are initialized.

Our suggestion for how to do this is that you continue to monitor the CameraList at regular intervals. Whenever you have a camera on the camera list in State() Initialized that you haven't pulled into your application, you can grab it at that point. Alternatively you can write your own WaitForInitialization function that looks at the camera list and just counts the number of cameras that are in State() Initialized. What that number reaches the expected number of cameras, you're good to go.



The SimpleCameraTest makes a call that you might be overlooking before calling WaitForInitialization(). It calls PopWaitingDialog. The PopWaitingDialog code pops a 'waiting for cameras dialog...' that remains until there is at least one camera found and initialized and there are no other cameras currently in the process of initialization. I pulled this code out so that you can include it in your initialization code.

So utilizing the code pasted below, call WaitForOneOrMoreInitializedCameras before calling the standard WaitForInitialization(). Again, it's important to note that the only bulletproof mechanisms for you would be to specify the number of cameras you have connected and simply wait until you have that many cameras initialized or option #2, must continue to monitor the CameraList for cameras for cameras that might initialize after a longer period of time.


You mentioned you have some bad exit behavior. This can happen sometimes when wrapping the Camera SDK with a .NET wrapper. It's likely related to the USB drivers and since you are using Ethernet cameras you can simply disable USB cameras with:

Code: Select all

cCameraLibraryStartupSettings::X().EnableUSBDevices(  
 cCameraLibrarySettings::USB_Disabled);
You must call the above line before making any other calls to the Camera SDK because this setting needs to be applied before the Camera SDK starts up.

Code: Select all

void WaitForOneOrMoreInitializedCameras()
{
    while( !IsOneOrMoreInitializedCamera() )
    {
        Sleap(10);
    }
}

bool IsOneOrMoreInitializedCamera()
{
    CameraLibrary::CameraList list;

    bool foundOneOrMoreInitializedCamera = false;

    for( int i=0; i<list.Count(); i++ )
    {
        if( list[ i ].State()==CameraLibrary::Initialized )
        {
            foundOneOrMoreInitializedCamera = true;
        }
    }

    for( int i=0; i<list.Count(); i++ )
    {
        if( list[ i ].State()==CameraLibrary::Initializing )
        {
            //== suppress reporting true until all known cameras are initialized ==--
            return false;
        }
    }

    return foundOneOrMoreInitializedCamera;
}
Please note that in the above code, I had to misspell the Sleep command in order for the forum to let me post. So please replace Sleap with Sleep.

Best,
Steven
--
Steven Andrews
OptiTrack | Customer Support Engineer

herrry99
Posts: 8
Joined: Tue Dec 06, 2022 12:47 am

Re: Building C-Wrapper für .Net

Post by herrry99 » Tue Dec 06, 2022 12:54 am

I'm using two Prime 13. Both cams are shown in your C++ sample but not in my C wrapper.

Post Reply