GetDeviceCount() takes forever

We have been using the FrontPanel API on 32-bit Linux for maybe 10 years now. We are porting to 64-bit (Ubuntu 18.04LTS). While there was a delay when bringing up our software (maybe 8 seconds) in GetDeviceCount(). We now hang for about 20 seconds!

We use this call to determine if any hardware is connected. If so we open the device we found. However, 20secs startup time is not acceptable. We are using 5.0.2 and tried with our older XEM 6010 boards as well as with our newer platform XEM 7310. The both have the same delay. On 32-bit Linux we have 8secs (while not ideal we can probably deal with it). On Windows 10 there is no noticable delay (fracions of a second).

Any idea why this function would block for so long and any workaround?

What we need to do is this: We first check if there is a device attached, if not we launch without hardware (test mode). IF the user configured a Device ID we check if among the found devices we have the Device ID, if so we open the device, if not we error out. If the user didn’t specify a device ID we grab the first device we found and open that.

If there is a way to figure this out without using GetDeviceCount() please advise.


Hello Thomas,

This is due to a known issue in the method used to determine which and how many FrontPanel devices are connected to a PC when calling GetDeviceCount(). The current implementation scans every USB device in the system to see if a FrontPanel device is present. It also does this for each possible FrontPanel device, so as more devices are added it takes longer. Some of this is due to legacy support for older kernel versions. We plan on improving this significantly in the next release of FrontPanel by adding support for more recent device discovery methods and adding some degree of caching within our library. We hope to release this support later this month or in early September.

That said, a time of 20 seconds is excessive even given the poor implementation. Since every device is scanned, it is possible that there is a device connected to the PC that is significantly increasing this time if it takes a substantial amount of time to respond. You may want to try disconnecting other USB devices to see if there is one particular culprit that is increasing the enumeration time. This may serve as a workaround until the next software release.

Thanks for the reply. That makes sense. I guess Windows is more efficient in that regard. Is there another method for the time being that you would recommend to use?
One note: We have been running Ubuntu 18.04 in a VM on Windows 10 (but our users might use a similar setup).

If we upgrade to the new release once it’s available would it be compatible with the 5.0.2 version?


Just a quick update. We ported to openSUSE 15.2 and the delay is about 2.6 seconds. Not sure why Ubuntu is > 30seconds but there seems to be an apprreciable difference.

When is the new release expected to be available?


Which version are you running? 5.2.3 was released 2020-08-27 and addresses this issue.

This was announced in our newsletter about a month ago.