F200 setOption freezes

[Wollimayer]

When using multible F200 Sensors I encounter a problem when setting the laserpower.
Sometimes the application freeze and does not recover during the setOption cmd.
No error is thrown and waiting for an hour did not solve this problem. It seems to get worse, the more cpu activity runs in the background.

(Using Windows 8.1 , i5-4460 core at 3.2GHz and 8 Gig of ram)

The problem seems to occure in uvc-wmf.cpp.

device.subdevices[subdevice].ks_control->KsProperty((PKSPROPERTY)&node, sizeof(KSP_NODE), data, len, nullptr)

is executed but never completed.

void set_control(device & device, int subdevice, uint8_t ctrl, void *data, int len)
        {        

            device.open_ks_control();

            KSP_NODE node;
            memset(&node, 0, sizeof(KSP_NODE));
            node.Property.Set = device.subdevices[subdevice].ks_property_set; //{0x18682d34, 0xdd2c, 0x4073, {0xad, 0x23, 0x72, 0x14, 0x73, 0x9a, 0x07, 0x4c}}; // GUID_EXTENSION_UNIT_DESCRIPTOR
            node.Property.Id = ctrl;
            node.Property.Flags = KSPROPERTY_TYPE_SET | KSPROPERTY_TYPE_TOPOLOGY;
            node.NodeId = device.subdevices[subdevice].ks_node_id;

        check("IKsControl::KsProperty", device.subdevices[subdevice].ks_control->KsProperty((PKSPROPERTY)&node, sizeof(KSP_NODE), data, len, nullptr));
        }

[Wollimayer]

I found a temporary way to at least get the information, that the setOption command did crash. It's really hacki so maybe some does have a better way.
I changed the code for set_option in the rs.hpp file, so that a thread is used to send the cmd. After a given timeout the program throws an error ,if no result was returned.

bool set_option(option option, double value)
        {

            std::future<int> setOption = std::async(std::launch::async, [](rs_device * ref, rs_option option, double value) {
                rs_error * e = nullptr;
                rs_set_device_option(ref, (rs_option)option, value, &e);
                error::handle(e);
                return 1;
            }, (rs_device *)this, (rs_option)option, value);

            if (std::future_status::ready == setOption.wait_for(std::chrono::seconds(1))){
                return true;
            }else{
                throw std::runtime_error("Could not set options");
                return false;
            }
        }

[ddiakopoulos]

@Wollimayer std::async is actually the best solution here (we talked about this internally yesterday), and likely will appear beneath the library layer sometime soon

[Wollimayer]

The question is, what causes this error ? The program crashes after the error is thrown ( probably because there is a child thread in an unknown state still active without a parent thread ).
So this will not fix the underlying problem.

[ddiakopoulos]

@Wollimayer can you give the dev branch a test? std::async wasn't the right solution here and we implemented a workaround using a (potentially) unsafe Windows-specific mechanism: https://github.com/IntelRealSense/librealsense/blob/dev/src/uvc-wmf.cpp#l488

The root cause is still unknown, but assumed to be a firmware bug. The UVC spec states that a control get/set shouldn't block infinitely.

[Wollimayer]

@ddiakopoulos I tried to use the dev branch and was able to capture a setOption failure. However it seems that this causes another error to quit the program (not always but sometimes). ucrtbase.dll does request a termination of the program after leaving my setOptionWithRetry test method (Without an error being thrown) :

bool setOption(rs::device & dev, rs::option option, double value, int retry = 5) {
    try {
        dev.set_option(option, value);
        return true;
    }
    catch (std::exception e) {
        std::cout << e.what() << std::end;;
        if (retry <= 0)
            return false;
        else
            setOption(dev, option, value, --retry);
    }
}

(An even strange effect was caused by multiple retries to start the capture process. After ~10 tries i receive two kinds of error when accessing the rs::context

opcodes do not match

and

calibration table is not compatible with this API

A reboot solved those problems, but this might be a side effect of the changes in the setOption part.
I got the feeling that the systems turns unstable the more often an error occurs, till it reaches a point where the devices are not responding correctly anymore.

Is there any way to bypass this complication by using another framework ( libuvc is available for windows , could this 'fix' the problem ?)

[digitologist]

I wonder if you are working with an unsupported USB controller. I have encountered certain machines that throw KSProperty errors inconsistently. Sometimes a reboot or plug/unplug of the hardware clears the issue, but usually until the app runs once, then won't reinitialize.

There's no comprehensive list of unsupported hardware, but can you list your machine, processor, and USB controller details? There might be a match with the ones I've found.

[Wollimayer]

Windows 8.1
i5-4460 core at 3.2GHz
8 Gig of ram
Intel(R) HD Graphics 4600

USB Controller:
2x Intel(R) 8 Series/C220 Series USB EHCI #1 - 8C26
4x Renesas USB 3.0 eXtensible-Hostcontroller

Hope that's the right information .

[ddiakopoulos]

@Wollimayer it's unlikely that switching backends will fix the problem (I also tried for a couple days a few months ago to get libuvc/libusb working with bulk transfers on Windows 8.1 with no luck). Renesas controllers should definitely work.

Can you isolate the bug to 1 camera (the one with 2.6 firmware) and attach a minimal app (as source-code) used to cause the error? One of the difficulties with your issue is that we are unable to replicate here.

[ddiakopoulos]

Closing for lack of new information.