MicroManager is giving an error on the serial port when I save a configuration file or open another configuration file. The error is coming from the standard serial port manager, not from device adaptors.
Error: Failed to load hardware configuration
Line 28: Property, Core, Iniitalize, 1
Error in device “COM5”: Unknown error in the device (1)
MM installation as of 2021-04-20 for all DLLs
Git code from head as of this morning (08 Jun)
MMCore rebuilt for debugging and copied across to MM installation, so that I can debug from Visual C++
Running/debugging MM Studio using Netbeans
Sequence of events:-
- Load a configuration file with a device using the serial port.
- Save the configuration file, or load another configuration file with that device and serial port.
- In SerialPort::OpenWin32SerialPort(), the call to CreateFileA() fails with an invalid handle and GetLastError() returning 5. This produces the error message above, (Happens roughly 95% of the time on my build setup.)
- Load another configuration file. This time it usually works.
- Breakpoint SerialPort::Shutdown() anywhere, and attach Visual C++ for debugging.
1-2) As above, and hit “continue” in Visual C++ when it hits the breakpoint in SerialPort::Shutdown().
- Everything works first time.
This suggests to me that there’s a timing/race condition between the serial port shutting down from the initial configuration and starting back up again with the new configuration. I suspect this is related to the Boost AsioClient implementation, as well as the SerialPort::Shutdown() code which simply uses a “SleepMs(100);” call and assumes that’s long enough for the port to be shut down. I can’t see anything in there which actually checks (using the Win32 API) that the port is genuinely unused.
I’m seeing this during development of Prior PureFocus support. We also have a client in China though who’s seeing the same issue with standard Prior hardware and the existing (unchanged) Prior device adaptors. I should note that my VM is (intentionally) fairly underpowered, and I suspect our Chinese client is also not on a latest-and-greatest PC, which naturally will tend to show up timing issues more.
Has anyone else reported this before?